I agree. Then again. It is easier to write some program in lisp beacuse
pretty much of the codes has been written for you. Like prolog. The
backtracking feature is already there. In my class, I wrote program to
solve the N-Queens problem with both Lisp and Prolog. You can see right
away the difference from those two and again from the rest of the
procedural languages.
and yes. Lisp sees data and function the same. but again, so does today's
object programming language like Ada, C++, and Pascal.
>In LISP, you can write a program in less than a page which will run
>other LISP programs. Try that in C.
>
>(Prolog also has these qualities, but it's of another flavor
>altogether)
>
>>
>>Oh! one interesting thing is that lisp is pretty well encapsulated it's
>>process. and then those guys who got only C in their computer classes
>>developed C and others developed other Structural languages. that's
meant
>>no more pretty encapsulation. But now, thing is going back. We have
>>visical this and visical that.
>>
>>Do you thing this is interesting?
--
______ Meow
\ OO / _/
:(__ =)
U \\
http://www.sci.csupomona.edu/~cchow
In article <··········@news1.h1.usa.pipeline.com>,
····@usa.pipeline.com(Boaz Chow) wrote:
>
> and yes. Lisp sees data and function the same. but again, so does today's
> object programming language like Ada, C++, and Pascal.
>
No, actually, C and C++ do *not* see functions and data as the same.
Here's a quote from _ANSI Common Lisp_ by Paul Graham.
"Suppose instead [of doing something trivial] you want to write a function
that takes a number n, and returns a function that adds n to its argument:
;Lisp
(defun addn (n)
#'(lambda (x)
(+ x n)))
What does addn look like in C? You just can't write it."
You can't write it in C++ either, because C++ doesn't have lexical
closures. Being able to return a pointer to a function is not the same
thing as lexical closures. Why, you may ask would one want them? Such a
question could only come from a C/C++ (or Pascal) programmer -another
quote from Graham's book:
"You have to think in language to write programs in it, and it's difficult
to want something you can't describe." C/C++ programmers are trained to
think in terms of what C/C++ can do, and since it can't do closures, they
don't know about them, or use them. Nevertheless, they're very useful. So
is a *real* macro system (which Lisp has), not the simple symbol
substitution that masquerades as macros in C/C++.
Sorry, C++ is a hack with object orientation added on as an afterthought
(worth noting in this context that the original name of C++ was "C with
objects."").
raf
Raffael Cavallaro (·······@tiac.net) wrote:
: In article <··········@news1.h1.usa.pipeline.com>,
: ····@usa.pipeline.com(Boaz Chow) wrote:
: >
: > and yes. Lisp sees data and function the same. but again, so does today's
: > object programming language like Ada, C++, and Pascal.
: >
: No, actually, C and C++ do *not* see functions and data as the same.
: Here's a quote from _ANSI Common Lisp_ by Paul Graham.
: "Suppose instead [of doing something trivial] you want to write a function
: that takes a number n, and returns a function that adds n to its argument:
: ;Lisp
: (defun addn (n)
: #'(lambda (x)
: (+ x n)))
: What does addn look like in C? You just can't write it."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Paul Graham knows what he's talking about, and I like his books.
: You can't write it in C++ either, because C++ doesn't have lexical
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: closures. Being able to return a pointer to a function is not the same
^^^^^^^^
: thing as lexical closures. Why, you may ask would one want them? Such a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: question could only come from a C/C++ (or Pascal) programmer -another
: quote from Graham's book:
: "You have to think in language to write programs in it, and it's difficult
: to want something you can't describe." C/C++ programmers are trained to
: think in terms of what C/C++ can do, and since it can't do closures, they
: don't know about them, or use them. Nevertheless, they're very useful. So
: is a *real* macro system (which Lisp has), not the simple symbol
: substitution that masquerades as macros in C/C++.
You may be slightly confused about the difference between C and C++.
Alternatively, you may have a very narrow, technical definition of
lexical closures -- if you want something that specifically bundles
up the lexical environment, then you're right, C++ doesn't do it that
way. But it's reasonably straightforward to write the equivalent
of ``addn'' in C++ -- see the example program after my sig. (BTW,
I think you're also right that closures can't be done in Pascal,
but I'm pretty sure that the C++ program below could be translated
into Ada95 without much difficulty. If you agree not to pick on
20-year-old strongly-typed languages, I'll try not to pick on
pre-Common-Lisp Lisp.:-)
Re. your remark about macros: yes, a real macro system would be nice.
Instead C and C++ programmers end up writing preprocessors and inline
functions and templates and cpp macros. This doesn't always do
everything we'd like -- there are some macros in Graham's books that
do things which would be hard to do in C++. So sometimes we end up
implementing higher-level languages in C. :-) :-)
Another thing that I really, really miss from Lisp is a run-time
environment which includes not only a debugger but a real
read-evaluate-print loop. Free Common Lisps have this, and free
debuggers like gdb are a pretty poor substitute.
: Sorry, C++ is a hack with object orientation added on as an afterthought
: (worth noting in this context that the original name of C++ was "C with
: objects."").
I am pretty impressed by Stroustrup's ability to maintain a certain
amount of elegance in an impressively backward-compatible language. I
am less impressed with the ability of the Common Lisp folks to do the
same, but YMMV. Or are you comparing C++'s kludginess to that of purer
languages like Scheme or ML?
Of course, if you just don't like statically-typed compiled languages,
you're unlikely to be impressed no matter what. So go on writing your
world-beating programs overnight and showing the world how much better
Lisp is for ordinary applications than the stupid languages everyone
else uses. (I like Graham's books, but that doesn't mean that I endorse
his more grandiose claims for Lisp.:-)
Bill Newman
·······@netcom.com
/* a rather literal translation of Paul Graham's ``addn'' example
into C++. (A more idiomatic translation would make ``Addn'' a
class derived from ``Float_Float_Closure'' and use the bare ``Addn''
constructor instead of a function called ``addn''.) */
#include <iostream.h>
class Float_Float_Closure {
/* If you had to use lots of closures, you'd probably want to define
something like ``template<class result, class arg1> Closure1''
as shorthand for closures of arity (?) one; then instead of
defining ``Float_Float_Closure'' you'd write Closure1<float,float>
and be done. */
public:
virtual float operator()(float x) = 0;
virtual ~Float_Float_Closure() {}
};
class Plus_Something : Float_Float_Closure {
private:
float something;
public:
Plus_Something(float something_arg) : something(something_arg) {}
float operator()(float x) { return x + something; }
};
Plus_Something* addn(float x)
{
return new Plus_Something(x);
}
int main()
{
Plus_Something plus1(1), plus2point4(2.4);
Plus_Something& plus9 = *addn(9);
cout << "plus1(12) = " << plus1(12)
<< ", plus2point4(11) = " << plus2point4(11)
<< ", plus9(3) = " << plus9(3) << "\n";
/* ``delete &plus9;'' here if you don't have GC. */
return 0;
}
From: Bill Vanyo
Subject: Re: no more lisp!
Date:
Message-ID: <DoMuny.2zI@abs.net>
·······@netcom.com (Bill Newman) wrote:
>Raffael Cavallaro (·······@tiac.net) wrote:
[much clipped]
>You may be slightly confused about the difference between C and C++.
>Alternatively, you may have a very narrow, technical definition of
>lexical closures -- if you want something that specifically bundles
>up the lexical environment, then you're right, C++ doesn't do it that
>way. But it's reasonably straightforward to write the equivalent
>of ``addn'' in C++ -- see the example program after my sig. (BTW,
>I think you're also right that closures can't be done in Pascal,
^^^^^^
>but I'm pretty sure that the C++ program below could be translated
>into Ada95 without much difficulty. If you agree not to pick on
>20-year-old strongly-typed languages, I'll try not to pick on
>pre-Common-Lisp Lisp.:-)
Pascal does implement functions passed as parameters as closures. But
there are, of course, no "upward closures", i.e. functions returned
from functions (only downward - passed to).
This is not true for Borlands in-name-only Pascal.
And Pascal programmers are generally unaware of what a closure is.
Ex. Pascal program to print out 10*15 multiplication table:
program TimesTable(input,output);
procedure DoTimes(procedure P(n:integer); T:integer);
var i:integer;
begin
for i:=1 to T do P(i);
end;
procedure PrintTable(numrows,numcols:integer);
procedure PrintRow(row:integer);
procedure PrintElement(column:integer);
begin
write(row*column:5);
end;
begin
DoTimes(PrintElement,numcols);
writeln;
end;
begin
DoTimes(PrintRow,numrows);
end;
begin
PrintTable(10,15);
end.
·····@ibcco.com (Bill Vanyo) wrote:
(example of lexical closure in c++ deleted)
Yes, you can write lexical closures in C++, but that immediately
raises the problem of polymorphic types. Writing mapcar, compose,
apply or using continuation passing style in C++ is virtually
impossible. Templates only push the problem back one level and it is
trivial to write a program that requires polymorphism beyond
what templates can provide.
From: Bill Vanyo
Subject: Re: no more lisp!
Date:
Message-ID: <DooBn1.Jvn@abs.net>
·····@capecod.net (Janet Bell) wrote:
>·····@ibcco.com (Bill Vanyo) wrote:
??????????????????????????????????
All this clipping of replies to clipped replies of replies to clipped
replies to ...etc., ... creates a mess.
I (Bill Vanyo) never wrote anything appearing below. Not that I
disagree, but I don't yet know enough about C++ that I would make
statements about it. (C, LISP, PASCAL, PROLOG, ??>SNOBOL4???, yes)
I'm sure this happens all the time though.
>(example of lexical closure in c++ deleted)
>Yes, you can write lexical closures in C++, but that immediately
>raises the problem of polymorphic types. Writing mapcar, compose,
>apply or using continuation passing style in C++ is virtually
>impossible. Templates only push the problem back one level and it is
>trivial to write a program that requires polymorphism beyond
>what templates can provide.
My apologies to Bill Vanyo for accidentally attributing
a statement to him. I was attempting to avoid reposting
a piece of C++ code that had been reposted several times
and I got overeager.
<G> did you see the point? I can write a same program with much less code
in lisp or prolog too.
O
>#include <iostream.h>
>
>class Float_Float_Closure {
>/* If you had to use lots of closures, you'd probably want to define
>something like ``template<class result, class arg1> Closure1''
>as shorthand for closures of arity (?) one; then instead of
>defining ``Float_Float_Closure'' you'd write Closure1<float,float>
>and be done. */
>public:
>virtual float operator()(float x) = 0;
>virtual ~Float_Float_Closure() {}
>};
>
>class Plus_Something : Float_Float_Closure {
>private:
>float something;
>public:
>Plus_Something(float something_arg) : something(something_arg) {}
>float operator()(float x) { return x + something; }
>};
>
>Plus_Something* addn(float x)
>{
>return new Plus_Something(x);
>}
>
>int main()
>{
>Plus_Something plus1(1), plus2point4(2.4);
>Plus_Something& plus9 = *addn(9);
>
>cout << "plus1(12) = " << plus1(12)
><< ", plus2point4(11) = " << plus2point4(11)
><< ", plus9(3) = " << plus9(3) << "\n";
>
>/* ``delete &plus9;'' here if you don't have GC. */
>
>return 0;
>}
--
______ Meow
\ OO / _/
:(__ =)
U \\
http://www.sci.csupomona.edu/~cchow
Bill,
a comparison of the two bodies of code makes it painfully clear that you
have to jump through hoops to get the equivalent of a closure because
*it's not part of the language.* It's also worth noting that even the more
idiomatic Closure1 template would still only give you closures of a
specific arity. In short, you have to roll your own, and its verbose and
ugly to do so.
Look, C/C++ have their strength, and that's speed of compiled code. But
the OO in C++ is an ugly, brittle add-on, and the strong typing of the
language makes C++ strength relative to C (i.e., run-time typing)
syntactically difficult (and ugly as well).
C++ is popular because it allowed a migration path from C to OO, and
because it produces fast compiled code, not because C++ is a good OO
language-- it's not.
Lest you get the impression I'm some sort of Lisp fanatic, I'm not. I just
think (as do many others) that C++ is an extraordinarily ugly and
cumbersome language because one has to do so much work (and thus run a
greatly increased risk of difficult to track errors) to yield results so
easily and elegantly accomplished in other languages (like, say,
Smalltalk, or Common Lisp).
Raf
;Lisp version
(defun addn (n)
#'(lambda (x)
(+ x n)))
----------------------------
//C++ version
#include <iostream.h>
class Float_Float_Closure {
public:
virtual float operator()(float x) = 0;
virtual ~Float_Float_Closure() {}
};
class Plus_Something : Float_Float_Closure {
private:
float something;
public:
Plus_Something(float something_arg) : something(something_arg) {}
float operator()(float x) { return x + something; }
};
Plus_Something* addn(float x)
{
return new Plus_Something(x);
}
int main()
{
Plus_Something plus1(1), plus2point4(2.4);
Plus_Something& plus9 = *addn(9);
cout << "plus1(12) = " << plus1(12)
<< ", plus2point4(11) = " << plus2point4(11)
<< ", plus9(3) = " << plus9(3) << "\n";
/* ``delete &plus9;'' here if you don't have GC. */
return 0;
}
oh! that is very good!
This is one of the best things about lisp!
You can design a compiler and other stuff... like simulation... with lisp
very easy.
I think this is the only thing that keeps lisp alive.
I know some operating system was written in lisp for testing the prototype.
and this is true for many compiler and of course algorthm too.
On Mar 20, 1996 21:43:41 in article <Re: no more lisp!>, ········@tiac.net
(Raffael Cavallaro)' wrote:
>In article <··········@news1.h1.usa.pipeline.com>,
>····@usa.pipeline.com(Boaz Chow) wrote:
>
>
>>
>> and yes. Lisp sees data and function the same. but again, so does
today's
>> object programming language like Ada, C++, and Pascal.
>>
>
>
>No, actually, C and C++ do *not* see functions and data as the same.
>
>Here's a quote from _ANSI Common Lisp_ by Paul Graham.
>
>"Suppose instead [of doing something trivial] you want to write a function
>that takes a number n, and returns a function that adds n to its argument:
>
>;Lisp
>(defun addn (n)
>#'(lambda (x)
>(+ x n)))
>
>What does addn look like in C? You just can't write it."
>
>You can't write it in C++ either, because C++ doesn't have lexical
>closures. Being able to return a pointer to a function is not the same
>thing as lexical closures. Why, you may ask would one want them? Such a
>question could only come from a C/C++ (or Pascal) programmer -another
>quote from Graham's book:
>"You have to think in language to write programs in it, and it's difficult
>to want something you can't describe." C/C++ programmers are trained to
>think in terms of what C/C++ can do, and since it can't do closures, they
>don't know about them, or use them. Nevertheless, they're very useful. So
>is a *real* macro system (which Lisp has), not the simple symbol
>substitution that masquerades as macros in C/C++.
>
>Sorry, C++ is a hack with object orientation added on as an afterthought
>(worth noting in this context that the original name of C++ was "C with
>objects."").
>
>raf
--
______ Meow
\ OO / _/
:(__ =)
U \\
http://www.sci.csupomona.edu/~cchow