Why don't people like lisp?

[Kaz Kylheku]

"Andrew Dalke" <adalke at mindspring.com> wrote in message news:<64Ilb.1525$I04.1503 at newsread4.news.pas.earthlink.net>...
> Kaz Kylheku:
> > Moreover,
> > two or more domain-specific languages can be mixed together, nested in
> > the same lexical scope, even if they were developed in complete
> > isolation by different programmers.
> 
> We have decidedly different definitions of what a "domain-specific
> language" means.  To you it means the semantics expressed as
> an s-exp.  To me it means the syntax is also domain specific.  Eg,
> Python is a domain specific language where the domain is
> "languages where people complain about scope defined by
> whitespace." ;)

There are two levels of syntax: the read syntax, and a deeper abstract
syntax. People who understand only the first one to be syntax are
scared of syntactic manipulation, because they are used to being
burned by syntax: stupid precedence rules, quirky punctuation,
semicolon diseases, strange whitespace handling, and so on.

A symbolic expression is a printed form which codes for a data
structure. That data structure continues to exhibit syntax, long after
the parentheses, whitespace and other lexical elements are processed
and gone.

> Yes, one can support Python in Lisp as a reader macro -- but
> it isn't done because Lispers would just write the Python out
> as an S-exp.

They would do that in cases when they have to invoke so many escape
hatches to embed Lisp code in the Python that the read syntax no
longer provides any benefit.

> But then it wouldn't be Python, because the domain
> language *includes*domain*syntax*.
> 
> In other words, writing the domain language as an S-exp
> is a short cut to make it easier on the programmer, and not
> on the domain specialist.

Writing the language in terms of a data structure (which can be
converted back and forth to a printed symbolic expression) is not a
shortcut; it's proper layering at work. The read syntax can be
independently developed; the symbolic expressions merely give you a
generic one for free! Read syntax is just lexical sugar. It can be
quite important. Heck symbolic expressions have enough of it; it would
be a pain to type (QUOTE X) all the time instead of 'X, or
#.(make-array '(4) :element-type 'bit :initial-contents '(1 1 0 1))
instead of #*1101!

> > Can you use that syntax in a Python source file and have
> > it processed together with normal code?
> 
> Did you look at my example doing just that?  I built
> an AST for Python and converted it into a normal function.

I'm looking for a Python example which adds a new kind of statement to
the language, and then later in the source file uses that statement to
write a part of the program, such that it's all processed in the same
pass. The statement can be nested in existing ones, and can have
existing syntax embedded in it. Oh yeah, and it should work on at
least two Python implementations.

> > What is Python's equivalent to the backquote syntax, if I
> > want to put some variant pieces into a parse tree template?
> 
> There isn't.  But then there isn't need.  The question isn't

When you start talking about need, that quickly becomes a losing
proposition. Because needs are actually wants in disguise. Do human
beings need electricity, running water or food prepared by heating?

> "how do I do this construct that I expect in Lisp?" it's "how
> do I solve this problem?" 

The answer is: if I can get Lisp, I use that. Otherwise I work around
that. If you are in the middle of civilization, and the question is
``what's for dinner'', the answers are to go to the supermarket or a
restaurant. If you are lost in the woods, then you have to reason
differently.

> There are other ways to solve
> that problem than creating a "parse tree template" and to
> date there have been few cases where the alternatives were
> significantly worse -- even in the case of translating a domain

What cases? Where? Can you be more specific? Can ``significantly
worse'' be put into some kind of numbers?

> language into local syntax, which is a Lisp specialty, it's only
> about twice as long for Python as for Lisp and definitely
> not "impossible" like you claimed.

Okay, I'm expecting that example I asked for to be only twice as long
as the Lisp version.