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.
So, we must consume the entire number first, then determine afterwards
if it was a number or a symbol, and only then determine if it was a
base-expr or base-expr-postable (i.e. it is a valid prefix). I
suppose we could implement this as a function that returns both the
expression and also whether it is validly postable (i.e. can be a
prefix as used above).
Anyway, the rationale for this seems to be to improve backward
compatibility, so that:
9(x)
is interpreted as two separate sub-expressions. This is generally
"not recommended" in s-expr syntax, but is valid anyway.
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.
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:"
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.
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.
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).
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
