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/