Email list hosting service & mailing list manager

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 05 Feb 2013 02:24 UTC

On 02/04/2013 05:24 PM, John Cowan 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.
>
> I can live with that.  I have yet to be convinced once and for all that
> initial-expressions are actually as useful as all that.  I'd rather
> leave them as an optional extension.
> ...
> Probably, but the difference is one of whitespace only, and it makes
>      (foo &condition [bar 1 2])
> and
>      (foo &condition[bar 1 2])
> differ very radically.  If initial & was rare, I'd probably feel better
> about this, but it's common in SRFI 35 or R6RS code that deals with
> conditions.

Fair enough.  I made this change in
http://per.bothner.com/tmp/srfi-108/srfi-108.html

I can make initial expressions an optional extension if it is likely
to lead to more implementations supporting SRFI-108.  Implementors,
let me know.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/