In article <3070521785789755@naggum.no>, Erik Naggum <erik@naggum.no> wrote:
>* Paul Wilson
>| You could build a language based on Lisp/Scheme technology with a more
>| conventional syntax, and more redundant keywords.
>
>* Fergus Henderson
>| Sure, you could, but has anyone done it?
>
>yes. it's called DYLAN, for DYnamic LANguage. see comp.lang.dylan.
There are a bunch of others, one notable one being Pop. Pop has
been around for a long time, has books published about it, etc.,
and is still in use. (see comp.lang.pop)
Even McCarthy's early Lisp system had a different syntax
available, which was expected to become the standard syntax.
(It doesn't look a whole lot like C, though. But then, C
wasn't going to exist for a while, so not many people grumbled
about that.)
The "code" syntax fell away in favor of the "data" syntax,
I suspect largely because in those days people were fond
of treating code as data, and calling eval. These days,
that's much less common because once you have lexical
scope and closures, it's much more efficient and safe
to use lambda and calling than eval. In other cases, where
you need to control whether and when arguments are evaluated,
macros are usually better than eval. (Eval should be used
very carefully and sparingly in normal apps, because it is
slow and tends to confuse compilers so that they can't
optimize *other* code as well. You can usually get the
effect you want straightforwardly with lambda (for the non
Lispers, think of it as "make-procedure"), and it'll be
tons faster.
Once you have lexical scope and closures, much of the advantage
of "code looks like data" syntax is reduced. (This is why ML,
Haskell, et al. didn't inherit this from Lisp. Unfortunately,
they also didn't inherit macros, which are a much cooler
thing than most people realize.)
There have been a bunch of other Algol-ish or C-ish parsers for
Lisp, but once the looks-like-data syntax had become entrenched as
"what Lisp looks like", they had little chance among serious
Lisp users. This may have entrenched the division between
Lisp and conventional programming languages, which I consider
to be one of the most unfortunate splits in CS.
Part of this was probably due to the fact that Lisp macros
required having a convenient data structure to operate on,
because they're basically procedural. Only recently have
there been macro and compiler extension facilities that
would work with more conventional syntax and give you most
of the power of Lisp macros. (As a side benefit, the
constraints on those systems make them easier to use correctly.)
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
|