On Fri, 2009-12-04 at 18:13 -0800, Vincent Manis wrote:
> On 2009-12-04, at 09:46, Eduardo Cavazos wrote:
> > I'm not a fan of the R6RS change to make brackets work like parenthesis.
> > On the other hand, I respect that alot of folks like to use them this
> > way. It would be nice if they were "programmable". One approach is to
> > have the reader expand '[...]' into:
> >
> > (brackets ...)
> >
> > and '{...}' into:
> >
> > (braces ...)
> >
> > or something along those lines. 'bracket' and 'braces' would be macros
> > that should be imported into the library accordingly. I.e. the R6RS
> > standard libraries would export a 'brackets' macro that simply expands
> > into '(...)'.
> >
> > What other designs are out there to consider?
>
> I'd much rather see programmable readtables,
I'd also like extensible lexical syntax, but not necessarily via
readtables (more below), and for square brackets = parenthesis to be
optional and achieved using that.
> which, IIRC, would be moderately
> difficult to add to Ikarus (and, in any case, wouldn't be portable elsewhere).
It could be portable if there was some standard.
> I'm very happy with R6RS's definition of square brackets, but both braces and
> guillemets, among other paired symbols, would be nice to define. But a
> programmable
> readtable lets us do a lot more.
I can understand why some people don't like R6RS making square brackets
equal to parenthesis, because then square brackets cannot be used for
something else. I used to feel square brackets helped me better
visually parse S-expressions, but, honestly, now they visually distract
and annoy me.
> I don't think this is an easy change to make to the language either, as there
> are
> interactions with both libraries and ports (what does it mean to import a
> readmacro?
> how do we associate readtables with ports?). But maybe it's worthwhile, or
> maybe
> it's a feature piled on a feature...
I think I like the idea of making the lexical syntax extensible via
continuable exceptions raised by the read procedure. (IIRC, this was
mentioned at r6rs-discuss before R6RS was ratified, but I don't know how
much it was discussed.) If read encounters a string it doesn't
understand, it raise-continuable's a condition which contains the string
consumed so far and the port (whose position is immediately after the
string). The lexical syntax can be extended by having an exception
handler use the condition to process the custom syntax and return
whatever type of value it wants. read will place that value in the
being-constructed data structure corresponding to where the custom
syntax started and continue trying to read more from where the handler
left the port's position.
#!symbol could be used to activate/deactivate lexical extensions.
Maybe: via some Scheme-system-specific means, you could tell the Scheme
system what handlers are associated with what #!symbol's, and when the
system's standard read procedure encounters a registered #!symbol, it
installs the associated handler for the rest of the parsing until it
encounters a deactivator #!no-symbol or the port ends. Or something. I
bet #!identifier could be used somehow.
> My current favorite example comes from the IEEE 754-2008 decimal arithmetic
> package at speleotrove.com (and found in some C compilers). I have a very
> crude
> interface to this running, but it requires me to specify a decimal constant
> as
> (decimal "3.14") (which is pretty much the same as the way you specify
> decimal
> numbers in Python, modulo a left parenthesis being moved). It would be very
> nice
> to be able to say #m3.14!
With something like my ideas above, I think you could do:
#!ieee-754-decimals --- #m3.14 ---
--
: Derick
----------------------------------------------------------------
