Re: Common Lisp "let"

[Pixel <address@hidden>]

Paul Prescod <paul@prescod.net> writes:

> As long as we're admitting that redundancy can be a good thing, maybe I
> should take a pot-shot at the usual Lisp-ers presumption that XML is
> highly redundant by accident, because its specifiers did not know about
> S-expressions. Actually, the redundancy helps error checking and
> reporting, 

hum. One can't generalize that redundancy *always* help error checking
and reporting.

I agree that named close-tags help error reporting (but doesn't help
error checking), but IMO it destroys readability. We end up with a
heavy Ada-like syntax.

Having both named & unnamed close-tags (a la SGML's </>) would allow
to favour readability for small trees (the leaves), and using named
close-tags for bigger nodes (favouring error reporting).


(http://www.prescod.net/xml/sexprs.html)
> The need to escape does not arise with most prose documents

Well, it depends what XML is for. If the purpose is literate
documentation, it is nice. If the purpose is programming (think XSLT),
I much prefer *any* other syntax (including Cobol!).

And XML escaping syntax is nicely generic, but quite ugly. I have many
html files with a lot of "->" and "=>" which are unreadable due to
"&gt;"s
(there is also "&", but it is not the one that bothers me the more)

And you don't talk about attributes, where the syntax is ="..." or
='...', which imply quoting (&quot; or &apos;)

I do agree Lisp s-exprs can't replace XML. I only dream XML would have
been nicer... Especially when people want XML everywhere (any idea how
/etc/group would like like? :-( )


> just as it does in the Scheme "let" example.

Well, as Paul Graham i disagree that :

> > I believe the downside of this approach is an example such as:
> > 
> >   (with (x w y z a b) ...)
> > 
> > where it's could be easy (especially with less-trivial variable names)
> > to be mistaken about which were the variables being bound and which
> > were the expressions being evaluated.  So I think there's a tradeoff
> > here.

is going to be a problem (same reasons as Paul Graham gave + the fact
that odd number of arguments can't go undetected)

one that may be worse in Arc is cond:

    cond make it easy to have errors (the cond and value are not
    grouped, uneven lists allowed because of the last default)
    ("with", (eg: "(with (x 0 y 1) (+ x y))") doesn't have the pb
    since the variable names are better checked)

    (written some time ago at http://lambda.weblogs.com/discuss/msgReader$2097?mode=day)