[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improving the API for read options
From: |
Ludovic Courtès |
Subject: |
Re: Improving the API for read options |
Date: |
Tue, 06 Nov 2012 20:01:28 +0100 |
User-agent: |
Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) |
Mark H Weaver <address@hidden> skribis:
> address@hidden (Ludovic Courtès) writes:
>>> I've been avoiding adding a public API for this, because I feel that the
>>> current 'read-options' API is poorly-designed and I'd rather take the
>>> opportunity to come up with a clean design.
>>
>> What about just mapping the existing ‘read-options’ to something like:
>>
>> (set-port-read-options! PORT OPTIONS)
>>
>> where OPTIONS would be a list of symbols, as for ‘read-options’? This
>> seems to me like the obvious API extension, but maybe I’m overlooking
>> something.
[...]
> One problem I have with the existing API has to do with its treatment of
> square brackets. There are multiple things that one might want to do
> with square brackets, but since 'square-brackets' is a boolean option,
For that particular problem, I’d propose:
(set-port-read-options! PORT OPTIONS)
but with OPTIONS being an list of option/value pairs, or:
(set-port-read-option! PORT OPTION VALUE)
where OPTION is a symbol.
Nothing fancy, but that should do the job while being reasonably
future-proof, no?
[...]
> I haven't yet had time to think this through, but my gut instinct is
> that I would prefer an API closer to this:
>
> * We provide an opaque type 'read-options' which we reserve the right to
> change at any time, and a set of predefined read-options objects such
> as 'inherit-all-read-options', 'guile-default-read-options',
> 'r6rs-read-options', etc.
>
> * We provide procedures to set! and retrieve the read-options object
> to/from a port, and perhaps to/from a global setting. We might also
> provide a parameter.
>
> * For each user-visible (high-level) read option, we provide a set of
> predicates and mutators for 'read-options' objects.
>
> * We provide a way to explicitly pass a 'read-options' object to the
> reader.
>
> * We define the order in which the 'read-options' objects are checked,
> e.g. first from the explicit parameter (if any), then the per-port
> options, then the fluid (if we add one), then the globals.
>
> * We provide a way for user-defined token readers to accept the
> 'read-options' object from the reader, so that it can be propagated
> properly to subordinate readers.
>
> * We need to think about whether (and how) to expose inheritance to the
> user. We might want to provide ways to reset an option to "inherit"
> mode and to test whether an option is in "inherit" mode. However, in
> other contexts the user may just want to know about the applicable
> option.
>
> This kind of API would give us more freedom to enhance and generalize
> the reader in the future, while providing an easy-to-use and stable API
> that users can rely upon.
Right. However, it seems to be addressing a lot more problems (more
like Guile-Reader) than what we were initially discussing, which is to
provide a way for users to set per-port options.
I was really hoping that a dumb solution as I proposed would be enough.
:-)
WDYT?
(Regarding reader extensibility, I’ve become dubious about the whole
idea of reusable and composable token readers. I think readers should
rather be generated from SILex-style declarations, and we could have
several of them pre-generated. And the ‘scm_t_read opts’ may not scale
well in terms of cyclomatic complexity.)
Thanks,
Ludo’.