Peter Lewerin <email@example.com> wrote:
| I recently found newLisp (<URL: http://www.nuevatec.com/>). It's
| developed for Linux but seems to work very well on Windows (98).
| BTW to other group readers: what is the common opinion on newLisp?
| Is it kosher or an abomination? I've noticed some interesting
| differences from other dialects, but to my untrained eye it appears
| to be OK.
From just a quick look, I'd say it's closer to the "abomination" end
of the spectrum. From the user's manual:
newLISP is closer to Scheme than it is to Common LISP,
but is also different in some aspects from both dialects
of LISP. In most cases the naming and working of built in
functions is similar to ANSI Common LISP
That is, neither fish nor fowl. No matter whether you're a Scheme
prgrammer or a CL programmer (or both), you're going to be confused.
newLISP is dynamically scoped, like original LISP...
*Neither* Scheme nor Common Lisp is dynamically scoped by default
(except CL for top-level variables only). Then they add back some
"state", in things that look like &aux variables (sort of):
...local state variables in lambda expressions. ... The
update of local state variables in lambda expressions is
treated as part of an transaction, which only takes place if
the function is completed without error. Since version 6.3
the contents of local state variables is stored directly in
the lambda list.
Self-modifying code??!? What happens when you instantiate multiple
instances of one of these?
User defined functions (Lambda expressions) in newLISP
may always be manipulated like any other list expression.
So a pure interpreter, no compilation?
Like Scheme newLISP also evaluates the operator element
of a list expression.
So it's a Lisp-1? [CL isn't.]
newLISP is free of garbage collection. Only under error
conditions newLISP needs to collect unused memory.
Clearly not suited to long-running processes.
Anyway, the list of weirdnesses goes on & on & on. [And that was
just the first screenful of the manual (excluding contents/index).]
My suggestion would be to avoid it liike the plague...
Rob Warnock, 30-3-510 <firstname.lastname@example.org>
SGI Network Engineering <http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA