[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.


(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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]