On 8/31/12, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> There have been interesting comments on the SRFI 105 list on curly-infix
> notation. I'd like comment/discussion here, if there's any.
>
> I have tried to summarize the comments here:
> http://sourceforge.net/p/readable/wiki/SRFI-Curly-issues/
>
> Two smaller issues first:
> 1. They'd like to use "equal?" instead of "eq?" for operator comparison,
> e.g., to support ",op". That generalizes things, and although I have
> concerns about cycles, they think that shouldn't be a big concern. I'm
> amenable.
> 2. They want a directive, and John Cowan really likes #!srfi-105, dropping
> (enable-curly-infix) completely. Directives are fine. I'm not enthusiastic
> about #! being the beginning of a directive, since this is also used to
> start a script. But it looks like the standards body will *insist* on using
> #!.... for #!fold-case and #!no-fold-case, and this would be a similar kind
> of syntactic change.
>
> It'd be possible to have both #!...!# comments and #! directives. E.G., an
> implementation could say if a letter follows "#!" it's a directive,
> otherwise it's a #!...!# comment. That would mean that #!/usr/bin/env,
> #!./unsweeten, and #! /usr/bin/env would all work like now. We don't have to
> spec the disambiguation anyway, just state the marker and its meaning, but
> our rationale could note that they don't NECESSARILY have to conflict in
> implementations. Knowing that makes me feel less bad about #!srfi-105 as a
> directive.
>
> Now, the big issue: Embedded neoteric-expressions.
>
> Shiro Kawai and John Cowan are both of the strong opinion that once you
> enter {...} curly-infix, it should ALWAYS support neoteric expressions.
>
> Shiro Kawai said:
>> > C-exprs and n-exprs are technically orthogonal, and you split
>> > them partly because for the ease of adoption. But I feel that
>> > combining them increases their appeal a lot for wider adoption,
>> > while supporting only one doesn't seem likely.
>> >
>> > Supporting n-exprs only in c-exprs may seem technically inelegant,
>> > but how about seeing it as a starting point? To me it seems easier
>> > to flip switch once I enter '{}' world, so I don't mind if the
>> > syntax is different in '{}' from outside '()' world.
>
> My concern has been that this creates a minor inconsistency; it means that
> f(x) would have a different meaning inside {...} than outside it. Granted,
> if you want f(x), you could just surround it with braces, e.g., {f(x)}. Alan
> Manuel Gloria also doesn't like it.
>
> HOWEVER, in the end, what is important is *adoption*. If we "stick to our
> guns" and make curly-infix by itself NOT support neoteric-expressions, I
> think it is likely we will have far less adoption. Basically, they'd like
> the SRFI to include "as much capability as you can WITHOUT changing the
> meaning of existing standards-compliant s-expressions". And their
> experiments show that curly-infix, by itself, isn't as expressive as
> curly-infix that also allows neoteric-expressions (which I believe is
> certainly true).
>
> So I'm of the opinion that we *should* make this change. This change
> doesn't affect sweet-expressions, since they will still require
> neoteric-expressions *outside* of curly-infix.
>
> Thoughts? Comments?
>
*shrug*
In t-expressions now that c-expressions have the {e} -> e mapping, I
sometimes format cond's this way:
define foo(bar) $ cond
{ retractable?(bar) } $ retract bar
{ extensible?(bar) } $ extend bar
else $ error "not a retractable or extendable bar"
In s-expr+SRFI-105+n-expr-in-curly:
(define (foo bar)
(cond
({ retractable?(bar) } (retract bar))
({ extensible?(bar) } (extend bar))
(else (error "not a retractable or extendable bar"))))
Okay, fine, I don't like it (inconsistency here concerns me), but I
won't oppose it. Will not support, will not oppose.
Here's another question. I assume that { foo(bar(nitz)) } is (foo
(bar nitz)), i.e. n-expressionism is recursive within curlies. How
will we implement the reader? The current implementation is much
simpler as it is simply a hook that gets triggered on {, but with
n-expressions inside curlies, we'll have to show a reference
implementation that replaces 'read.
Sincerely,
AmkG
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
