Alan Manuel Gloria <[email protected]>:
> Here's the rule I'm talking about:
>
> "What's more, if (...), {...}, or [...] are prefixed with a symbol or
> list (i.e., have no whitespace between them), they have a new meaning
> in modern-expressions"
>
> Rather unfortunately, with a single-character lookahead, this is a
> little hard to implement, at least in a modular way (we'd have to
> integrate base-expr and base-expr-postable into the mdn-expr parser),
> because symbols can legitly start with numeric characters - see Common
> Lisp http://www.lispworks.com/documentation/HyperSpec/Body/02_cd.htm ,
> which also includes 1+ as a symbol.
> ...
> This is however a bit of an inconsistency. Compare:
> 9(x) f(x)
> I'm thinking that maybe backward compatibility for the 9(x) case might
> not be too hard to sacrifice.
That's a good point. I would agree that 9(x) is pretty darn ugly, and unlikely
to be written today.
> Basically what I'm proposing is to modify the rule (changes underlined):
>
> "What's more, if (...), {...}, or [...] are prefixed by _any
> expression_, they have a new meaning in modern-expressions:"
That would actually continue a trend. Originally I only translated "f(x)" =>
"(f x)" if f was a symbol, but then I realized that translating "(a b c)(d e
f)" => "((a b c) d e f)" was actually remarkably useful. Thus, I've already
relaxed the rules once.
> This also enforces our "parameters are separated by spaces" guideline;
> it now becomes "parameter are _always_ separated by spaces", by
> removing one of the few ways (one of the only remaining ways?) that
> parameters can be separated without a space.
Well, "(" would still separate parameters... it's just that, if it's embedded,
the previous value gets cuddled inside.
But I see your point, it would make the rule much more regular, and that is
very valuable.
One thing I worry about in general is making the syntax so generous that
arbitrary line noise is okay. But that doesn't apply to this case; since
"9(x)" is already being accepted, as "9 (x)", arguing that it should be
interpreted instead as "(9 x)" on the grounds of consistency is certainly
plausible.
> So I suppose we should try:
>
> 1. Look at existing CL, Scheme, Arc, ELisp code, and see how often
> stuff like 9(x) #t(x) etc. etc occur.
>
> As an aside, the code: http://srfi.schemers.org/srfi-75/r6rs-reader.ss
> has a few cases of [var exp][var exp] (specifically in let
> expressions) without space separating them. modern-expressions in 0.2
> will still fail here because it gets interpreted as (bracketaccess
> (var exp) var exp). So I think going all the way and requiring spaces
> between all params is not going to add that much more back-compat
> problems.
That make sense.
> However this is just a weak idea, and one I'm willing to let go of if
> someone can show real-world code that would work fine in current 0.2
> but would fail with this change (the r6rs-readers.ss example above
> would fail both 0.2 and with this change, so it doesn't count).
I can be convinced either way as well. However, the arguments that:
1. It makes the rule more consistent
2. It makes the parsing easier to implement
is a pretty darn compelling case. Especially since I expect expressions like
"9(x)" to be extremely uncommon in modern code. I think I *have* to say "yes!"
unless there's some data to suggest otherwise.
Can you grep some sample code in CL, Scheme, & Arc to see how often it happens?
--- David A. Wheeler
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
