updated SRFI-108 Per Bothner (04 Feb 2013 00:21 UTC)
Re: updated SRFI-108 John Cowan (04 Feb 2013 08:16 UTC)
Re: updated SRFI-108 Per Bothner (04 Feb 2013 20:29 UTC)
Re: updated SRFI-108 Per Bothner (04 Feb 2013 20:43 UTC)
Re: updated SRFI-108 John Cowan (05 Feb 2013 01:24 UTC)
Re: updated SRFI-108 Shiro Kawai (05 Feb 2013 02:11 UTC)
Re: updated SRFI-108 Per Bothner (05 Feb 2013 02:24 UTC)
Re: updated SRFI-108 John Cowan (05 Feb 2013 07:54 UTC)
Re: updated SRFI-108 Per Bothner (05 Feb 2013 08:15 UTC)
Re: updated SRFI-108 John Cowan (05 Feb 2013 15:42 UTC)
Re: updated SRFI-108 Per Bothner (22 Feb 2013 00:36 UTC)
Re: updated SRFI-108 John Cowan (22 Feb 2013 03:10 UTC)

Re: updated SRFI-108 Per Bothner 04 Feb 2013 20:43 UTC

On 02/04/2013 12:29 PM, Per Bothner wrote:
> A possible solution/compromise is to *require* that "&name[initial-exp]"
> be followed by a braced-delimited literal part, if necessary empty:
>    &name[initial-exp]{}
> This avoids the incompatibility.  It makes parsing slightly more
> complex, but the extra code and state needed is small.

To clarify: Parsing is slightly more complex if an implementation
wishes to support *both* SRFI-108 and R6RS brackets-as-parens
(or Kawa's brackets-as-vector-constructor).  At least if not
requiring a separator between a symbol and a starting bracket.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/