From: ludo@gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel@gnu.org
Subject: Re: Improving the API for read options
Date: Tue, 06 Nov 2012 20:01:28 +0100 [thread overview]
Message-ID: <87zk2usghj.fsf@gnu.org> (raw)
In-Reply-To: <87y5ifb2tw.fsf_-_@tines.lan> (Mark H. Weaver's message of "Tue, 06 Nov 2012 02:36:11 -0500")
Mark H Weaver <mhw@netris.org> skribis:
> ludo@gnu.org (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’.
next prev parent reply other threads:[~2012-11-06 19:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-04 23:59 [PATCH] Make `get-datum' conform more closely to R6RS semantics Andreas Rottmann
2012-11-05 5:07 ` Mark H Weaver
2012-11-05 17:52 ` Ludovic Courtès
2012-11-06 7:36 ` Improving the API for read options Mark H Weaver
2012-11-06 19:01 ` Ludovic Courtès [this message]
2012-11-11 7:56 ` Mark H Weaver
2012-11-06 19:55 ` [PATCH] Make `get-datum' conform more closely to R6RS semantics Andreas Rottmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zk2usghj.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).