Should *most* memory be release back to the system?

[Jörg W Mittag]

Thanks for the replies, looks like I have really missed some recent stuff here.

Also, one of the first backends for the PyPy Python implementation
<http://PyPy.Org/> was a Common Lisp (actually clisp) backend, because
that was easier for testing. I mean, Lisp eats syntax trees for
breakfast, what better language would there be to bootstrap a
prototype compiler in? (-;

Looks like it was revived recently:
<http://CodeSpeak.Net/pypy/dist/pypy/doc/translation.html#gencl>

jwm

 

[M. Edward (Ed) Borasky]

In what sense? I don't think Lisp is mostly functional nowadays any more
than Perl is mostly functional so to speak. You _can_ write in a
functional style in both languages, but in my view they are
multi-paradigm nowadays.

I'm not sure what "multi-paradigm" means, but Lisp 1.5, Common Lisp and
Scheme are at their core functional languages based on the lambda
calculus with "enough" imperative features, macros and side effects to
get work done. An awful lot of Lisp (and Scheme) code has been written
over the years, but it's still really Lisp 1.5 at heart.

You can almost get away with writing Lisp 1.5 in either Common Lisp or
Scheme. Where you'll get thrown off is

a. Lexical scoping. Both Common Lisp and Scheme are lexically scoped,
but Lisp 1.5 was dynamic.
b. There ain't no "evalquote" any more -- it's "read - eval - print".
c. Scheme treats "nil" as true.

 

[Chad Perrin]

I'm not sure what "multi-paradigm" means, but Lisp 1.5, Common Lisp and
Scheme are at their core functional languages based on the lambda
calculus with "enough" imperative features, macros and side effects to
get work done. An awful lot of Lisp (and Scheme) code has been written
over the years, but it's still really Lisp 1.5 at heart.

I think, in this context, "multi-paradigm" is intended to mean
functional, object oriented, imperative/procedural, and maybe even a
little declarative, all at once.

You can almost get away with writing Lisp 1.5 in either Common Lisp or
Scheme. Where you'll get thrown off is

a. Lexical scoping. Both Common Lisp and Scheme are lexically scoped,
but Lisp 1.5 was dynamic.
b. There ain't no "evalquote" any more -- it's "read - eval - print".
c. Scheme treats "nil" as true.

Point C really throws me. I guess my Ruby bias is showing.

 

[Yohanes Santoso]

I think, in this context, "multi-paradigm" is intended to mean
functional, object oriented, imperative/procedural, and maybe even a
little declarative, all at once.



Point C really throws me. I guess my Ruby bias is showing.

Strictly speaking, Scheme does not have nil. It has empty list, (),
which in other Lisps is also called nil.

And, as in Ruby, an empty container, be it a list or an array, is
evaluated as true in boolean context.

The only false value in Scheme is #f.

YS.

 

[Chad Perrin]

Strictly speaking, Scheme does not have nil. It has empty list, (),
which in other Lisps is also called nil.

And, as in Ruby, an empty container, be it a list or an array, is
evaluated as true in boolean context.

The only false value in Scheme is #f.

Thanks. That makes a lot more sense to me.

 

[Florian Frank]

Point C really throws me. I guess my Ruby bias is showing.

I think you misunderstood the sentence. In Lisps nil is the empty list
(= the last element of a recursive list), and in ordinary Lisps it's THE
false constant at the same time. In Scheme the empty list is a true
value like Ruby's empty array, but there are also literal constants #t
for true and #f for false, while there is only a symbolic T constant for
true in ordinary Lisps.

So if you would write

(defun sum (l)
(if (not l)
0
(+ (car l) (sum (cdr l)))))

in Common Lisp, you would have to write

(define (sum l)
(if (null? l)
0
(+ (car l) (sum (cdr l)))))

in Scheme. Of course you could shorten the Common Lisp version to:

(defun sum (l)
(if l
(+ (car l) (sum (cdr l)))
0))

But in Common Lisp it's more common (ha!) to use the loop construct

(loop for i from 1 to 3 sum i)

because it's not required for Common Lisps to have tail call optimization.

In general Ruby's kind of nil (as an undefined "value") doesn't come up
very much in Scheme (or the other Lisps), because all variables have to
be explicitly bound to a value for a scope if you want to access them.

 

[M. Edward (Ed) Borasky]

I think, in this context, "multi-paradigm" is intended to mean
functional, object oriented, imperative/procedural, and maybe even a
little declarative, all at once.

Well, then, every Turing-complete language is multi-paradigm, right? The
core of Scheme and Common Lisp is "car", "cdr", "cons", "lambda",
S-expressions and M-expressions mapped into S-expressions, etc., just
like good ol' Lisp 1.5. Lisp 1.5 had "progn", though, so I guess you
could claim it was procedural. Objects were grafted onto Lisp just like
they were grafted onto Perl and Python. Lisp wasn't *born* with objects
in the same sense as Smalltalk, Java and Ruby were. Now I would call
Ruby a multi-paradigm language before I'd call Scheme one.

 

[Xavier Noria]

Well, then, every Turing-complete language is multi-paradigm,
right? The core of Scheme and Common Lisp is "car", "cdr", "cons",
"lambda", S-expressions and M-expressions mapped into S-
expressions, etc., just like good ol' Lisp 1.5. Lisp 1.5 had
"progn", though, so I guess you could claim it was procedural.
Objects were grafted onto Lisp just like they were grafted onto
Perl and Python. Lisp wasn't *born* with objects in the same sense
as Smalltalk, Java and Ruby were. Now I would call Ruby a multi-
paradigm language before I'd call Scheme one.

When I mentioned multi-paradigm there was a response to someone
mentioning Scheme and Common Lisp. I didn't see "mostly functional"
was referring to Lisp 1.5 and not Common Lisp. It is Common Lisp the
one I think it is multi-paradigm.