Subject: newLISP [was: Re: Running Lisp on Windows 98 ]
From: (Rob Warnock)
Date: 21 Aug 2001 04:30:25 GMT
Newsgroups: comp.lang.lisp
Message-ID: <9lso51$ctsbr$>
Peter Lewerin <> wrote:
| I recently found newLisp (<URL:>).  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		<>
SGI Network Engineering		<>
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA