Xavier N. wrote:
– fxn
Yet another reason not to learn Haskell. 
On Oct 22, 2007, at 4:23 PM, M. Edward (Ed) Borasky wrote:
Martin DeMello wrote:
Also, Scheme is mostly functional, but Common Lisp is multiparadigm.
Both are really Lisp 1.5 with some simple core semantics changes
and different libraries.
functional” but contain imperative features.
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.
– fxn
Michal S. wrote:
On 22/10/2007, Xavier N. [email protected] wrote:
On Oct 21, 2007, at 10:41 PM, Michal S. wrote:
I haven’t heard of an interpreter
of a procedural language written in a functional language (even an
experimental, let alone useful).
There’s Pugs:http://www.pugscode.orgThanks 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
Xavier N. wrote:
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.
On Tue, Oct 23, 2007 at 01:29:16PM +0900, M. Edward (Ed) Borasky wrote:
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 isa. 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.
On Wed, Oct 24, 2007 at 03:25:41AM +0900, Yohanes S. wrote:
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.
Thanks. That makes a lot more sense to me.
Chad P. [email protected] writes:
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 P. wrote:
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.
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.
Chad P. wrote:
On Tue, Oct 23, 2007 at 01:29:16PM +0900, M. Edward (Ed) Borasky wrote:
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.
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.
On Oct 24, 2007, at 4:53 AM, M. Edward (Ed) Borasky wrote:
functional, object oriented, imperative/procedural, and maybe even a
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.