Erk... sorry Neil I pressed the wrong reply button.... I sent it to
you but not to the list.
---------- Forwarded message ----------
From: Alan Manuel Gloria <[EMAIL PROTECTED]>
Date: Nov 19, 2007 8:46 PM
Subject: Re: [Readable-discuss] Sweet-expressions version 0.2 ideas:
grouping {}, [], ()
To: Neil Toronto <[EMAIL PROTECTED]>
On Nov 19, 2007 11:03 AM, Neil Toronto <[EMAIL PROTECTED]> wrote:
> David A. Wheeler wrote:
> > Alan Manuel Gloria:
> >
> >> Hmm. Possible confusion between ()-as-s-expr versus
> >> f()-as-swt-expr-function-call IMO.
> >
> > Yes, but that's no different than any other language. In C and friends,
> > f(3) is not the same operator as (3 + 4). Unfortunately, it's not hard to
> > do (3 + 4) when you meant to do {3 + 4}. A colorizing text editor can make
> > those blazingly clear, though.
> >
> > My current thought is to allow f{3} instead of f(3), in case that worries
> > you. But to be honest, I don't really like the look of f{3}. My goal is
> > to make the surface syntax "comfortable", even to those who don't use Lisp
> > day-in/day-out... because OTHER people have to read my code, not just me
> > :-). f(x) as a function-call is so standardized that I can't find examples
> > of anything other than f(g(x)) or f g x. Well, except Lisp :-).
> >
> > --- David A. Wheeler
>
> I imagine you invited me onto this list for my perspective as a Lisp
> outsider, so here it is. :)
>
> 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.
>
> People expect a language parser to use a consistent set of rules. (This
> may be a strange idea to people who use their languages to write
> languages, but there it is.) There are often differences in rules
> between types of scopes (e.g. module vs. class vs. function), especially
> in statically-typed languages, but overall the rules are more similar
> between scope types than between languages.
>
> With these recent proposals, there are arbitrary differences depending
> on the whims of the programmer. That's much better than arbitrary
> differences imposed by a parser, but it'll still make people's heads spin.
>
> 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.
> 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.
> 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.
>
> 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.
> ----
>
> One last thing: I agree with Dave Herman that your sweet-expression page
> is well-written. I had no problem following most of it with just a
> passing familiarity with Lisp and Scheme. (I had to look some things up,
> but that's expected.) One thing I don't understand is the need for full
> backward compatibility. Is it because readers are global, and you can't
> switch them out per-file - or at least, you can't expect people to do that?
I think he wants to add this as part of the LISP language. If
swt-expr readers are somehow inherently incapable of reading s-expr --
well, LISP's without support for s-expr syntaxes seem to have failed
to really capture the attention of LISP users e.g. Dylan. If he can
somehow keep s-expr syntax while supporting m-expr syntax, he hopes to
attract both oldtimers who are madly in love with s-exprs, and
newcomers who can't figure out all those parens.
As far as I can tell, swt-expr is an attempt to get m-expr syntax
while retaining the possibility of reading s-expr syntax.
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.
Basically, macros are so important that we'll even program in s-expr
if necessary, but if you can, say, do something like this, so much the
better:
defmacro foo (x)
if check-if-valid(x)
`(let
( (some-foo ,x))
(do-something some-foo))
error "x is not valid"
>
> If that's the case, maybe the right thing to do would be some sort of
> file-level block delimiter rather than expression-level enclosures. I'd
> be perfectly happy with something like this:
>
> *readable* (or some other non-syntactic marker)
*readable* is a valid symbol in LISP. Possibly #readable#, since # is
an "escape character" to the reader.
>
> defun factorial (n)
> if (n <= 1) ; this is lovely, by the way
> 1
> n * factorial(n - 1) ; or n * {factorial (- n 1)}
>
>
> *unreadable* (or some less snarky non-syntactic marker :D)
>
> (defun factorial (n)
> (if (<= n 1)
> 1
> (* n (factorial (- n 1)))))
>
>
> And have it default to s-expressions for backward compatibility. Can
> that work? Could it also work interactively?
>
> Neil
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Readable-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>
