[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI 105: Curly-infix-expressions

This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.



On Tue, Aug 28, 2012 at 8:50 PM, David A. Wheeler <dwheeler@xxxxxxxxxxxx> wrote:
> Shiro Kawai:
>> We already have #!r6rs, #!fold-case and #!no-fold-case.  I can
>> see #!-markers can be easily abused, but C-expr is a disruptive
>> lexical syntax change big enough to justify using it, IMHO.
>> And with #! marker it is clear that when the reader sees it.
>> With a procedure or a macro, it's not clear when it takes effect.
>>
>> BTW, I think you can drop "(enable-curly-infix)" completely.
>> Other than using it in a single-threaded simple REPL interaction,
>> a user can't assume much how it works...
>
> Okay.  Anyone else have thoughts on this?  I'd be happy to drop (enable-curly-infix) given its weaknesses.
>
> Also, if a #!... marker is important to make the proposal work for everyone, then let's do it.  If it's added, though, my hope is that it would become redundant (because everyone just implemented it out-of-the-box).

Eeehh, #! is syntax for executable scripts on unix-likes.

Now if #! is ignored on the first line, that's fine.

How about, if #!curly-infix is found somewhere other
than as the first column of the first line of a file?

>
>> I certainly see the point of making C-expr default.  It may depend
>> on how many implementations have (ab)used '{}' for other purposes.
>> I'm ok to put it up to the community's vote.
>
> Thanks!  I think this is a challenge in extending Scheme... no matter what is proposed, there is a fair chance that *someone* has a conflicting extension :-).


Is there some process to somehow ask for the community to
vote on an issue?  Or is that the RnRS?

Sincerely,
AmkG