On 2/25/13, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> Alan Manuel Gloria:
>> Awww..... (^.^)v
> :-).
>> Since you're unwilling to put the full Beni formulation in *right
>> now*, then let's use classic formulation. I hope somebody else speaks
>> up for the full Beni formulation and gives a fully interesting example
>> *real soon now* (^_^)
> Absolutely!  Thanks for being willing to do this.
> This particular formulation is definitely interesting, I think
> documenting it is important.
> And please make it clear that this is an upward-compatible
> extension that could be added later, without interfering with any
> existing sweet-expressions.
>> I volunteer to write up the Beni formulation for the SRFI-sweet
>> document - unless Beni wants to write it up himself.
> That'd be great.  Please feel free to document my "$-at-end"
> attempt at a compromise.  If you don't want to do that, I'll add it.

Yeah, although I'll wait a few days to see if Beni wants to write it
himself first.

>> Note that:
>> $
>>   foo
>> ==>
>> ((foo))
>> which is both non-obvious and not something I see as *useful*.  So
>> raising an error is fine with me too.
> Okay. John Cowan made the same point too.
> Looks like we'll drop that, at least for this edition.
> Once it's removed from the BNF, I think we need to make sure that the
> Scheme specifically checks for it and forbids it.  That way, people won't
> accidentally use such constructs for now, and that'll make it easier to
> add later if indeed it's added later.

I propose making it an explicit error in the BNF rather than just
making it an invalid sequence by implication of its absence.


Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Readable-discuss mailing list

Reply via email to