Alan Manuel Gloria wrote:
On Nov 19, 2007 11:03 AM, Neil Toronto <[EMAIL PROTECTED]> wrote:
I've been following these proposals, and been having a difficult time
keeping the decorations straight. My first reaction was "huh?" followed
by "oh!" and then "why?" I'm not going to claim to be the brightest bulb
in the universe, but I have dabbled in quite a few languages in my quest
for The Perfect Fit, and this confuses me more than most confusing
things I've seen so far.
- snip -
In my no-longer-professional opinion, you should leave the decorations
to the s-expressions.
Hmm. "decorations" being...? From my point of view s-exprs hardly
have decorations at all - list limits are all started and ended by ( )
pairs.
Sorry about that. "Decorations" == delimiting parsing rules using (), []
and {} enclosures.
Give the sweet-expression folks One Way to Do It,
which is the full sweet suite, of course. Give them a quick way to drop
down to pure s-expressions if they need to. (Enclosing a list in {}
might work nicely. ;))
maybe a tag with () would do better -
define somefunction(x y)
if somethingorother(x)
ournewcode(y)
#|Legacy code from old version of somefunction()|#
#s-expr(oldcode (somemoreoldcode x) (lessoldcode y))
...or maybe not. Hmm.
I thought about that, too. Whether it's good would depend on how often
sweet-expr people are expected to drop down to pure s-expressions. I
think the tag would have to be long because any short ones would have
the potential to collide with a real identifier. Maybe it's not an
issue, though, if the tag means nothing within real s-exprs.
If anyone will want to selectively enable
language features, it won't be these people.
I might like to have sweet-exprs, but use some language features too.
Do you mean programming with s-exprs in general, but including
sweet-expr features when you want them? If you do mean that, which
subset? I imagine just infix, since syntactic whitespace wouldn't make
much sense, and function prefixes are very un-s-expr (though potentially
the easiest to disambiguate without special delimiters, I think).
The s-expression folks *might*, but they've already developed the
requisite band-pass filter for reading Lisp code, so most won't see the
point of it anyway.
I might prefer the ability to not have to write out lots of
parentheses on the command line, although I'd probably prefer to use
s-exprs in final code.
Good point.
Finally - conventional wisdom claims that LISP's most important power,
macros, is possible only because of the sheer number of parens in the
s-expr syntax (I would contend this, though). So, just in case macros
really, really need s-expr - better keep it in, since we don't want to
accidentally cut LISP's power.
I've read this in a few places, but never seen any concrete reason that
macros can't work with m-exprs. It usually comes down to "if you
understand macros, you'll already know why" - a type of answer I find
both maddening and unfortunately common. So... could you very sweetly
attempt to explain to a non-Lisper exactly why this might be? :)
I'm not attempting to argue the banishment of s-exprs, by the way. I
just want to understand why people think what they do.
*readable* (or some other non-syntactic marker)
*readable* is a valid symbol in LISP. Possibly #readable#, since # is
an "escape character" to the reader.
Gotcha.
Thanks for your time and patience.
Neil
