Mark H Weaver <m...@netris.org> skribis: > l...@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’.
