|
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)
|
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/