Hello all,

Here are improved versions of my recent patches to add per-port read
options, reader directives, and SRFI-105 curly-infix expressions to
Guile 2.0.

I was able to simplify the SRFI-105 patch quite substantially, while
adding a non-standard extension based on GNU Kawa's handling of square
brackets: if the 'curly-infix' read option is enabled, but the
'square-brackets' read option is disabled, then square brackets that are
not part of the SRFI-105-defined neoteric expression syntax are read as
follows: [...] => ($bracket-list$ ...).  This combination of read
options can be set (per-port) using the new non-standard reader
directive '#!curly-infix-and-bracket-lists'.

I added this extension because '[' and ']' must be added as delimiters
when 'curly-infix' is enabled, in order to handle neoteric expressions
such as '{ e[a b] }' which is read as ($bracket-apply$ e a b).

SRFI-105 does not specify what to do with square brackets if the '[' is
preceded by whitespace (or is outside of curly braces), so we needn't
change our default behavior of treating them like parentheses, but if
the 'square-brackets' read option is turned off, then what?  Since they
are delimiters, we cannot use them in unescaped symbols, so I figured
that we ought to do something else useful with them (the alternative was
to report an error).  Since SRFI-105 already followed Kawa's convention
for $bracket-apply$ within curly braces, I chose to follow Kawa's
$bracket-list$ convention as well.

Note that SRFI-105 will be finalized in 4 days.  After that, I see no
reason why these patches shouldn't be applied to the stable-2.0 branch.

What do you think?

    Mark