Szymon <···@bar.baz> wrote in message news:<··············@eva.rplacd.net>...
> [ http://www.strout.net/python/pythonvslisp.html ]
>
> Very funny.
>
> "...
> raw scores * weight = adjusted scores
> Python LISP Python LISP
> Maturity 7 10 * 5 35 50
> Syntax 10 2 * 8 80 16
> Expressiveness 9 8 * 10 90 80
Apparently "propaganda" was not such a negative word until is was
associated with totalitarian governments around WW2. Before, it was
considered a reasonable way to sway public opinion. And with lisp, you
get to encounter a lot of it.
I enjoy weird forms like this, where the author has the problem, "How
do I make people swallow 'I like Python more' and make it sound
scientfic?" Well, the common way is to use quantifications. How can
you disagree? It's science! Of course, it's also the worst form of
numerology...
Incidentally, some of us might have heard that Leonhard Euler was once
asked by Catherine the Great to shut up an atheist, so they engaged in
a debate, and Leonhard advanced upon him and said with great
conviction:
"Sir, a + bn/n = x, hence God exists; reply!"
His opponent didn't know how to respond, and eventually left the
country humiliated.
MfG,
Tayssir
Szymon wrote:
>
> [ http://www.strout.net/python/pythonvslisp.html ]
> raw scores
> Python LISP
> Syntax 10 2
Hehe, what syntax? In Lisp all I have to learn is ( ) and ' and I
suddently know 90% of the language syntax. That could be considered the
entire syntax if it wasn't for read macros... which leads me to
> Extensibility 10 7
Has this person ever programmed Lisp? I find that Lisp is *the* most
extensible language I've ever worked with. I would, personally, rate
Python extensibility at a 0. I can overload operators -- but then
wouldn't that make C++ extensible? Note: I'm not a Python guru, so
anyone here who does know about Python's extensibility features, I'd be
interested in learning about them.
> Open Source 10 0
I guess clisp doesn't count?
> Documentation 8 7
Obviously has never seen the HyperSpec. A search on Amazon for "Lisp
programming" returned 2355 books. "Python programming" returned 2287
results... hmm.
> Mac Integration 8 7
LispWorks? OpenMCL? DigitTool? c-lisp?
> Available Modules 10 4
> Current Code 1 10
How can current code be 10 and available modules be a 4?
Oh well, I'm probably just feeding the troll and should stop. I just
woke up and this happened to catch me while still rubbing my eyes ;)
Jeff
--
Progress in computer technology is waiting for people to stop
re-inventing the wheel.
- Dr. William Bland (comp.lang.lisp)
Jeff wrote:
> Szymon wrote:
>
>
>>[ http://www.strout.net/python/pythonvslisp.html ]
>
>
>> raw scores
>> Python LISP
>
>
>>Syntax 10 2
>
>
> Hehe, what syntax?
infix vs sexpr. Every line item scoring is explained in detail at the
URL above. In the 1999 article.
>>Extensibility 10 7
>
>
> Has this person ever programmed Lisp?
He was proposing a switch from MCL to Python for their work. He was
talking about ease of integration with C.
>>Open Source 10 0
>
>
> I guess clisp doesn't count?
Nope. He was specifically comparing Python with MCL, not really Lisp as
a category.
>>Mac Integration 8 7
>
>
> LispWorks? OpenMCL? DigitTool? c-lisp?
He was worried about MCL not yet being ready for OS X. This was in 1999,
recall.
>
>
>>Available Modules 10 4
>>Current Code 1 10
>
>
> How can current code be 10 and available modules be a 4?
They were using MCL at the time. Current code is /their/ code.
kt
Kenny Tilton <·······@nyc.rr.com> wrote:
> infix vs sexpr. Every line item scoring is explained in detail at the
> URL above. In the 1999 article.
Yes. Some items still remain mystifying, though:
"LISP's most-used datatype is the list, but strings are also a basic
type, and dictionaries are supported to some degree through
association lists."
What happened to hash-tables?
"LISP can achieve a limited sort of exception handling through
"catch" and related operators, but it is lacking in two important ways: (1)
errors generated by built-in or most library functions cannot be
caught, and (2) one must nest "catch" blocks for every type of error
that might be thrown; there is no way to list several error types at
once or have a catch-all category. These limit the usefulness of
LISP's exception handling in practice."
I can but boggle. 1999 is post-ansi. Conditions are in the spec. Or
was MCL exceptionally lacking in this respect? I'd be surprised.
"LISP uses CLOS, which is a fairly (but not completely) standard
object extension to LISP."
Ditto. Oh well, maybe he means MOP. Did Python have MOP in 1999?
It goes on and on. I was going to say several nasty things, but then I
realized that the author doesn't appear to link to the article from
his own site -- so being nasty would be just nasty . Sleeping dogs, old
mistakes, etc.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
·········@random-state.net writes:
> [...]
> 1999 is post-ansi. Conditions are in the spec. Or
> was MCL exceptionally lacking in this respect? I'd be surprised.
I remember using a version of MCL from a few years before 1999,
which wasn't ANSI CL, but CLtL2, so it did have conditions and CLOS.
(Unfortunately, I don't remember the release number, but I remember
that it ran on MacOS 7.5.)
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
From: David Golden
Subject: what happened to hash-tables (was: Re: troll's food (python vs lisp))
Date:
Message-ID: <BNm1d.27376$Z14.9319@news.indigo.ie>
·········@random-state.net wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>> infix vs sexpr. Every line item scoring is explained in detail at the
>> URL above. In the 1999 article.
>
> Yes. Some items still remain mystifying, though:
>
> "LISP's most-used datatype is the list, but strings are also a basic
> type, and dictionaries are supported to some degree through
> association lists."
>
> What happened to hash-tables?
>
For a python person, CL hash tables are a poor substitute for python dictionaries as
Common Lisp hash tables aren't print/read round-trippable in a _standard_ way, whereas
dictionary literals work in python and are very commonplace - e.g. at the python repl:
>>> { 1 : "no" , 2 : "software" , 3 : "patents" }
{1: 'no', 2: 'software', 3: 'patents'}
alists thus come closer to the idiomatic use of dictionaries in python, but I guess
intrinsically kinda suck for anything beyond a few elements that isn't going to be just
iterated over.
No doubt there's a reason lists and arrays have literal syntaxes and hashtables don't
in CL, and it has to do with eq hashtables, probably.
This subject has come up on c.l.l. threads many times before, probably years before I
even had usenet access. Here's a few relatively recent ones: B. Haible + KMP at
one stage proposed a syntax [1], one year later the issue was raised again [2], I mentioned
it in 2003 in the middle of one of /those/ threads [3]. And there's the whole "xapping"
malarkey of yore for yore = CLTL2.
[1]
From: ······@clisp.cons.org (Bruno Haible)
Subject: *print-readably* and hash tables
Date: 1998/04/14
Message-ID: <············@nz12.rz.uni-karlsruhe.de>#1/1
Organization: University of Karlsruhe, Germany
Newsgroups: comp.lang.lisp
[2]
From: ············@tzd.dont.telekom.spam.de.me (Joerg-Cyril Hoehle)
Subject: Why can't a hash table be read/written as #S(HASH-TABLE ...)?
Date: 1999/04/08
Message-ID: <···············@tzd.dont.telekom.spam.de.me>#1/1
Organization: Deutsche Telekom AG
Newsgroups: comp.lang.lisp
[3]
From: ············@oceanfree.net (David Golden)
Subject: Re: Why some people think that Scheme is not a Lisp
Date: 6 Sep 2003 15:09:56 -0700
Message-ID: <···························@posting.google.com>
Organization: http://groups.google.com/
Newsgroups: comp.lang.lisp
>>>>> "David" == David Golden <············@oceanfree.net> writes:
David> For a python person, CL hash tables are a poor substitute
David> for python dictionaries as Common Lisp hash tables aren't
David> print/read round-trippable in a _standard_ way, whereas
David> dictionary literals work in python and are very commonplace
David> - e.g. at the python repl:
>>>> { 1 : "no" , 2 : "software" , 3 : "patents" }
David> {1: 'no', 2: 'software', 3: 'patents'}
Hrm. Is this really such a big deal?
It is pretty trivial to accomplish this sort of transformation, so why
should this be a standard? It seems like something that everyone
writes for their own set of tools. It's fine if there is a standard,
but it's hardly a bridge-burner.
Besides, many of the things which you might want in a dictionary are
not easily printable anyway. If you can't print the contents,
dictionary printing won't matter.
General-purpose persistence is interesting, but some approaches to
that have been mentioned here recently.
Tim Lavoie <········@spamcop.net> writes:
> >>>>> "David" == David Golden <············@oceanfree.net> writes:
>
> David> For a python person, CL hash tables are a poor substitute
> David> for python dictionaries as Common Lisp hash tables aren't
> David> print/read round-trippable in a _standard_ way, whereas
> David> dictionary literals work in python and are very commonplace
> David> - e.g. at the python repl:
> >>>> { 1 : "no" , 2 : "software" , 3 : "patents" }
> David> {1: 'no', 2: 'software', 3: 'patents'}
>
> Hrm. Is this really such a big deal?
>
Why not write the input as a list, and use a trivial function
to create a hashtable from it, and ,if necessary, a function
to print it back?
(defparameter *hash-food*
'(
"wheel" 4
"wiper" 2
"motor" 1
"door" 4
"tank" 1
"mirror" 3
))
(defun swallow (food)
(let ((hash (make-hash-table :test 'equal)))
(loop for (key val) on food by #'cddr
do (setf (gethash key hash) val))
hash))
(defun vomit (some-hash)
(format t " '(~%")
(maphash (lambda (key val)
(format t " ~s ~s~%" key val))
some-hash)
(format t ")~%"))
CL-USER> (defparameter *x* (swallow *hash-food*))
*X*
CL-USER> (vomit *x*)
'(
"wheel" 4
"wiper" 2
"motor" 1
"door" 4
"tank" 1
"mirror" 3
)
NIL
CL-USER>
Tim Lavoie wrote:
> Hrm. Is this really such a big deal?
>
No, it's not a huge deal. Just a vague niggle.
> Besides, many of the things which you might want in a dictionary are
> not easily printable anyway. If you can't print the contents,
> dictionary printing won't matter.
>
I think that is a particularly weak argument - consider
"many of the things which you might want in a (list|array) are
not easily printable anyway."
So one could print the hashtable and do the obvious
#H((blah #<UNPRINTABLE-OBJECT 1>) (bloo #<UNPRINTABLE-OBJECT 2>))
thing if they objects aren't easily printable
[#H just for sake of argument]
>>>>> "David" == David Golden <············@oceanfree.net> writes:
David> Tim Lavoie wrote:
>> Hrm. Is this really such a big deal?
>>
David> No, it's not a huge deal. Just a vague niggle.
Ah, OK. Vague niggles are fine, but I got the impression that it was
more to some folks, and didn't quite see why.
>> Besides, many of the things which you might want in a
>> dictionary are not easily printable anyway. If you can't print
>> the contents, dictionary printing won't matter.
>>
David> I think that is a particularly weak argument - consider
David> "many of the things which you might want in a (list|array)
David> are not easily printable anyway."
David> So one could print the hashtable and do the obvious
David> #H((blah #<UNPRINTABLE-OBJECT 1>) (bloo
David> #<UNPRINTABLE-OBJECT 2>)) thing if they objects aren't
David> easily printable [#H just for sake of argument]
Heh. Don't get me wrong, I'm all for being able to print and read
whatever I've got. It's just that the case given, not being able to
read and write dictionaries, may already need more thought for a
particular case than having a standard syntax. It's the contents, not
the hash table which are more likely a challenge in a lot of cases.
Python's pickle and shelve are handy tools to have around, so I've
been following with interest some of the discussions about Lisp
persistence. If I recall correctly, Zope's ZODB used pickle for
everything; at the least, it demonstrates the value of being able to
write objects out in some form and get them back.
Hash tables are just an easier case than many things, as they map
nicely into lists for reading and writing. It is easy to get spoiled
by having Lisp already provide much of what is needed. If I need to
write a bit of transformation to a form I can simply print and read,
I'm not going to moan too much.
Cheers,
Tim
From: marco
Subject: Re: what happened to hash-tables
Date:
Message-ID: <m2zn3tsu41.fsf@bese.it>
David Golden <············@oceanfree.net> writes:
> For a python person, CL hash tables are a poor substitute for python
> dictionaries as Common Lisp hash tables aren't print/read
> round-trippable in a _standard_ way, whereas dictionary literals
> work in python and are very commonplace - e.g. at the python repl:
>>>> { 1 : "no" , 2 : "software" , 3 : "patents" }
> {1: 'no', 2: 'software', 3: 'patents'}
you forgot this one (i saw your emphasis on _standard_, so maybe this
isn't the kind of answer you're looking for):
http://groups.google.com/groups?selm=3222747467111424%40naggum.net
hash tables are great, but 1) providing a convient syntax for
initializing hash tables is way over-rated and 2) printing hash tables
so that all elements are written out explicitly becomes unweidly as
soon as there are more than 10 elements (very often the
case). python's (and perl's) hash table syntax in a solution to a
problem which doesn't exist.
having said that, this has always irked me (i'd would love to know
that python supports a way to write this and i'm just ignorant):
··@codoxime ~/lisp/sbcl $ python
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> hash = { 1 : "whatever" }
>>> hash
{1: 'whatever'}
>>> hash[1] = hash
>>> hash
{1: {...}}
>>> {1: {...}}
File "<string>", line 1
{1: {...}}
^
SyntaxError: invalid syntax
>>>
what's python's equivalent of #1={ 1 => #1# } ?
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
marco <··@bese.it> writes:
> hash tables are great, but 1) providing a convient syntax for
> initializing hash tables is way over-rated and 2) printing hash tables
> so that all elements are written out explicitly becomes unweidly as
> soon as there are more than 10 elements (very often the
> case). python's (and perl's) hash table syntax in a solution to a
> problem which doesn't exist.
The special case of creating a new empty dictionary[1]
is of some importance, and it's certainly nicer to write
"d = {}" than "(let ((d (make-hash-table))) ...)"; still
more so if, e.g., you want to be able to use strings as
keys (a very common case), when you need to specify the
test for the hash-table too.
[1] I prefer this terminology to "hash table" in contexts
where the implementation isn't specially important.
Perl hashes, Python dicts, CL hash-tables and C++
maps are all dictionaries.
But it's hardly a lot of work to write
(defmacro dict ((&rest options) &rest inits)
(let ((name (gensym)))
`(let ((,name (make-hash-table . ,options)))
,@(loop for (key value) on inits by #'cddr collect
`(setf (gethash ,key ,name) ,value))
,name)))
and then (dict ()) or (dict (:test #'equal) "foo" 1 "bar" 2)
aren't too bad.
> having said that, this has always irked me (i'd would love to know
> that python supports a way to write this and i'm just ignorant):
...
> what's python's equivalent of #1={ 1 => #1# } ?
Doesn't have one. I think Pythonistas would say the same
about circular literals as you did about dictionary literals.
I think they'd be at least as right as you :-).
--
Gareth McCaughan
.sig under construc
From: marco
Subject: Re: what happened to hash-tables
Date:
Message-ID: <m2k6ux3tey.fsf@bese.it>
Gareth McCaughan <················@pobox.com> writes:
> Doesn't have one. I think Pythonistas would say the same
> about circular literals as you did about dictionary literals.
> I think they'd be at least as right as you :-).
touche' :)
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
I've done a bit of investigation of phython and found
the dictionary feature VERY limiting as compared
to LISP hash tables.
1) LISP hash tables alow any LISP object as a key
Python dictionaries only allow basic types such as integer, string
etc... you cannot make a dictionary or a list be a hash key.
LISP allows this with now problem.
2) LISP hash tables allow you to specify the equivalence function
be used on table access; i do not believe Python does.
3) LISP allows the hash table itself to know what to do when
you try to access a key that is not in the table. In Python
the calling function must handle the exception of the key is
missing.
-jim
David Golden wrote:
> ·········@random-state.net wrote:
>
>
>>Kenny Tilton <·······@nyc.rr.com> wrote:
>>
>>
>>>infix vs sexpr. Every line item scoring is explained in detail at the
>>>URL above. In the 1999 article.
>>
>>Yes. Some items still remain mystifying, though:
>>
>> "LISP's most-used datatype is the list, but strings are also a basic
>> type, and dictionaries are supported to some degree through
>> association lists."
>>
>>What happened to hash-tables?
>>
>
>
> For a python person, CL hash tables are a poor substitute for python dictionaries as
> Common Lisp hash tables aren't print/read round-trippable in a _standard_ way, whereas
> dictionary literals work in python and are very commonplace - e.g. at the python repl:
>
>>>>{ 1 : "no" , 2 : "software" , 3 : "patents" }
>
> {1: 'no', 2: 'software', 3: 'patents'}
>
> alists thus come closer to the idiomatic use of dictionaries in python, but I guess
> intrinsically kinda suck for anything beyond a few elements that isn't going to be just
> iterated over.
>
> No doubt there's a reason lists and arrays have literal syntaxes and hashtables don't
> in CL, and it has to do with eq hashtables, probably.
>
> This subject has come up on c.l.l. threads many times before, probably years before I
> even had usenet access. Here's a few relatively recent ones: B. Haible + KMP at
> one stage proposed a syntax [1], one year later the issue was raised again [2], I mentioned
> it in 2003 in the middle of one of /those/ threads [3]. And there's the whole "xapping"
> malarkey of yore for yore = CLTL2.
>
>
> [1]
> From: ······@clisp.cons.org (Bruno Haible)
> Subject: *print-readably* and hash tables
> Date: 1998/04/14
> Message-ID: <············@nz12.rz.uni-karlsruhe.de>#1/1
> Organization: University of Karlsruhe, Germany
> Newsgroups: comp.lang.lisp
>
> [2]
> From: ············@tzd.dont.telekom.spam.de.me (Joerg-Cyril Hoehle)
> Subject: Why can't a hash table be read/written as #S(HASH-TABLE ...)?
> Date: 1999/04/08
> Message-ID: <···············@tzd.dont.telekom.spam.de.me>#1/1
> Organization: Deutsche Telekom AG
> Newsgroups: comp.lang.lisp
>
> [3]
>
> From: ············@oceanfree.net (David Golden)
> Subject: Re: Why some people think that Scheme is not a Lisp
> Date: 6 Sep 2003 15:09:56 -0700
> Message-ID: <···························@posting.google.com>
> Organization: http://groups.google.com/
> Newsgroups: comp.lang.lisp
>
>
Jim Newton wrote:
> I've done a bit of investigation of phython and found
> the dictionary feature VERY limiting as compared
> to LISP hash tables.
>
> 1) LISP hash tables alow any LISP object as a key
> Python dictionaries only allow basic types such as integer, string
> etc... you cannot make a dictionary or a list be a hash key.
> LISP allows this with now problem.
Really? I would have expected Python to be similar to Java in this
regard, allowing objects to override an equality predicate and a
corresponding hash method. Then you could use any objects as keys.
> 2) LISP hash tables allow you to specify the equivalence function
> be used on table access; i do not believe Python does.
ANSI Common Lisp only allows you to choose from four different fixed
equivalence predicates. (Concrete implementation may allow more of those.)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: what happened to hash-tables
Date:
Message-ID: <87d60jxs0l.fsf@qrnik.zagroda>
Jim Newton <·····@rdrop.com> writes:
> 1) LISP hash tables alow any LISP object as a key
> Python dictionaries only allow basic types such as integer, string
> etc... you cannot make a dictionary or a list be a hash key.
> LISP allows this with now problem.
It's not quite true. You can't use builtin mutable types, but you can
use objects of custom classes (which implement hashing and equality in
whatever way they want). And you can use a tuple instead of a list.
> 2) LISP hash tables allow you to specify the equivalence function
> be used on table access; i do not believe Python does.
But there is little reason to do it, as the default equality does the
right thing for most types imaginable as hash keys.
> 3) LISP allows the hash table itself to know what to do when
> you try to access a key that is not in the table. In Python
> the calling function must handle the exception of the key is
> missing.
Not necessarily by catching the exception: there are methods get and
setdefault which wrap common usage patterns of handling missing keys.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Jim Newton <·····@rdrop.com> writes:
> I've done a bit of investigation of python and found
> the dictionary feature VERY limiting as compared
> to LISP hash tables.
>
> 1) LISP hash tables alow any LISP object as a key
> Python dictionaries only allow basic types such as integer, string
> etc... you cannot make a dictionary or a list be a hash key.
> LISP allows this with now problem.
Not correct; used-defined types can be hash keys,
and you get to choose when they're considered equivalent.
Indeed, you can't use dictionaries and lists, but you
can use tuples.
In Lisp, you can use (say) #'equal hash tables and
get useful results with lists; hash tables (as keys)
are compared using EQ, and so are all user-defined
objects. Or you can use #'equalp hash tables and get
hash tables and structs compared fieldwise, but
strings are now compared case-blindly. And instances
of instances of STANDARD-CLASS are still compared
using EQ.
Neither of these seems obviously better than the
other. It seems fairly clear to me that neither
is optimal, either; you want the ability to make
hash tables using any hash function (plus equality
tester) that you like, and you want the ability
to specify the behaviour of the language's standard
equality predicate(s) more or less ad lib for
user-defined classes.
> 2) LISP hash tables allow you to specify the equivalence function
> be used on table access; i do not believe Python does.
Lisp hash tables allow you to choose from a small
fixed set of equivalence functions, independently
for each hash table. Python dictionaries allow you
to choose at will how your own objects will compare
for hashing purposes, but the answer has to be the
same for all hash tables. Python's defaults work
(I think) a little more smoothly than Lisp's.
Again, neither of these seems obviously better
than the other, and I'm pretty sure neither is
optimal. See above.
> 3) LISP allows the hash table itself to know what to do when
> you try to access a key that is not in the table. In Python
> the calling function must handle the exception of the key is
> missing.
I don't think I understand this statement. In what
sense does Lisp allow the hash table itself to know
what to do?
In Python, you can access the dictionary using []
and handle the exception yourself, or you can access
it using .get() and have a default value used. Or
you can use .setdefault() and get a default value
both returned and stored when the key isn't found.
It looks to me as if Python has the advantage here.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> > 2) LISP hash tables allow you to specify the equivalence function
> > be used on table access; i do not believe Python does.
>
> Lisp hash tables allow you to choose from a small
> fixed set of equivalence functions, independently
> for each hash table. Python dictionaries allow you
> to choose at will how your own objects will compare
> for hashing purposes, but the answer has to be the
> same for all hash tables. Python's defaults work
> (I think) a little more smoothly than Lisp's.
>
> Again, neither of these seems obviously better
> than the other, and I'm pretty sure neither is
> optimal. See above.
For those interested:
http://www.cliki.net/Proposed%20Extensions%20To%20ANSI
Starting at: "Extend MAKE-HASH-TABLE to take any function as an
equality predicate, and open it up so users can write their own hash
functions. These will put CLOS objects on an equal footing with
built-in objects."
I wonder if the standards guys felt really decadent about putting in a
hashtable, since CL was already huge by the standards of the day (ha
ha, how times change), so it wasn't bulked up.
I'm curious how much faddishness remained in the CL standard.
MfG,
Tayssir
--
Observations of a circus which travelled to Iraq (note the left
sidebar):
http://www.circus2iraq.org/updates.asp
From: Christopher C. Stacy
Subject: Re: what happened to hash-tables
Date:
Message-ID: <umzzmrip0.fsf@news.dtpq.com>
"Tayssir John Gabbour" <···········@yahoo.com> writes:
> Gareth McCaughan wrote:
> > > 2) LISP hash tables allow you to specify the equivalence function
> > > be used on table access; i do not believe Python does.
> >
> > Lisp hash tables allow you to choose from a small
> > fixed set of equivalence functions, independently
> > for each hash table. Python dictionaries allow you
> > to choose at will how your own objects will compare
> > for hashing purposes, but the answer has to be the
> > same for all hash tables. Python's defaults work
> > (I think) a little more smoothly than Lisp's.
> >
> > Again, neither of these seems obviously better
> > than the other, and I'm pretty sure neither is
> > optimal. See above.
>
>
> For those interested:
> http://www.cliki.net/Proposed%20Extensions%20To%20ANSI
>
> Starting at: "Extend MAKE-HASH-TABLE to take any function as an
> equality predicate, and open it up so users can write their own hash
> functions. These will put CLOS objects on an equal footing with
> built-in objects."
>
> I wonder if the standards guys felt really decadent about putting in a
> hashtable, since CL was already huge by the standards of the day
The Lisp Machine had a extensible hash tables like you want.
(Of course.)
is this true? I was under the impression that i could
specify any function i want as the equivalence function
for a given hash table when i create it. Of course
it only makes sense if the function accepts two
arguments. But what does the writer here mean with
"a small set of equivalence functions"?
-jim
>>>>2) LISP hash tables allow you to specify the equivalence function
>>>> be used on table access; i do not believe Python does.
>>>
>>>Lisp hash tables allow you to choose from a small
>>>fixed set of equivalence functions, independently
>>>for each hash table.
>>
From: Bulent Murtezaoglu
Subject: Re: what happened to hash-tables
Date:
Message-ID: <87acvm5q4t.fsf@p4.internal>
>>>>> "JN" == Jim Newton <·····@rdrop.com> writes:
JN> is this true? I was under the impression that i could specify
JN> any function i want as the equivalence function for a given
JN> hash table when i create it. [...]
No, not in ANSI cl:
http://www.lisp.org/HyperSpec/Body/fun_make-hash-table.html
You can anly use eq, eql, equal, equalp.
Some (most?) implementations have a facility for you to use other
tests. Of course there's nothing to prevent you from writing your
own make-hash-table*, gethash* etc. that does as you wish.
cheers,
BM
Jim Newton wrote:
>>>>> 2) LISP hash tables allow you to specify the equivalence function
>>>>> be used on table access; i do not believe Python does.
>>>>
>>>> Lisp hash tables allow you to choose from a small
>>>> fixed set of equivalence functions, independently
>>>> for each hash table.
> is this true? I was under the impression that i could
> specify any function i want as the equivalence function
> for a given hash table when i create it. Of course
> it only makes sense if the function accepts two
> arguments. But what does the writer here mean with
> "a small set of equivalence functions"?
As Bulent Murtezaoglu wrote, what I meant was the
set {eq,eql,equal,equalp}. It would be nice if it
were possible to pick any equality predicate (supplying,
of course, a compatible hash function to go with it),
but standard CL doesn't let you do that.
--
Gareth McCaughan
.sig under construc
From: Duane Rettig
Subject: Re: what happened to hash-tables
Date:
Message-ID: <47jqpzlv6.fsf@franz.com>
Gareth McCaughan <················@pobox.com> writes:
> Jim Newton wrote:
>
> >>>>> 2) LISP hash tables allow you to specify the equivalence function
> >>>>> be used on table access; i do not believe Python does.
> >>>>
> >>>> Lisp hash tables allow you to choose from a small
> >>>> fixed set of equivalence functions, independently
> >>>> for each hash table.
>
> > is this true? I was under the impression that i could
> > specify any function i want as the equivalence function
> > for a given hash table when i create it. Of course
> > it only makes sense if the function accepts two
> > arguments. But what does the writer here mean with
> > "a small set of equivalence functions"?
>
> As Bulent Murtezaoglu wrote, what I meant was the
> set {eq,eql,equal,equalp}. It would be nice if it
> were possible to pick any equality predicate (supplying,
> of course, a compatible hash function to go with it),
> but standard CL doesn't let you do that.
But of course each implementation is free to extend the interface,
and the result can be precisely this freedom to specify any test
function and/or hash generator:
http://www.franz.com/support/documentation/6.2/doc/implementation.htm#cl-make-hash-table-2
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> But of course each implementation is free to extend the interface,
> and the result can be precisely this freedom to specify any test
> function and/or hash generator:
>
> http://www.franz.com/support/documentation/6.2/doc/implementation.htm#cl-make-hash-table-2
It's not good enough. People have been burned before with proprietary
extensions (when the vendor disappears or change his specifications
without notice). We won't be using vendor specific extensions anymore
in this life!
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
From: Duane Rettig
Subject: Re: what happened to hash-tables
Date:
Message-ID: <4pt4hf0l4.fsf@franz.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> Duane Rettig <·····@franz.com> writes:
> > But of course each implementation is free to extend the interface,
> > and the result can be precisely this freedom to specify any test
> > function and/or hash generator:
> >
> > http://www.franz.com/support/documentation/6.2/doc/implementation.htm#cl-make-hash-table-2
>
> It's not good enough. People have been burned before with proprietary
> extensions (when the vendor disappears or change his specifications
> without notice).
Yes, of course, one always takes a chance when going outside of
a specification. If you don't trust your vendor not to burn
you, then you should always stay within the spec, or else change
vendors.
> We won't be using vendor specific extensions anymore
> in this life!
I'm not quite sure of the scope of this rather strong statement.
Who is "we", and which extensions? And life expectancy is
increasing all the time - are you sure you want your statement
to be that strong and for such a long time?
If you're still speaking only of hash-table extensions, ok,
just don't use them; hash-tables are easy to implement without
using existing implementations, although they're not especially
easy to implement efficiently, including protection from other
extensions such as multiprocessing.
However, if you are talking about _all_ extensions, then you
have a tough road ahead of you; there are many extensions you
might use without realizing that they are vendor-specific.
Consider the UFFI, which is built entirely on extensions.
If you use the UFFI, then you are at risk of your vendor
changing their FFI incompatibly and breaking the UFFI.
Consider multiprocessing, which is an ever changing world of
extensions, dangerous in part because it affects so many areas
of the standard including hash-tables.
Consider the MOP, which is an extension for any vendor which
provides it.
Consider Gray streams, which is an extension.
But perhaps I am reading your statement too literally; perhaps
you can clarify what you meant and set me straight.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> > It's not good enough. People have been burned before with proprietary
> > extensions (when the vendor disappears or change his specifications
> > without notice).
>
> Yes, of course, one always takes a chance when going outside of
> a specification. If you don't trust your vendor not to burn
> you, then you should always stay within the spec, or else change
> vendors.
>
> > We won't be using vendor specific extensions anymore
> > in this life!
>
> I'm not quite sure of the scope of this rather strong statement.
> Who is "we",
Me and any customer that would listen to my advice.
> and which extensions?
Vendor specific extensions.
> And life expectancy is
> increasing all the time - are you sure you want your statement
> to be that strong and for such a long time?
Yes. I would have written "ever" instead, but I don't believe in
reincarnation anyway, so it's as good.
> However, if you are talking about _all_ extensions, then you
> have a tough road ahead of you; there are many extensions you
> might use without realizing that they are vendor-specific.
>
> Consider the UFFI, which is built entirely on extensions.
> If you use the UFFI, then you are at risk of your vendor
> changing their FFI incompatibly and breaking the UFFI.
UFFI is not vendor specific, since it runs on a range of
implementations including cmucl, sbcl, alegro, and soon clisp.
> Consider multiprocessing, which is an ever changing world of
> extensions, dangerous in part because it affects so many areas
> of the standard including hash-tables.
Yes. That's why I don't use multitasking. It's not even available on
some implementations like clisp.
> Consider the MOP, which is an extension for any vendor which
> provides it.
>
> Consider Gray streams, which is an extension.
Both MOP and Gray streams are not vendor specific extensions. They're
specified out of vendors, and implemented by several vendors. So they
could be used. But I doubt they're often needed: for my first use of
Gray streams, I eventually implemented the feature
(with-input-from-byte-vector and with-output-to-byte-vector) without
them, both because that would have mean to disqualify too many
packages of my as non-pure Common-Lisp and because there are small
differences in implementations that are untasty (unsurprizingly, since
it's not an ANSI standard (yet)).
> But perhaps I am reading your statement too literally; perhaps
> you can clarify what you meant and set me straight.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
On Mon, 20 Sep 2004 21:29:39 +0200, Pascal Bourguignon wrote:
[Big snip]
> it's not an ANSI standard (yet)).
This just reminded me to ask a question I've been thinking about for a
while. I know the status of Scheme standardisation (afaik it all stalled
after R5RS, with little hope of restarting - all ongoing work seems to be
in the form of SRFIs). I don't know anything at all about CL
standardisation though (except that the ANSI standard exists!). Is there
any kind of ongoing process to extend and update the ANSI standard for CL?
I'm aware of the various lists on Cliki of things that people would want
in a new standard, but I can't find anything about the process itself. Is
it driven by ANSI? Or does ANSI wait for people to say that a given
standard should be updated?
Thanks for any responses - I probably won't get a chance to respond to
them for a while as I'm catching a plane back to the UK in a couple of
hours.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
On Mon, 20 Sep 2004 20:15:44 +0000, William Bland wrote:
> This just reminded me to ask a question I've been thinking about for a
> while. I know the status of Scheme standardisation (afaik it all stalled
> after R5RS, with little hope of restarting - all ongoing work seems to be
> in the form of SRFIs).
Oops, I should have made sure I knew what I was talking about before I
posted. Apparently (according to www.schemers.org) there is a new
standardisation process under way. Interesting stuff.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland wrote:
> I know the status of Scheme standardisation (afaik it all stalled
> after R5RS, with little hope of restarting - all ongoing work seems to be
> in the form of SRFIs). I don't know anything at all about CL
> standardisation though (except that the ANSI standard exists!).
Nick Levine from the ALU is going to talk about the CLRFI (that's Common
Lisp's variant of SRFI) at the Amsterdam Lisp meeting next Sunday:
http://www.xs4all.nl/~alemmens/lisp/meetings/september-2004.html
> I'm catching a plane back to the UK in a couple of hours.
You're from the UK? Maybe you can catch another plane to Amsterdam
this weekend and attend the meeting.
Arthur
Pascal Bourguignon <····@mouse-potato.com> wrote:
+---------------
| Duane Rettig <·····@franz.com> writes:
| > But of course each implementation is free to extend the interface,
| > and the result can be precisely this freedom to specify any test
| > function and/or hash generator:
| >
| http://www.franz.com/support/documentation/6.2/doc/implementation.htm#cl-make-hash-table-2
|
| It's not good enough. People have been burned before with proprietary
| extensions (when the vendor disappears or change his specifications
| without notice). We won't be using vendor specific extensions anymore
| in this life!
+---------------
Well, that's a rather absolutist posture. The Franz hash/test
function extension is quite similar to the CMUCL (and probably
SBCL too, though I haven't looked) DEFINE-HASH-TABLE-TEST extension
(which likewise also defines a hash function to pair with the test),
and the syntactic differences could easily be papered over with
feature tests. So if you *need* it, why not use it?
-Rob
p.s. The Franz extension for weak keys/values looks like a
reasonable & useful one for people to copy in other implementations
as well...
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Tayssir John Gabbour wrote:
> I wonder if the standards guys felt really decadent about putting in a
> hashtable, since CL was already huge by the standards of the day (ha
> ha, how times change), so it wasn't bulked up.
You already need hashtables anyway internally for implementing Common
Lisp (-> package system), so it doesn't cost that much to standardize
them. EQUALP already works well with structures, so the current state of
affairs is probably just because noone put energy into integrating CLOS
and hashtables.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Tayssir John Gabbour wrote:
>
>> I wonder if the standards guys felt really decadent about putting in a
>> hashtable, since CL was already huge by the standards of the day (ha
>> ha, how times change), so it wasn't bulked up.
>
> You already need hashtables anyway internally for implementing Common
> Lisp (-> package system), so it doesn't cost that much to standardize
> them. EQUALP already works well with structures, so the current state
> of affairs is probably just because noone put energy into integrating
> CLOS and hashtables.
Or maybe because the people on the committee were not quite sure how
exactly to standardize this (using any user-supplied function as the
equality test of an ANSI Common Lisp hash table), and they did not
want to set anything in stone that might turn out to be half-baked.
As it has been pointed out many times, designing library interfaces
(including the constraints that apply) requires lots of effort as
well as sufficient experience with prototype library designs.
I believe it is very likely that Kent Pitman (or someone else) has
commented on how hash tables are standardized in ANSI Common Lisp,
but unfortunately I don't have the time to search for appropriate
posts now...
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
From: Christopher C. Stacy
Subject: Re: what happened to hash-tables
Date:
Message-ID: <uy8j5zjqa.fsf@news.dtpq.com>
Vassil Nikolov <········@poboxes.com> writes:
> Pascal Costanza <········@web.de> writes:
>
> > Tayssir John Gabbour wrote:
> >
> >> I wonder if the standards guys felt really decadent about putting in a
> >> hashtable, since CL was already huge by the standards of the day (ha
> >> ha, how times change), so it wasn't bulked up.
> >
> > You already need hashtables anyway internally for implementing Common
> > Lisp (-> package system), so it doesn't cost that much to standardize
> > them. EQUALP already works well with structures, so the current state
> > of affairs is probably just because noone put energy into integrating
> > CLOS and hashtables.
>
> Or maybe because the people on the committee were not quite sure how
> exactly to standardize this (using any user-supplied function as the
> equality test of an ANSI Common Lisp hash table), and they did not
> want to set anything in stone that might turn out to be half-baked.
> As it has been pointed out many times, designing library interfaces
> (including the constraints that apply) requires lots of effort as
> well as sufficient experience with prototype library designs.
The above is not consistent with the reality of the state
of the art of the day, and is a naive analysis of how
standards committees work.
Many of the people on the committee had much more experience
with Lisp than you seem to imagine. The state of the art of
the period is not really reflected in ANSI Common Lisp;
only a small, minimally greeable subset is in there.
The ANSI standard is about memorializing the "Common" practice
of the existing vendors, not necessarily about good practice.
Suppose there had been a well-thought out protocol, with years
of experience, and it solved the problem nicely. But also suppose
that only some dominant vendor had this particular feature.
Now imagine that you are one of the various competing vendors;
your main goal is to create an ANSI standard that you will be
complaint with. (That is, you want a standard that describes the
product that you already have, and you very much do not want to
add extra work for yourself,) Further suppose that you might be
rather sick and tired of the community telling you that the
dominant vendor's product is the gold standard, (of which this
functionality this might be small example), while your product
is at best, a second fiddle. How do you vote?
Suppose that the winning extensible hash table protocol is based
on object-oriented programming, and that there is disagreement on
which OO extensions to Lisp are best. It is not clear if there
will be any OO in the standard - the CLOS committee is working
in parallel with your committee. Maybe CLOS will not be be adopted.
And maybem,while hash table performance is critical to you, OO
performance is a general problem, or at least in your implementation,
and that you don't want to be forced to reimplement your hash tables
and at the same time slow it down (and things dependant on it) down
in the process. Maybe the dominant vendor does not even propose
their winning hash table protocols, and maybe nobody else suggests
that it's even a problem. Maybe everyone has much bigger fish to fry.
The above is a hypothetical thought experiment, but illustrative.
People were motivated at various times by exactly those factors.
(I don't know anything about proposals for this particular feature.)
I do not mean to cast any aspersions or make any specific suggestion
here about any particular vendor. Everybody who was on the committee
worked very hard to come up with something "good". But whether one
is "adopting a common practice" or "innovating" is a judgement call.
Technical abstractions might not be the deciding factor of "goodness".
Also, committee work is extremely expensive, taking critical resources
away from struggling companies. (By which I mean All of the companies.)
And the committe is on some deadlines. (To some degree, at least some
of the vendors - maybe most - didn't even really want any ANSI standard
at all at the time, but were forced into it by politics!)
If someone wants to propose a hash table extension protocol, I recommend
a careful study of the extension protocols used by the past and current
vendors. . (I strongly suggest including the Symbolics hash and "table"
system circa 1998 in this study.) Also, consider how you may and may not
extend the ANSI standard hash table functions, whether some "generic table"
system might be a better way of providing the functionality to applications,
and the performance implications and other features and implementation
constraints (GC, locking, etc.) involved in these. And, of course, look to
see what protocols are available in recently invented programming languages
so we can steal any good ideas that might have been missed.
······@news.dtpq.com (Christopher C. Stacy) writes:
> If someone wants to propose a hash table extension protocol, I recommend
> a careful study of the extension protocols used by the past and current
> vendors. . (I strongly suggest including the Symbolics hash and "table"
> system circa 1998 in this study.)
That's more like 1987, right? I have a video tape of Tom Diaz talking
about new Genera 7.0 features, citing extensions to the tabling system
as a major customer-requested enhancement (along with increasing the
amount of writable microstore and attaching multiple consoles to a
single machine).
Carl Shapiro wrote:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
>>If someone wants to propose a hash table extension protocol, I recommend
>>a careful study of the extension protocols used by the past and current
>>vendors. . (I strongly suggest including the Symbolics hash and "table"
>>system circa 1998 in this study.)
>
> That's more like 1987, right? I have a video tape of Tom Diaz talking
> about new Genera 7.0 features, citing extensions to the tabling system
> as a major customer-requested enhancement (along with increasing the
> amount of writable microstore and attaching multiple consoles to a
> single machine).
Do you see any chance of converting this to a Quicktime movie, or some such?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Carl Shapiro wrote:
>
> > ······@news.dtpq.com (Christopher C. Stacy) writes:
> >
> >>If someone wants to propose a hash table extension protocol, I recommend
> >>a careful study of the extension protocols used by the past and current
> >>vendors. . (I strongly suggest including the Symbolics hash and "table"
> >> system circa 1998 in this study.)
> > That's more like 1987, right?
> > I have a video tape of Tom Diaz talking
> > about new Genera 7.0 features, citing extensions to the tabling system
> > as a major customer-requested enhancement (along with increasing the
> > amount of writable microstore and attaching multiple consoles to a
> > single machine).
>
> Do you see any chance of converting this to a Quicktime movie, or some such?
Better AVI/DiVX. At least there's reader on MacOSX, Windows AND Linux,
while for Quicktime, there's only on MacOSX and Windows.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
On 2004-09-20, Pascal Bourguignon <····@mouse-potato.com> wrote:
>> Do you see any chance of converting this to a Quicktime movie, or some such?
> Better AVI/DiVX. At least there's reader on MacOSX, Windows AND Linux,
> while for Quicktime, there's only on MacOSX and Windows.
mplayer can read 'em.
Curt <·····@free.fr> writes:
> On 2004-09-20, Pascal Bourguignon <····@mouse-potato.com> wrote:
>
> >> Do you see any chance of converting this to a Quicktime movie, or some such?
>
> > Better AVI/DiVX. At least there's reader on MacOSX, Windows AND Linux,
> > while for Quicktime, there's only on MacOSX and Windows.
>
> mplayer can read 'em.
Actually, it depends on the codec used. The popular Sorrenson is not
available out of MacOSX...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
On 2004-09-20, Pascal Bourguignon <····@mouse-potato.com> wrote:
>> > Better AVI/DiVX. At least there's reader on MacOSX, Windows AND Linux,
>> > while for Quicktime, there's only on MacOSX and Windows.
>> mplayer can read 'em.
> Actually, it depends on the codec used. The popular Sorrenson is not
Sure.
> available out of MacOSX...
What?
http://www.mplayerhq.hu/DOCS/HTML/en/codecs.html#sorenson
Sorenson is a video codec developed by Sorenson Media and licensed to Apple
who distribute it with their QuickTime Player. We are currently able to
decode all version of Sorenson video files with the following decoders:
* Sorenson Video v1 (fourcc SVQ1) - decoding supported by native codec
(libavcodec)
* Sorenson Video v3 (fourcc SVQ3) - decoding supported by native codec
(libavcodec)
Curt <·····@free.fr> writes:
> On 2004-09-20, Pascal Bourguignon <····@mouse-potato.com> wrote:
>
> >> > Better AVI/DiVX. At least there's reader on MacOSX, Windows AND Linux,
> >> > while for Quicktime, there's only on MacOSX and Windows.
>
> >> mplayer can read 'em.
>
> > Actually, it depends on the codec used. The popular Sorrenson is not
>
> Sure.
>
> > available out of MacOSX...
>
> What?
I meant: is available only on MacOSX...
sorry.
> http://www.mplayerhq.hu/DOCS/HTML/en/codecs.html#sorenson
>
> Sorenson is a video codec developed by Sorenson Media and licensed to Apple
> who distribute it with their QuickTime Player. We are currently able to
> decode all version of Sorenson video files with the following decoders:
>
> * Sorenson Video v1 (fourcc SVQ1) - decoding supported by native codec
> (libavcodec)
> * Sorenson Video v3 (fourcc SVQ3) - decoding supported by native codec
> (libavcodec)
Nice. Last time I looked that did not exist.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
On 20 Sep 2004 11:17:53 +0200, Pascal Bourguignon wrote:
>> > I have a video tape of Tom Diaz talking
>> > about new Genera 7.0 features, citing extensions to the tabling system
>> > as a major customer-requested enhancement (along with increasing the
>> > amount of writable microstore and attaching multiple consoles to a
>> > single machine).
>>
>> Do you see any chance of converting this to a Quicktime movie, or some such?
> Better AVI/DiVX. At least there's reader on MacOSX, Windows AND Linux,
Better Theora (http://www.xiph.org)
--
Don't worry about people stealing your ideas. If your ideas are any good,
you'll have to ram them down people's throats.
-- Howard Aiken
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
From: Christopher C. Stacy
Subject: Re: what happened to hash-tables
Date:
Message-ID: <u7jqoetls.fsf@news.dtpq.com>
Carl Shapiro <·············@panix.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > If someone wants to propose a hash table extension protocol, I recommend
> > a careful study of the extension protocols used by the past and current
> > vendors. . (I strongly suggest including the Symbolics hash and "table"
> > system circa 1998 in this study.)
>
> That's more like 1987, right?
Yeah, I think those particular features are indeed from the mid-1980s.
(But I was just looking at the latest Genera sources on hand,
which was from about 12 years later.)
······@news.dtpq.com (Christopher C. Stacy) writes:
> The ANSI standard is about memorializing the "Common" practice
> of the existing vendors, not necessarily about good practice.
> Suppose there had been a well-thought out protocol, with years
> of experience, and it solved the problem nicely. But also suppose
> that only some dominant vendor had this particular feature.
> Now imagine that you are one of the various competing vendors;
> your main goal is to create an ANSI standard that you will be
> complaint with. (That is, you want a standard that describes the
> product that you already have, and you very much do not want to
> add extra work for yourself,) Further suppose that you might be
> rather sick and tired of the community telling you that the
> dominant vendor's product is the gold standard, (of which this
> functionality this might be small example), while your product
> is at best, a second fiddle. How do you vote?
That's why standards ought to be written by users, not by vendors.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
From: Christopher C. Stacy
Subject: Re: what happened to hash-tables
Date:
Message-ID: <u3c1cetfo.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > The ANSI standard is about memorializing the "Common" practice
> > of the existing vendors, not necessarily about good practice.
> > Suppose there had been a well-thought out protocol, with years
> > of experience, and it solved the problem nicely. But also suppose
> > that only some dominant vendor had this particular feature.
> > Now imagine that you are one of the various competing vendors;
> > your main goal is to create an ANSI standard that you will be
> > complaint with. (That is, you want a standard that describes the
> > product that you already have, and you very much do not want to
> > add extra work for yourself,) Further suppose that you might be
> > rather sick and tired of the community telling you that the
> > dominant vendor's product is the gold standard, (of which this
> > functionality this might be small example), while your product
> > is at best, a second fiddle. How do you vote?
>
> That's why standards ought to be written by users, not by vendors.
I ought to have a million dollars, and Lisp Machines ought not to have
"failed", too. But more to the point: users are free to join the
standards commitee and have exactly the same vote as vendors.
If they can't afford to do that, they're supposed to pressure
their vendors.
(I think the current vendors we have today are generally
quite well behaved and community-minded, by the way.)
Szymon <···@bar.baz> writes:
> [ http://www.strout.net/python/pythonvslisp.html ]
>
> Very funny.
>
> "...
>
> raw scores * weight = adjusted scores
> Python LISP Python LISP
> Maturity 7 10 * 5 35 50
> Syntax 10 2 * 8 80 16
> Expressiveness 9 8 * 10 90 80
> Functionality 10 10 * 5 50 50
> Dev. Activity 4 5 * 8 32 40
> Open Source 10 0 * 3 30 0
> Available Modules 10 4 * 7 70 28
> Extensibility 10 7 * 8 80 56
> Documentation 8 7 * 6 48 42
> Mac Integration 8 7 * 4 32 28
> Current Code 1 10 * 5 9 45
> Total 87 69 557 435
>
> ..."
Ha. Troll food indeed.
- They're talking about specific implementations, not the
languages as a whole: Macintosh Common Lisp as of 1999
and Python 1.5.2b1. (The page was written in 1999; it
doesn't purport to reflect current realities 5 years
later.)
That's why Python scores only 7/10 for maturity (I'd have
considered giving it less); why it only gets 4 for
"Dev. Activity" (Python was pretty young then); why
Lisp only gets 5 for "Dev. Activity" (MCL seemed pretty
moribund at that time); why Lisp gets 0 for "Open Source"
(they were only looking at MCL, and OpenMCL didn't exist --
thought I don't know why they ruled out CLISP).
- "Current Code" refers to *their* current code, which
at the time was written in Lisp.
That's why Python only gets 1/10 for "Current Code" and
Lisp gets 10. Er, except that actually it got 9 despite
what the table above says.
They also admit that their decision to give Lisp only 2/10
for "Syntax" is debatable. They don't make the same admission
about "Expressiveness", which is entertaining since one of
their arguments for Python ahead of Lisp is that Lisp's
exception handling is "limited"; they seem, in fact, not
to have bothered reading about conditions and to have
assumed that THROW/CATCH is the best one can do.
Their scores are a bit silly, but if you actually read the
whole page they aren't nearly as silly as they look at first.
--
Gareth McCaughan
.sig under construc
> [ http://www.strout.net/python/pythonvslisp.html ]
> Very funny.
A few years ago, I wrote an annotation regarding what I felt were the
shortcomings of that paper's analysis. I wrote my first draft as a
copy of the original brief, with inline comments.
I spoke with a copyright lawyer about releasing it in that form, but
decided it wasn't worth worrying about. I don't have time to rewrite
my findings in a releasable form. I do have time to copy the text of
my annotations below, with some notes regarding context.
Note that this was written a while ago, and only underwent one draft.
Also, I never followed up on some of the points regarding MCL
specifically. I've added a couple of nodes in [brackets] just now,
too.
Share and enjoy,
joelh
* Introduction
This brief is based on Joe Strout's Python vs. LISP
<URL:http://www.strout.net/python/pythonvslisp.html> brief. I read it
and was quite upset at the number of inaccurate implications that were
made, that could unduly sway a person chosing a language. Here, I
take his brief and annotate it with updates and clarifications.
I believe that Lisp was not given a fair assessment in this
paper, so most of my annotations concentrates on bringing out aspects
of Lisp which this paper does not thoroughly consider. I have
refrained from discussing Lisp's advantages except where they have a
bearing on the original text. For information about Lisp and its
merits, without regard to Python, see the information at the
Association of Lisp Users <URL:http://www.alu.org/>.
My annotations are displayed in italics throughout this paper.
[Although obviously not in the form I'm currently posting to c.l.l.
-joelh]
(Regarding terminology:) The choice of Macintosh Common Lisp (MCL)
plays a significant part in this paper. It affects a good portion of
the analysis, but by referring to MCL as "LISP" throughout, the reader
may be led to believe that the analysis is valid for any
implementation of Lisp.
It is important to recognize that the term Lisp refers to a family of
languages which have evolved since the late 1950s. The question of
what languages fall into this family is very significant. Some people
use this term to refer strictly to Common Lisp these days. Others use
it to refer to the languages with a clear ancestry to LISP 1.5,
typically including MAClisp (an implementation for the PDP-8, not the
Macintosh), Zetalisp, Spice Lisp, Emacs Lisp, NIL, InterLisp, and-- of
course-- Common Lisp. Others broaden this scope to include other less
clear descendants, such as Scheme, Dylan, and even Logo.
Because the most popular Lisp in industrial applications today is
Common Lisp, when I refer to Lisp in this paper, I am referring to
Common Lisp. In my comments, I will refer to Macintosh Common Lisp as
MCL. I regret forcing the reader to see two different referents of
Lisp depending on the italicization, but feel it is important to make
this distinction. [It should be easier to separate the usages of
"Lisp" in this separated version, but I make up for it by making it
harder to read overall. -joelh]
* Syntax
(Regarding a table of setq equivalents in different programming
languages:) Note that (let ((y (+ (* m x) b))) ...) is more common
than setq.
I disagree with the issues the author has with the Lisp syntax. The
Lisp syntax is very quickly learnable, if the student is not tied up
on clinging to old syntax.
The Lisp syntax also has important benefits. One key benefit is that
editors can become much more powerful when there is a regular,
consistent syntax. I can quickly traverse, transpose, and copy
expressions with a single keystroke in Lisp, which is not possible in
other languages because of the lack of delimiters.
(Regarding an example using #'): The fact that this was on page 2
should be a clue. This was intended as an example in the introduction
that functional programming is possible in Lisp. (The comparison was
with C, in which closures do not exist.) It was not intended to be
understood at that point in the book, for obvious reasons.
The complete introduction is available on-line at
<URL:http://www.paulgraham.com/lib/paulgraham/acl1.txt> for the
curious.
(Regarding the use of QUOTE to alter evaluation semantics, which the
author refers to as "syntax" throughout:) In most languages--
including Python-- "=" is an operator that violates standard
evaluation rules: the left-hand side is evaluated so far as necessary
to produce an lvalue. The concept of an lvalue is not an easy one.
Lisp also supports "set", which is not so special, but rather uses the
standard evaluation rules. The "setq" special form is provided as a
convenience, for learning and for readability.
(Regarding Python's lack of macros, which the author presents as a
feature of Python:) The read macro feature of Lisp is very powerful,
and should not be construed as a misfeature without giving it due
consideration.
Here is an example. I am working on one project that processes
configuration files. One very simple such configuration file might be:
a { system { name "foo"; } }
b { system { name "bar"; } }
These are processed as objects internally. While I am debugging and
experimenting, it is useful for me to include these objects inline.
To do so, I have created a read macro called "#{". This macro reads
such a configuration file as part of the inline code, and it will be
a new object. For example, using this new syntax, I can now write:
(merge #{a{system{name "foo";}} b{system{name "bar";}}}
#{c{system{name "baz";}}})
instead of the more klunky
(merge (create-params-from-string
"a{system{name \"foo\";}}b{system{name \"bar\";}}")
(create-params-from-string
"c{system{name \"baz\";}}"))
This makes my test suites more readable, and my debugging much easier.
It has been said: "Give a man a FORTRAN compiler, and he has a FORTRAN
compiler. Give a man Lisp, and he has any langauge he wants." Lisp's
syntax can be flexed by the user to let them write in a syntax that is
convenient for that project, rather than whatever the language
designer thinks should be good enough for everybody. (Another main
point of the quote is that Lisp is a flexible enough language that
other language's concepts can be quickly implemented. Indeed, a
number of languages have either their primary implementation in Lisp,
or have been repeatedly implemented in Lisp. Examples included
Macsyma (the predecessor to Maple and Mathematica), Prolog, and Logo.)
[This hasn't changed since my original writing, of course: I'm
presently working on v2 of the above-mentioned system, and it's now
based around a Prolog-within-Lisp. -joelh]
Oh, and how much code did it take to extend the language thusly? Five
lines. Four were adding to the READ-PARAMS function to accept the
character } as EOF if need be. The other was to set #{ to call
read-params.
(Regarding the author's assertion that Lisp's syntax is inconsistent,
because special forms and macros change evaluation rules:) I disagree
that the Lisp syntax is inconsistent. (Certainly, user-defined macro
functions like my #{ can make it so if you write them that way, but
I'm referring to the unextended language.) Rather to the contrary,
the syntax-- and semantics-- are much more consistent than other
languages, in my experience.
Note also that reader macros such as ', #', and my #{, as well as the
default reader, all produce lists. This means that macros-- both
reader macros and traditional macros-- can manipulate their arguments
in a natural way: by modifying the structure of the program, rather
than its textual representation. In most languages this is not
possible; macros must operate on text, which leads to many potential
problems.
One final note about syntactical differences: it is of historical
significance that the original implementation of Lisp, known as LISP
1.5 (for historical reasons), had a second syntax that used
traditional algebraic notation, etc. It was never used by Lisp
programmers, and was dropped. Perhaps the Lisp syntax has some merit
that the author of this paper did not consider.
* Expressiveness
(Regarding data types:) What the author calls "dictionaries" here
refers to key-value tables. The author fails to mention that, in
addition to the association list, Lisp supports very powerful hash
tables, keyed on either identity or different forms of equality (such
as case-sensitive or case-insensitive string comparisons). Most
implementations also support weak hash tables, and several support
lazy keying of hash tables. The association list is only used for
efficiency in small sets.
The Lisp numeric types deserve more mention than the author gave here.
Lisp is one of the few languages to support the bignum, which is an
integer that is larger than a machine word. Indeed, bignums may be as
large as swap space will allow. Lisp also supports machine integers,
ratios, floating point numbers, and complex numbers (where the
components may be any or all of the other numeric types). The type
system is hierarchical, so "real" is a datatype referring to all types
other than complex, "rational" refers to integers and ratios, etc.
The great advantage that this gives Lisp is that operations continue
to work properly regardless of type. For instance, the + operator
will work correctly on any numeric type, allowing a function such as
cis (cosine + i*sine) to be written using generic operations, and it
will work correctly regardless of the datatypes it is passed.
I have no idea why the author says that Lisp's lists are not
well-handled. It is probably the most well-supported type in the
language. The example the author gives-- the list slice operator-- is
equivalent to Common Lisp's subseq function. (Like Python's slice
operator, the subseq function also works on arrays. Unlike the slice
operator, it also works on strings.) Lisp also has built-in support
for nested and circular lists, shallow and deep duplication of lists
and trees, concatenation of lists both destructively and
non-destructively, lists as stacks, substitution in lists, and lists
as sets. This is on top of the sequence functions that work on
arrays, strings, and lists, for such operations as sorting, reversing,
arbitrary (user-defined) searching, substitution and modification
(destructive and non), merging, and mapping. (I use the term
"mapping" here in the sense it is used in functional programming, not
the Python-specific sense. That is, mapping creates sequences based
on applying a function to elements of an existing sequence.)
Of course, Lisp's other types are extremely powerful. To choose one
example, many people believe that Lisp has no vector datatype. Rather
to the contrary, Lisp offers powerful support for single and
multi-dimensional arrays, arrays of varying element type, and array
access that provides transparent access to fixed size arrays, arrays
displaced to other arrays, and arrays whose size is expected to
dynamically grow and shrink.
This flexibility in types may lead people to believe that, since Lisp
operators perform type-based dispatching, simple operations such as
addition are slow. However, if proper declarations are made, Lisp's
numeric operators rival those of FORTRAN in speed, and operations on
other types can see similar improvements.
(Regarding doc strings:) It is probably worth mentioning that in Lisp,
documentation strings may also appear associated with variables,
constants, object slots, qualified methods, and many other places.
Most Lisp editors support display of these documentation strings
rapidly on-demand, because there are built-in functions in Lisp to
interactively access them, even in compiled code.
(Regarding exception handling:) This is one of the most misleading
paragraphs in this paper. The author did not discuss what version of
MCL was used for this. However, well prior to the date of this
report, MCL had the very powerful and flexible [Note: I didn't finish
this paragraph. -joelh]
The first edition of Common Lisp: The Language did not specify an
error-handling system. The following rationale was given:
Rationale: Error handling of adequate flexibility and power for
all systems written in Common Lisp appears to require a complex
error classification system. Experience with several
error-handling systems in such dialects as MacLisp and Lisp
Machine Lisp indicates that further experimentation is needed in
this area; it is too early to define a standard error-handling
mechanism. Therefore Common Lisp provides standard ways to signal
errors, but no standard ways to handle errors. Of course a
complete Lisp system requires error-handling mechanisms, but many
useful portable programs do not require them. It is expected that
a future revision of Common Lisp will address the problem of
portable error-handling mechanisms.
Indeed, the second edition of Common Lisp: The Language (published
1990) specifies a very powerful and flexible error-handling system.
The ANSI standard also has this specification (voted 1988, published
1994). Every current Common Lisp implementation of which I am aware--
including MCL since sometime prior to January 2000-- supports this
system.
The second edition of CLtL provides this explanation, regarding the
new system, after quoting the first edition:
This was the result of the research and experimentation alluded to
in the preceding paragraph. Conditions subsume and generalize the
notion of errors. The condition system also provides means for
handling conditions (of which errors are a special case) and for
restarting a computation after a condition has been signaled.
The Common Lisp error-handling system is known as the condition
system. This supports a powerful and extensible hierarchy of
conditions, including errors, warnings, and signals for non-serious
(but potentially useful to the program) conditions. Programs may
establish useful points of execution for restarting evaluation. For
instance, the LOAD function in my preferred implementation installs
three such restarts: one to check for the file again (presumably after
the user creates it), one to prompt the user for a different filename,
one to simply pretend the LOAD succeeded, and one to abort whatever
user command prompted the LOAD call (which may have been a load
command, or something else).
Programs also may establish handlers for conditions. For instance, a
program may trap the LOAD error, create the file (based on some logic
particular to the program), and then invoke the restart to retry the
LOAD. Programs do this without checking for explicit error codes.
Instead, they simply indicate that a particular section of code is to
execute with particular handlers. The function raising the exception,
of course, need not be directly called by functions establishing
restarts or handlers.
Furthermore, programs may specify their own debuggers. For example,
one project I am working on is a library that is invoked using a
remote procedure call system. In the event of an error, the server's
debugger is not invoked. Instead, my library uses the RPC system to
invoke a debugger in the calling program. This allows the calling
program (or its user) to decide how to handle the situation. It
provides a list of restarts (including invoking the normal server-side
debugger). This mechanism certainly makes sense for my project than
always invoking the local debugger, or simply aborting the remote call
on any error. I can think of no other language which provides this
flexibility; debuggers are rarely first-class objects.
In summary, contrary to the assertion made by the original author,
Lisp provides an extremely versatile, flexible error handling system.
No other language I have seen comes anywhere close to Lisp in this
category.
[I recently considered writing an opinion paper that a language's
exception handling system is a good indicator of the language's
overall power. -joelh]
(Regarding the object system:) I am unclear on why the author says
that CLOS, the Common Lisp Object System, is not standard. Indeed,
Common Lisp-- with CLOS-- was the first object-oriented programming
language to have an ANSI standard. CLOS is now in all major Lisp
implementations that I am aware of. It certainly does appear to be
very standard.
The historical relationship of Lisp and object-oriented programming is
very solid. Several of the first OOP systems were implemented in
various dialects of Lisp, including Common Lisp. CLOS was developed
after years of experience with a number of other Lisp object systems.
CLOS is arguably the most complete and advanced object system of any
programming language. It supports:
- multiple-inheritance, where classes can inherit from multiple
superclasses.
- multi-method dispatch, where operations can be specialized not
just on a single object, but on any of the arguments for the
operation, or any combination of those arguments.
- method combination, in which the means by which several applicable
operations to a particular set of arguments can be combined, is itself
an object-oriented specification, definable by the programmer.
- operations that can specialize on particular instances of classes,
rather than on just the broad class of the arguments.
- shared class variables (slots, attributes) that are shared by all
instances of a class, in addition to instance variables which are
unique to each instance.
- specification of the creation operation for instances of a class
as an object-oriented program, definable by the programmer.
- The behavior of operations on objects (methods) are themselves
defined as first-class objects, which can be specialized by the
programmer.
- Access to classes themselves as first-class objects. The objects
which define the behavior of classes are themselves classes, usable
directly by the programmer.
Lisp has a long history of introspection and intervention, meaning
that a program can examine itself, and change how the language works.
CLOS realizes this with a very powerful metaobject protocol. This
defines classes, generic functions, and methods as first-class objects
which may be manipulated by the program. For instance, with CLOS's
metaobject protocol, it is possible to make a portable class browser
that operates on classes in compiled or interpreted code. It is also
possible to define new classes and methods programmatically at
runtime, without prior knowledge about the superclasses.
This is the first paper I have seen which considers and rejects CLOS.
Every other paper I have seen, along with my own personal opinion,
considers CLOS to be the most advanced object system found in any
language.
(Regarding expressiveness:) I find it ironic that the author is
marking off points for Lisp's expressiveness by relationship to a
language which so heavily requires OOP style. Certainly,
object-oriented programming is a great thing, but a truly expressive
language should meet the needs of the problem, not force the problem
to meet its standards.
Bjarne Stroustrup, inventor of C++ once said, "No single language can
support every style, but a variety of styles can be supported within
the framework of a single language. Where this can be done,
significant benefits arise from sharing a common type system, a common
toolset, and so forth. These technical advantages translate into
important practical benefits such as enabling groups with moderately
differing needs to share a language rather than having to apply a
number of specialized languages."
Lisp has excellent support for the three major styles of programming:
procedural, functional, and object-oriented. There are procedural
operations such as assignment and many different kinds of iteration
and other control flow constructs (even go). Lisp also has excellent
support for functional programming; in fact, it is frequently
classified a functional language.
I have already discussed Lisp's support for object-oriented
programming.
Besides supporting many different styles of programming, Lisp itself
is a very expressive language. Lisp's powerful macro facility also
allows the language to be extended in any way that is useful to the
program. This allows programmers to be more clear and concise in
their code.
Indeed, the major reason that most Lisp programmers like the language
is because of its expressiveness and flexibility.
* Developer Activity
(Regarding implementations:) One of these facts is easily refuted.
Digitool opened MCL 4.4 (Mac OS X native) for beta testing in July
2001, and started shipping MCL 4.3.1 in August 2001. (I'm writing
this in November 2001.) It's also useful to note that the 1997
posting the author referred to may be the news item saying that
MacWorld magazine, a very prominent magazine in the Mac community,
rated MCL 4.1 as an Editor's Choice Finalist in the category of Best
Rapid Development Tool.
Gauging a user community based on one vendor is certainly perilous.
One leading commercial Lisp vendor, Xanalys, released LispWorks 4.1.20
on February 2001. They list as customers American Express, Alcatel,
Atraxis, Commerce One, Ford Motor Company, Fujitsu, HotDispatch, HP
Labs, KPN Research, Memetric PTY, NASA, Qwest Communications and the
US Army. Another vendor, Franz Inc., released their most recent
implementation of Lisp (Allegro CL 6.1) this month; they are primarily
marketing it towards the e-commerce/b2b, bioinformatics, and knowledge
management markets.
For comparison purposes, the commercial vendors of Python I could find
are Pythonware, who made their last release in March 2001, and
theKompany, who released January 2001.
Of course, that's just looking at commercial vendors. Both Lisp and
Python have open-source implementations that are very popular. I
certainly don't mean to sound like I'm putting down open source; I'm a
very active proponent of open source myself. I only highlight
commercial vendors because that's what the original author chose to
highlight.
Among open-source implementations, my favorite is CMU CL. Even though
it was originally developed at CMU, its userbase is so strong that it
has continued in open source after CMU no longer was able to
officially maintain it. Its most recent release was January 2001.
Another open-source implementation, CLISP, was last released July
2001. These two are intended as sample data points; I used the two
implementations I'm most familiar with. There are many others that
may have relevant release dates as well.
For comparison, the latest open-source Python release was July 2001.
(Regarding documentation:) Certainly, it is absurd to only consider
documentation published after 1995. Because Lisp has been around for
a long time, many excellent books have been published on the topic and
are reprinted. One of the most well-respected books on computer
programming, Structure and Interpretation of Computer Programs
(pub. date Aug 96), chooses the Scheme dialect of Lisp for its work.
This book is frequently regarded with the same respect as Knuth's The
Art of Computer Programming. It also is a better seller than any
Python book, according to Barnes and Noble. (This book is not about
ANSI Common Lisp, so would not meet the above criteria, but I feel the
authors' choice of language is relevant.)
The author omitted the book he found. He may have been referring to
Paul Graham's ANSI Common Lisp (pub. date Nov 95); this seems likely,
since he referred to it.
The well-respected book Paradigms of Artificial Intelligence
Programming: Case Studies in Common Lisp was published in October 92,
but my copy is in its fifth printing, on 1999. Surely this indicates
an ongoing demand for Lisp books.
Admittedly, this paper was published before the current (4th) edition
of Artificial Intelligence: Structures and Strategies for Complex
Problem Solving (pub. date Aug 01), which is based around Common Lisp
and Prolog, but I'm not sure if previous editions of this were
considered. Certainly, though, Object-Oriented Common Lisp (1st ed,
pub. date Jul 97) should have been in his list, as well as Lisp in
Small Pieces (pub. date Jan 97).
I also feel it is misleading to discard books about AutoLISP from
consideration. The fact that books about industry-specific
applications of Lisp exist is significant. I am aware of no
industry-specific books for Python, but am aware of books based on
Lisp in general for AI, switching networks, and mathematics, as well
as product-specific books about Lisp in Emacs and AutoCAD.
(Regarding Usenet stats:) First of all, let me make it clear that I
assign very little relevance to these statistics. I suspect that the
numbers are meaningless; there is more traffic on comp.lang.python
than on comp.lang.java and comp.lang.perl combined, and almost as much
as on comp.lang.c. This clearly does not reflect the relative
popularity of the languages. However, I will still proceed to discuss
the matter.
The newsgroup difference is now a factor of two. I don't have numbers
for the mailing lists, but the MCL mailing list was probably not a
good data point.
The author suggests that Lisp users may not be as active on the
mailing lists because of a wider variety of reference material
available. I propose it is also possibly influenced by the fact that
the Python language itself is still in a state of great flux, as is
normal for a language this young. This flux causes confusion on the
part of the programmers.
The Common Lisp language, however, has been very stable. There are
great libraries for new technologies such as XML, SQL, CORBA, Java
integration, etc, from both vendors and open-source communities, and
these are changing. However, discussion of these libraries tends to
take place on product-specific mailing lists, rather than
comp.lang.lisp. (I am referring to library-specific questions; the
general issues, such as "is Java integration a useful thing or a
distraction", are discussed on comp.lang.lisp.)
In contrast, these sorts of things are prominent on comp.lang.python.
These theories are both supported by the message content. Most
messages on comp.lang.python are of the how-do-i... variety. In
contrast, discussion on comp.lang.lisp tends to relate more to
discussions of Lisp's history and future, implementational tradeoffs,
software repositories, etc.
Again, I do not assign any relevance to these figures; I do not think
that number of messages in a newsgroup is a valid measure of the size
or strength of a language's user community.
(Regarding growth rates:) Although the Lisp community is generally
believed to be smaller (in percentage of programmers) than in the mid
80's, it has in the last year or so began to grow faster. The cause
of this is difficult to determine, but one popular theory is that
programmers are getting fed up with Java, and go to Lisp, from which
Java got many of its best features.
* Open Source
There are many excellent open-source implementations of Lisp. I use
CMUCL in my day-to-day work because I like its compiler, but there are
others.
* Available Modules
Traditionally, in the Lisp world, most library needs have been met by
the vendor. Today, vendors are providing libraries for both
traditional Lisp libraries such as expert systems and knowledge
representation, as well as modern technologies for complete Java
integration, RPC, SSL, HTML/XML, ODBC/SQL, FFI, OLE/COM, CORBA, even
complete web servers for dynamic content that work on their own or
with Apache and other web servers.
However, in today's world, open-source code libraries are of great
significance. CPAN, the Comprehensive Perl Archive Network, is a
clear indication that open-source code repositories can be very
powerful tools for language developers.
There are libraries, and more in the works. Good starting points
would be CLiki <URL:http://www.cliki.net/cliki/> [I updated the URL
-joelh] CLOCC <URL:http://clocc.sourceforge.net/>; also cCLan
<URL:http://cclan.sourceforge.net> is a new one. There has been much
talk in the Lisp community about the need for a software repository
similar to CPAN, and these are where they are happening.
It's important to recognize that many excellent libraries for these
things exist, and some have for some time. Historically, they have
been discussed by word-of-mouth, and distributed on FTP. The CMU AI
repository used to serve a similar purpose for Lisp as CPAN now does
for Perl, but CMU was unable to continue its maintenance. The Lisp
community is now working to create a centralized repository like new
Lisp developers-- like the author-- expect.
* Documentation
When there is a single implementation of a language, the vendor
documentation is the same as the language documentation. The author
here glosses over this distinction, and is comparing, on one hand the
combined language and implementation documentation for Python, and on
the other hand, only the implementation documentation for MCL.
The implementation documentation will, of course, vary from vendor to
vendor. One Lisp implementation I enjoy has highly advanced,
integrated hypertext documentation, available right from the editor,
or a separate documentation viewer. This includes both reference
material as well as task-oriented documentation like suggestions on
how to organize projects.
As previously mentioned, Lisp allows the user to include function
documentation along with function definitions. Editors, such as the
popular open-source Emacs or the Lisp implementation's built-in
editor, allow the user to pull up documentation for a built-in or
user-defined function at the touch of a button.
As for language documentation, the two primary references for Lisp are
available online, in hypertext form: the ANSI standard
<URL:http://www.xanalys.com/software_tools/reference/HyperSpec/index.html>,
and Common Lisp: The Language
<URL:http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/lang/lisp/doc/cltl/cltl_ht.tgz>
* MacOS Integration
As of this writing, the latest version of MCL, 4.3.1, runs under Mac
OS X in "classic" mode. The native version, 4.4, is now in testing.
[I was going to followup to see what the situation was when the
original brief was published, but never did. -joelh]
* Current Code
This probably doesn't apply to most situations.
* Scoring
I have chosen not to change these scorings. Deciding appropriate
scores and weights for a particular situation is left as an exercise
to the reader.
(Regarding the author's justification for the weight on syntax:) Some
programmers-- particularly those who have exposure to a limited
variety of languages-- get hung up on Lisp's syntax when they are
first exposed to the language, and never get past that initial
impression. This is quite regrettable; I find Lisp to be a wonderful
language, and the syntax to be easily readable and a real feature of
the language. It simply takes a little bit of time and a willingness
to learn something new.
* Recommendation
Every situation is different. I cannot make recommendations regarding
every situation, only make general observations.
* Footer
pythonvslisp-redux.html . . . . . . . . . .
11/30/01 . . . . . . . .
Joel Ray Holveck (·····@gnu.org)
Szymon wrote:
> [ http://www.strout.net/python/pythonvslisp.html ]
>
> Very funny.
>
> "...
>
> raw scores * weight = adjusted scores
> Python LISP Python LISP
> Maturity 7 10 * 5 35 50
> Syntax 10 2 * 8 80 16
> Expressiveness 9 8 * 10 90 80
> Functionality 10 10 * 5 50 50
> Dev. Activity 4 5 * 8 32 40
> Open Source 10 0 * 3 30 0
> Available Modules 10 4 * 7 70 28
> Extensibility 10 7 * 8 80 56
> Documentation 8 7 * 6 48 42
> Mac Integration 8 7 * 4 32 28
> Current Code 1 10 * 5 9 45
> Total 87 69 557 435
>
> ..."
>
> Best regards.
If lisp is so great (which I tend to believe, actually) are their so
many people not using it ?
I mean there must be flaws or something, otherwise everybody would use
it I suppose.
Take for example speed. People say "C is faster than lisp". We (lispers)
reply "With proper declaration, Lisp is as fast as C". But, people, how
difficult is that ! I mean I've been declaring things in my code to make
it efficient, and now I got something full of "the" and "declare", which
makes the code lot less readable, and I don't mention the time I spend
on it...
Ok, maybe I'm wrong, but I think we have to admit lisp is not as
straightforward as C for exemple.
However, I'm really keen on lisp at the moment.
I'm just an old newbie, but I hope you get my point somehow.
Martin
Martin Raspaud <········@labri.fr> writes:
> If lisp is so great (which I tend to believe, actually) are their so
> many people not using it ?
> I mean there must be flaws or something, otherwise everybody would use
> it I suppose.
Betamax vs VHS. Eat shit, after all 3e12 flies can't be wrong.
> Take for example speed. People say "C is faster than lisp". We
> (lispers) reply "With proper declaration, Lisp is as fast as C". But,
> people, how difficult is that ! I mean I've been declaring things in
> my code to make it efficient, and now I got something full of "the"
> and "declare", which makes the code lot less readable, and I don't
> mention the time I spend on it...
Why do you think C code is 2 to 3 times more bloated than normal Lisp
code? Because they have to put all these type declarations and type
casting everywhere!
Either you want to spend your time on ugly but fast code, or you want
to let the computer spend its time on nice but slow code. With the
hope that sometimes with some lisp macros you can get nice and fast
code too.
> Ok, maybe I'm wrong, but I think we have to admit lisp is not as
> straightforward as C for exemple.
For what? Since when I reimplement in Lisp old C (or other
procedural) code I en with a lot less lisp code, I find it rather
straightforward: I can write in one lisp line what takes ten C lines!
> However, I'm really keen on lisp at the moment.
> I'm just an old newbie, but I hope you get my point somehow.
Just try it.
Take your prefered program written in C and rewrite it in Lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Martin Raspaud wrote:
> If lisp is so great (which I tend to believe, actually) are their so
> many people not using it ?
>
> I mean there must be flaws or something, otherwise everybody would use
> it I suppose.
Yes, of course. The only question is whether the language or the people
not using it are flawed. ;)
> Take for example speed. People say "C is faster than lisp". We (lispers)
> reply "With proper declaration, Lisp is as fast as C". But, people, how
> difficult is that ! I mean I've been declaring things in my code to make
> it efficient, and now I got something full of "the" and "declare", which
> makes the code lot less readable, and I don't mention the time I spend
> on it...
> Ok, maybe I'm wrong, but I think we have to admit lisp is not as
> straightforward as C for exemple.
Don't gratuitously add lots of declarations all over the place. It's
well known that you cannot predict their effects in large programs. The
only way to make a program perform fast is to run it in realistic
scenarios, try to find the bottlenecks, and then to optimize those.
Everything else is a waste of time. There are several reasons: programs
tend to spend 80% of their time in 20% of the code (or so), so if you
optimize everything you have wasted 80% of your time; small improvements
over here can lead to an unexpected big degradations over there (for
example, too much inlining may have a bad effect on processor caches);
good algorithms and good program organization are better than micro
efficiency (the C version of bubble sort won't beat the Lisp version of
quicksort); and so on.
So it's more important that the language allows you to write clearer and
more understandable code in a shorter amount of time, so that you can
see the effects of your design decisions as soon as possible, and change
your mind very late in the game.
I think that the bigger programs get, the more inevitable it becomes
that you integrate a (kind of) domain-specific language. The natural way
to do this in C is to write an interpreter for such a language. The
natural way to do this in Lisp is to write a compiler (due to macros).
Therefore, I believe that on a large scale, Lisp can be more efficient
than C. (Admittedly, this is speculation.)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
On Mon, 13 Sep 2004 11:18:50 +0200, Pascal Costanza <········@web.de>
wrote:
>
> I think that the bigger programs get, the more inevitable it becomes
> that you integrate a (kind of) domain-specific language. The natural way
> to do this in C is to write an interpreter for such a language. The
> natural way to do this in Lisp is to write a compiler (due to macros).
> Therefore, I believe that on a large scale, Lisp can be more efficient
> than C.
> (Admittedly, this is speculation.)
Not entirely. Take the CL-PPCRE, the regexp library for lisp.
Because it produces compiled code it can outperform Perl's regexps.
(Of course Perls regexp engine is written in C and thus regexps are
interpreted)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Mon, 13 Sep 2004 12:41:24 +0200, "John Thingstad" <··············@chello.no> wrote:
> Not entirely. Take the CL-PPCRE, the regexp library for lisp.
> Because it produces compiled code it can outperform Perl's regexps.
> (Of course Perls regexp engine is written in C and thus regexps are
> interpreted)
CL-PPCRE generates compiled code but it doesn't compile code at run
time - it just creates a chain of closures. In theory, you could do
the same thing in C.
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On 2004-09-13 11:18:50, Pascal Costanza wrote:
> I think that the bigger programs get, the more inevitable it becomes
> that you integrate a (kind of) domain-specific language. The natural way
> to do this in C is to write an interpreter for such a language.
How often does this actually happen?
And how often does this happen when people try learning and using a
language at home?
Stefan Scholl wrote:
> On 2004-09-13 11:18:50, Pascal Costanza wrote:
>
>>I think that the bigger programs get, the more inevitable it becomes
>>that you integrate a (kind of) domain-specific language. The natural way
>>to do this in C is to write an interpreter for such a language.
>
> How often does this actually happen?
>
> And how often does this happen when people try learning and using a
> language at home?
These are rhetorical questions, right? Or do you know about any studies
that investigate these - interesting! - questions?
The only hint in the literature I recall is the Interpreter pattern in
the Design Patterns book, and patterns are supposed to be solutions to
recurring problems that happen to be frequently used.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
On 2004-09-13 10:54:47, Martin Raspaud wrote:
> If lisp is so great (which I tend to believe, actually) are their so
> many people not using it ?
>
> I mean there must be flaws or something, otherwise everybody would use
> it I suppose.
Different expectations, way of thinking.
After C64, AmigaOS, and Linux I was confronted with a very different
machine at work: IBM's AS/400 with OS/400.
Instead of character/byte oriented files it has database files with
fixed record lengths. And many other strange things I haven't
thought of coming from AmigaOS and Linux. The main language was
RPG/400. Like C for Unix, RPG/400 was the language of choice for
many things. Because of the DB centric view of OS/400 and RPG/400
you have to think differently.
Back to Common Lisp: People don't start looking at Common Lisp out
of a void (except when they are forced to as a student). They know
their (mostly Unix inspired) systems and way of work/thinking.
So the first questions they want to solve is how to make an
executable with CL, how to make a GUI, how to make all I want
without paying for a commercial implementation.
The answers don't make everybody happy.
Common Lisp ist different. Too different.
They ways of other languages: Take an editor of your choice, which
can be a VI if you want to, save your work, run the implementation
of the Language to either execute (Perl, Ruby, Rexx, Python, ...) or
compile (C, C++, OCaml, ...) it. Error in the code? Jump to the
indicated line and correct it.
In CL you are forced to use Emacs (or some emacs like editor of the
commercial vendors) to make the differences worth the effort of
using CL at all.
And even when people only program for themselves, they want to be
able (even when they never will!) to package their work easily and
give it away. It is possible with CL, but it's not easy to
understand when you look at it before actually learning CL.
And some other problems: Lisp advocates don't alway tell the truth.
Or maybe only the truth from the standpoint of a Lisp programmer.
After hearing how easy CL is, no syntax, no swearing characters like
in Perl, you get really pissed finding out about FORMAT, LOOP, and
all the funny characters like #, `, ', @, ...
Stefan Scholl <······@no-spoon.de> writes:
> Common Lisp ist different. Too different.
You could use Lisp like C. All the implementations (that I know, but
most probably others too) allow you to compile a Lisp file like gcc.
For example, with clisp:
clisp -ansi -c source.lisp
instead of:
gcc -ansi -c source.c
Now, to link the object files, it's slightly more complicated than
gcc, but you could easily encapsulate it in a script or makefile:
clisp -ansi -x "(prong $(for src in pkg1 pkg2 pkg3 main ; do \
echo "(LOAD \"${src}.fas\")" ; done ) \
(DEFUN %MAIN () (MAIN ext:*args*) (EXT:QUIT)) \
(EXT:SAVEINITMEM \"mypgm.mem\" :QUIET T \
:INIT-FUNCTION (FUNCTION %MAIN)) (EXT:QUIT))"
instead of:
ld -o mypgm $(for src in pkg1 pkg2 pkg3 main ;do \
echo ${src}.o ; done) -lc -lx -ly
I don't see it so different in CL!
> And some other problems: Lisp advocates don't alway tell the truth.
> Or maybe only the truth from the standpoint of a Lisp programmer.
> After hearing how easy CL is, no syntax, no swearing characters like
> in Perl, you get really pissed finding out about FORMAT, LOOP, and
> all the funny characters like #, `, ', @, ...
I rather use (function sin) and (character "x"), you could use (quote
x), and list, append, list*, cons, etc instead of ` and @.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Stefan Scholl wrote:
> Back to Common Lisp: People don't start looking at Common Lisp out
> of a void (except when they are forced to as a student). They know
> their (mostly Unix inspired) systems and way of work/thinking.
>
> So the first questions they want to solve is how to make an
> executable with CL, how to make a GUI, how to make all I want
> without paying for a commercial implementation.
>
> The answers don't make everybody happy.
Yes, of course. Unfortunately, such entry barriers make some not take a
deeper look. Unless they are open minded enough to expect some important
and maybe unexpected differences.
> Common Lisp ist different. Too different.
>
> They ways of other languages: Take an editor of your choice, which
> can be a VI if you want to, save your work, run the implementation
> of the Language to either execute (Perl, Ruby, Rexx, Python, ...) or
> compile (C, C++, OCaml, ...) it. Error in the code? Jump to the
> indicated line and correct it.
vi seems to work well for Lisp, as some have reported here. Slime (for
emacs) provides pretty good error handling.
> In CL you are forced to use Emacs (or some emacs like editor of the
> commercial vendors) to make the differences worth the effort of
> using CL at all.
On the Mac, things go pretty smooth because the Control and the Command
key don't interfere with each other. So the commercial Common Lisp
implementations provide editors that work as a Mac application when
using the Command key and like an emacs editor when using the Control
key. The Control key is largely not used by Mac OS X, which BTW also
makes using the terminal pretty painless. I can imagine that on Windows,
things seem somewhat tougher because the Control key is also used by the
operating system. (Especially, Control-C sucks in the terminal. ;)
> And even when people only program for themselves, they want to be
> able (even when they never will!) to package their work easily and
> give it away. It is possible with CL, but it's not easy to
> understand when you look at it before actually learning CL.
I'd say it's pretty effortless once you got it.
> And some other problems: Lisp advocates don't alway tell the truth.
> Or maybe only the truth from the standpoint of a Lisp programmer.
> After hearing how easy CL is, no syntax, no swearing characters like
> in Perl, you get really pissed finding out about FORMAT, LOOP, and
> all the funny characters like #, `, ', @, ...
These are reader macros. You don't have to use them, they are just added
for convenience.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> [...]
> On the Mac, things go pretty smooth because the Control and the
> Command key don't interfere with each other. So the commercial Common
> Lisp implementations provide editors that work as a Mac application
> when using the Command key and like an emacs editor when using the
> Control key. The Control key is largely not used by Mac OS X, which
> BTW also makes using the terminal pretty painless. I can imagine that
> on Windows, things seem somewhat tougher because the Control key is
> also used by the operating system. (Especially, Control-C sucks in the
> terminal. ;)
Well, Macs have always done a good thing by having four modifier
keys (Alt, Ctrl, Command, Shift), and even though PC keyboards have
also had an extra key for a couple of years now (the "Windows" key),
it doesn't come to much use in Windows (though it does in X). But
even with just Alt, Ctrl, and Shift, Emacs/XEmacs on Windows works
pretty well---I can't think of many cases where Windows'
interpretation of key combinations gets in the way (in fact, right
now, only Alt+Space and Alt+F<n> come to mind as "shadowing" M-SPC
and M-f<n>).
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Vassil Nikolov wrote:
> pretty well---I can't think of many cases where Windows'
> interpretation of key combinations gets in the way (in fact, right
> now, only Alt+Space and Alt+F<n> come to mind as "shadowing" M-SPC
> and M-f<n>).
Ahh, but Alt-TAB gets in the way of the completion keystroke. Just as much
of a problem in GNOME and KDE too, though.
Also, I've noticed that Meta-< seems not to work on a linux text-mode
terminal. So I guess Emacs is just too greedy with the keyboard.
Chris Capel
Chris Capel <······@iba.nktech.net> writes:
> Vassil Nikolov wrote:
>
>> pretty well---I can't think of many cases where Windows'
>> interpretation of key combinations gets in the way (in fact, right
>> now, only Alt+Space and Alt+F<n> come to mind as "shadowing" M-SPC
>> and M-f<n>).
>
> Ahh, but Alt-TAB gets in the way of the completion keystroke. Just as much
> of a problem in GNOME and KDE too, though.
In Windows, yes, but in KDE (GNOME too?), it's possible to switch to
the "Windows" key for KDE's shortcuts, so Alt becomes available.
> Also, I've noticed that Meta-< seems not to work on a linux text-mode
> terminal. So I guess Emacs is just too greedy with the keyboard.
For TERM=linux? It works on Red Hat's Linux 2.4.21-4.EL #1 Fri Oct
3 18:13:58 EDT 2003...
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Vassil Nikolov wrote:
> For TERM=linux? It works on Red Hat's Linux 2.4.21-4.EL #1 Fri Oct
> 3 18:13:58 EDT 2003...
Oh, silly me. It's actually using PuTTY as a SSH client running emacs that
has that problem. I remembered incorrectly. :-)
Chris Capel
Chris Capel <······@iba.nktech.net> wrote:
+---------------
| Vassil Nikolov wrote:
|
| > For TERM=linux? It works on Red Hat's Linux 2.4.21-4.EL ...
|
| Oh, silly me. It's actually using PuTTY as a SSH client running
| emacs that has that problem. I remembered incorrectly. :-)
+---------------
Note that PuTTY lets you select among several terminal emulations.
I tend to use "xterm", but there are others that might work better
for you.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Chris Capel <······@iba.nktech.net> writes:
> Vassil Nikolov wrote:
>
>> pretty well---I can't think of many cases where Windows'
>> interpretation of key combinations gets in the way (in fact, right
>> now, only Alt+Space and Alt+F<n> come to mind as "shadowing" M-SPC
>> and M-f<n>).
>
> Ahh, but Alt-TAB gets in the way of the completion keystroke. Just as much
> of a problem in GNOME and KDE too, though.
In Windows, yes, but in KDE (GNOME too?), it's possible to switch to
the "Windows" key for KDE's shortcuts, so Alt can be made available.
> Also, I've noticed that Meta-< seems not to work on a linux text-mode
> terminal. So I guess Emacs is just too greedy with the keyboard.
For TERM=linux? It works on Red Hat's Linux 2.4.21-4.EL #1 Fri Oct
3 18:13:58 EDT 2003...
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Stefan Scholl <······@no-spoon.de> wrote:
+---------------
| They ways of other languages: Take an editor of your choice, which
| can be a VI if you want to, save your work, run the implementation
| of the Language to either execute (Perl, Ruby, Rexx, Python, ...) or
| compile (C, C++, OCaml, ...) it. Error in the code? Jump to the
| indicated line and correct it.
|
| In CL you are forced to use Emacs (or some emacs like editor of the
| commercial vendors) to make the differences worth the effort of
| using CL at all.
+---------------
This is a persistent myth. Yes, if you use (or *can* use[1]) Emacs,
there are some significant speedups in performing certain tasks, but
one really *can* develop sizable Common Lisp apps just fine with "vi".
"Vi" has paren-matching, paren-flashing, and shift left/right to matching
paren. So rather than do *everything* in one window (or set of windows)
as in Emacs-with-SLIME (or ILISP), when using "vi" (or some other editor)
one keeps another window open to a REPL in the application, where you
invoke LOAD (or something more convenient, such as ASDF) whenever you
write out an update from the editor. [And you use the mouse to cut'n'paste
from the editor to the REPL for trial evaluation of single redefined
functions.] You're still "living in the editor", mostly...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Stefan Scholl <······@no-spoon.de> wrote:
+---------------
| They ways of other languages: Take an editor of your choice, which
| can be a VI if you want to, save your work, run the implementation
| of the Language to either execute (Perl, Ruby, Rexx, Python, ...) or
| compile (C, C++, OCaml, ...) it. Error in the code? Jump to the
| indicated line and correct it.
|
| In CL you are forced to use Emacs (or some emacs like editor of the
| commercial vendors) to make the differences worth the effort of
| using CL at all.
+---------------
This is a persistent myth. Yes, if you use (or *can* use[1]) Emacs,
there are some significant speedups in performing certain tasks, but
one really *can* develop sizable Common Lisp apps just fine with "vi".
"Vi" has paren-matching, paren-flashing, and shift left/right to matching
paren. So rather than do *everything* in one window (or set of windows)
as in Emacs-with-SLIME (or ILISP), when using "vi" (or some other editor)
one keeps another window open to a REPL in the application, where you
invoke LOAD (or something more convenient, such as ASDF) whenever you
write out an update from the editor. [And you use the mouse to cut'n'paste
>from the editor to the REPL for trial evaluation of single redefined
functions.] You're still "living in the editor", mostly...
-Rob
[1] I have tried several times to make the transition from Vi to Emacs,
but have never been successful. Emacs gives my hands cramps (literally).
I'm just too used to using "moded" editors where most of the "editing"
commands are unshifted, un-control, un-meta lowercase alphabetics.
[Guess I spent too much time using TECO in my youth...]
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Martin Raspaud <········@labri.fr> writes:
> Szymon wrote:
> > [ http://www.strout.net/python/pythonvslisp.html ]
> > Very funny.
> > "...
> > raw scores * weight = adjusted scores
> > Python LISP Python LISP
> > Maturity 7 10 * 5 35 50
> > Syntax 10 2 * 8 80 16
> > Expressiveness 9 8 * 10 90 80
> > Functionality 10 10 * 5 50 50
> > Dev. Activity 4 5 * 8 32 40
> > Open Source 10 0 * 3 30 0
> > Available Modules 10 4 * 7 70 28
> > Extensibility 10 7 * 8 80 56
> > Documentation 8 7 * 6 48 42
> > Mac Integration 8 7 * 4 32 28
> > Current Code 1 10 * 5 9 45
> > Total 87 69 557 435
> > ..."
> > Best regards.
>
>
> If lisp is so great (which I tend to believe, actually) are their so
> many people not using it ?
>
> I mean there must be flaws or something, otherwise everybody would use
> it I suppose.
The correct, but somewhat unsatisfactory, answer to this question is:
there is frequently no relation between quality and popularity.
People's choices are dictated by other things such as propaganda.
> Take for example speed. People say "C is faster than lisp". We
> (lispers) reply "With proper declaration, Lisp is as fast as C". But,
> people, how difficult is that ! I mean I've been declaring things in
> my code to make it efficient, and now I got something full of "the"
> and "declare", which makes the code lot less readable, and I don't
> mention the time I spend on it...
> Ok, maybe I'm wrong, but I think we have to admit lisp is not as
> straightforward as C for exemple.
You have spent a lot of time using Lisp for something that it is
probably worst at (compared to C) namely numeric computations. I am
sure it has been an interesting exercise, but I am not so sure it was
worth it (though you had no way of knowing that beforehand).
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Robert Strandh wrote:
>>Take for example speed. People say "C is faster than lisp". We
>>(lispers) reply "With proper declaration, Lisp is as fast as C". But,
>>people, how difficult is that ! I mean I've been declaring things in
>>my code to make it efficient, and now I got something full of "the"
>>and "declare", which makes the code lot less readable, and I don't
>>mention the time I spend on it...
>>Ok, maybe I'm wrong, but I think we have to admit lisp is not as
>>straightforward as C for exemple.
>
>
> You have spent a lot of time using Lisp for something that it is
> probably worst at (compared to C) namely numeric computations. I am
> sure it has been an interesting exercise, but I am not so sure it was
> worth it (though you had no way of knowing that beforehand).
>
Well, I'll try to make it worth it. (I didn't say I would give up lisp,
yet ;-))
Martin
Martin Raspaud <········@labri.fr> writes:
> Robert Strandh wrote:
> > You have spent a lot of time using Lisp for something that it is
> > probably worst at (compared to C) namely numeric computations. I am
> > sure it has been an interesting exercise, but I am not so sure it was
> > worth it (though you had no way of knowing that beforehand).
>
> Well, I'll try to make it worth it. (I didn't say I would give up
> lisp, yet ;-))
Yes, I understand. What I meant was that it would probably have been
easier to use C + FFI to write the FFT implementation. But you have a
very stubborn adviser.
My experience is that the main trouble is not convincing the Lisp
compiler to generate fast floating point arithmetic. The main trouble
seems to be convincing the compiler that (1+ x) where x is a fixnum is
still a fixnum because we start with (= x 0) and we are doing at most
(say) a million iterations (usually fewer). Since C is using modulo
arithmetic by default, this is not a problem for C.
--
Robert Strandh
Robert Strandh <·······@labri.fr> writes:
> My experience is that the main trouble is not convincing the Lisp
> compiler to generate fast floating point arithmetic. The main trouble
> seems to be convincing the compiler that (1+ x) where x is a fixnum is
What's wrong with just saying (the fixnum (1+ x)) ? That doesn't
seem like very much convincing to me...
> still a fixnum because we start with (= x 0) and we are doing at most
> (say) a million iterations (usually fewer). Since C is using modulo
> arithmetic by default, this is not a problem for C.
Right. The problem for C is convincing the compiler to keep integers
increasing after a certain point...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Robert Strandh <·······@labri.fr> writes:
>
> > My experience is that the main trouble is not convincing the Lisp
> > compiler to generate fast floating point arithmetic. The main trouble
> > seems to be convincing the compiler that (1+ x) where x is a fixnum is
>
> What's wrong with just saying (the fixnum (1+ x)) ? That doesn't
> seem like very much convincing to me...
I do not know how to do that in loop.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Robert Strandh <·······@labri.fr> wrote:
+---------------
| Duane Rettig <·····@franz.com> writes:
| > What's wrong with just saying (the fixnum (1+ x)) ? That doesn't
| > seem like very much convincing to me...
|
| I do not know how to do that in loop.
+---------------
CMUCL seems to generate fairly good code for either of these:
(loop for i fixnum from 0 below 1000
do (foo i))
(loop for i fixnum = 0 then (the fixnum (1+ i))
while (< i 1000)
do (foo i))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Robert Strandh <·······@labri.fr> writes:
>
> Duane Rettig <·····@franz.com> writes:
>
> > Robert Strandh <·······@labri.fr> writes:
> >
> > > My experience is that the main trouble is not convincing the Lisp
> > > compiler to generate fast floating point arithmetic. The main trouble
> > > seems to be convincing the compiler that (1+ x) where x is a fixnum is
> >
> > What's wrong with just saying (the fixnum (1+ x)) ? That doesn't
> > seem like very much convincing to me...
>
> I do not know how to do that in loop.
Well, you can't say that directly for the iteration variable, but
doesn't loop do the right thing (tm) if you write
(loop for x fixnum from 0 to 1000000
...)
Seems to work in ACL 5.0.1 with appropriate compiler optimization
settings. The increment becomes a single machine instruction.
--
Thomas A. Russ, USC/Information Sciences Institute
Robert Strandh asks about type declarations in the LOOP macro
> > What's wrong with just saying (the fixnum (1+ x)) ? That doesn't
> > seem like very much convincing to me...
>
> I do not know how to do that in loop.
It is tucked away in 6.1.1.7 Destructuring
(loop for i of-type (integer 10 20)
from 10 below 11 do (print i))
FIXNUM
=> NIL
With Allegro 6.2
(macroexpand +) =>
(LET ((I 10))
(DECLARE (TYPE (INTEGER 10 20) I))
(BLOCK NIL
(TAGBODY
EXCL::NEXT-LOOP (PRINT (TYPE-OF I))
(EXCL::LOOP-REALLY-DESETQ I (1+ I))
(WHEN (>= I '11) (GO EXCL::END-LOOP))
(GO EXCL::NEXT-LOOP)
EXCL::END-LOOP)))
which is enough for Allegro's compiler to realise that, for
example, (* i i i) is a fixnum and can be compiled with inline
integer multiplication
23: 8b c3 movl eax,ebx
25: f7 6d e4 imull [ebp-28] ; I
28: 8b d8 movl ebx,eax
30: c1 fb 02 sarl ebx,$2
33: 8b c3 movl eax,ebx
35: f7 6d e4 imull [ebp-28] ; I
Alan Crowe
Edinburgh
Scotland
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> Robert Strandh asks about type declarations in the LOOP macro
> > > What's wrong with just saying (the fixnum (1+ x)) ? That doesn't
> > > seem like very much convincing to me...
> >
> > I do not know how to do that in loop.
>
> It is tucked away in 6.1.1.7 Destructuring
>
> (loop for i of-type (integer 10 20)
> from 10 below 11 do (print i))
> FIXNUM
> => NIL
Thanks to everyone for suggestions. I will not have the time to test
them at the moment, but I shall keep them in mind for later.
The main problem seems to be in loops such as:
(loop for i from exp1 below exp2 by exp3 do ...)
where I know that the values of exp1 and exp2+exp3 are fixnums,
especially when using a Lisp that takes declarations to be assertions
and not promises.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
> especially when using a Lisp that takes declarations to be assertions
> and not promises.
If you're referring to CMUCL (my newsfeed already expired your
original article), it takes them as assertions or promises depending
on your optimization settings. I think that (safety 0) is when it
switches to making them promises, but it's been a while since I had to
think about optimizing CMUCL code.
joelh
>>>>> "Robert" == Robert Strandh <·······@labri.fr> writes:
Robert> Martin Raspaud <········@labri.fr> writes:
>> Robert Strandh wrote:
>> > You have spent a lot of time using Lisp for something that it is
>> > probably worst at (compared to C) namely numeric computations. I am
>> > sure it has been an interesting exercise, but I am not so sure it was
>> > worth it (though you had no way of knowing that beforehand).
>>
>> Well, I'll try to make it worth it. (I didn't say I would give up
>> lisp, yet ;-))
Robert> Yes, I understand. What I meant was that it would probably have been
Robert> easier to use C + FFI to write the FFT implementation. But you have a
Robert> very stubborn adviser.
Simple FFT's aren't very hard to write.
Robert> My experience is that the main trouble is not convincing the Lisp
Robert> compiler to generate fast floating point arithmetic. The main trouble
Robert> seems to be convincing the compiler that (1+ x) where x is a fixnum is
Robert> still a fixnum because we start with (= x 0) and we are doing at most
Robert> (say) a million iterations (usually fewer). Since C is using modulo
Then shouldn't you declare that x is of type (integer 0 1000000)?
That usually works for me, and with cmucl/sbcl at high enough safety,
I get a runtime error if I messed up the declaration and x actually
goes up to 1000001.
Ray
Raymond Toy <···········@ericsson.com> writes:
> Then shouldn't you declare that x is of type (integer 0 1000000)?
It seems like when x is incremented, a test still has to be emitted to
check whether x is below 1000000, or am I missing something?
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Robert Strandh <·······@labri.fr> writes:
> Raymond Toy <···········@ericsson.com> writes:
>
>> Then shouldn't you declare that x is of type (integer 0 1000000)?
>
> It seems like when x is incremented, a test still has to be emitted to
> check whether x is below 1000000, or am I missing something?
It sounds like you're talking here about a lisp which checks your
declarations for validity. Even so, a check which can be expressed
purely in terms of fixnum comparisons is very inexpensive compared
with, say, a check that an addition has not exceeded the range of a
fixnum (as must happen with generic addition) since in the former case
the addition can be performed in terms of fixnums only.
Christophe
Christophe Rhodes <·····@cam.ac.uk> wrote:
> It sounds like you're talking here about a lisp which checks your
> declarations for validity. Even so, a check which can be expressed
> purely in terms of fixnum comparisons is very inexpensive compared
> with, say, a check that an addition has not exceeded the range of a
> fixnum (as must happen with generic addition) since in the former case
> the addition can be performed in terms of fixnums only.
...and then there's
(locally
(declare (optimize (safety 0) (speed 3))
(type fixnum x))
(the fixnum (incf x)))
etc.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
Robert Strandh <·······@labri.fr> writes:
> It seems like when x is incremented, a test still has to be emitted
> to check whether x is below 1000000, or am I missing something?
I thought it was so that when you declare a variable to be of some
type, you implicitly promise the compiler that every value you assign
to that variable is of said type?
So, if you declare x to be (unsigned-byte 32), then (setf x (1+ x))
can skip the overflow check, even if the form (1+ x) in isolation
isn't (unsigned-byte 32). And this should also apply to e.g. (loop for
x of-type (unsigned-byte 32) upfrom 0 ...) if I'm not mistaken.
--
Frode Vatvedt Fjeld
>>>>> "RS" == Robert Strandh <·······@labri.fr> writes:
RS> Raymond Toy <···········@ericsson.com> writes:
>> Then shouldn't you declare that x is of type (integer 0
>> 1000000)?
RS> It seems like when x is incremented, a test still has to be
RS> emitted to check whether x is below 1000000, or am I missing
RS> something?
Maybe in safe code, yes, but it is not required. Then again for course
the compiler can ignore your declarations completely.
http://www.lisp.org/HyperSpec/Body/dec_type.html
says:
"...Affects only variable bindings and specifies that the vars take
on values only of the specified typespec. In particular, values
assigned to the variables by setq, as well as the initial values of
the vars must be of the specified typespec. ..."
so (lispworks)
(pprint
(macroexpand '(loop for i of-type (integer 0 1000) from 1 to *foo* do
(print i))))
giving
(BLOCK NIL
(MACROLET ((LOOP-FINISH () '(GO #:|end-loop-629|)))
(LET ((I 1) (#:|to-632| *FOO*) (#:|by-633| 1))
(DECLARE (TYPE (INTEGER 0 1000) I))
(TAGBODY (PROGN
(WHEN (OR (> I #:|to-632|)) (GO #:|end-loop-629|)))
#:|begin-loop-628| (PRINT I)
(PROGN
(LET ((#:|temp-634| (+ I #:|by-633|)))
(SETQ I #:|temp-634|))
(WHEN (OR (> I #:|to-632|)) (GO #:|end-loop-629|)))
(GO #:|begin-loop-628|)
#:|end-loop-629| (RETURN-FROM NIL NIL)))))
should do what you want even regardless of what *foo* is. Maybe I am missing
something?
cheers,
BM
From: Christopher C. Stacy
Subject: Re: troll's food (python vs lisp)
Date:
Message-ID: <uisagep75.fsf@news.dtpq.com>
Robert Strandh <·······@labri.fr> writes:
> The main trouble seems to be convincing the compiler that (1+ x)
> where x is a fixnum is still a fixnum because we start with (= x 0)
> and we are doing at most (say) a million iterations (usually fewer).
> Since C is using modulo arithmetic by default, this is not a problem for C.
If you want modulo arithemetic, you should explicitly write them.
You can do that in Lisp. (And you can make it go fast by adding
type declarations, either in the actual expression, or at the
top of the function.)
That seems like a better idea than (far away from the expression)
declaring a variable to be of some type that (you hope) corresponds
to the integer range that you want, and implicitly using the modulo
semantics of integer overflow / type conversion.
······@news.dtpq.com (Christopher C. Stacy) writes:
> If you want modulo arithemetic, you should explicitly write them.
Well, no I don't. But modulo arithmetic will do, since I now that the
range I need is fairly small.
Also, when using loop, I do not know how to make the loop counter use
modulo arithmetic. Perhaps it is possible, I just do now know how.
> That seems like a better idea than (far away from the expression)
> declaring a variable to be of some type that (you hope) corresponds
> to the integer range that you want, and implicitly using the modulo
> semantics of integer overflow / type conversion.
The problem often seems to be that I know before the start of a loop
how many iterations it will go through, and that number of iterations
is fairly small compared to a fixnum, even when multiplied by some
value k. I then need to convince the compiler that something like :
loop ...
for a from b by k
will make a remain much smaller than a fixnum.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
"Robert Strandh" <·······@labri.fr> wrote in message
···················@serveur5.labri.fr...
> The problem often seems to be that I know before the start of a loop
> how many iterations it will go through, and that number of iterations
> is fairly small compared to a fixnum, even when multiplied by some
> value k. I then need to convince the compiler that something like :
>
> loop ...
> for a from b by k
>
> will make a remain much smaller than a fixnum.
If A is guaranteed to remain smaller than a fixnum, would something
like this:
(loop ...
for a from b below most-positive-fixnum by k
...)
allow the compiler to consider A as a fixnum?
--
Matthieu Villeneuve
On Mon, 13 Sep 2004 10:54:47 +0200, Martin Raspaud wrote:
> I've been declaring things in my code to make it efficient, and now I got
> something full of "the" and "declare", which makes the code lot less
> readable
I was thinking it would be fairly easy to put together some ELisp code
that allows one to toggle between showing and hiding such declarations.
Can anyone see a problem with this idea? Has someone tried this before?
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
From: marco
Subject: Re: troll's food (python vs lisp)
Date:
Message-ID: <m2acvurrvq.fsf@bese.it>
William Bland <·······@abstractnonsense.com> writes:
> On Mon, 13 Sep 2004 10:54:47 +0200, Martin Raspaud wrote:
>> I've been declaring things in my code to make it efficient, and now I got
>> something full of "the" and "declare", which makes the code lot less
>> readable
>
> I was thinking it would be fairly easy to put together some ELisp code
> that allows one to toggle between showing and hiding such declarations.
> Can anyone see a problem with this idea? Has someone tried this before?
this would make for a great macro, something with-floats which would
walk its body and insert all the various THE and DECLARE forms, maybe
you'd limit the body of the macro to jsut certain arithmetic and array
operations to make things easier.
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
On Mon, 13 Sep 2004 19:38:33 +0200, marco wrote:
> William Bland <·······@abstractnonsense.com> writes:
>
>> On Mon, 13 Sep 2004 10:54:47 +0200, Martin Raspaud wrote:
>>> I've been declaring things in my code to make it efficient, and now I got
>>> something full of "the" and "declare", which makes the code lot less
>>> readable
>>
>> I was thinking it would be fairly easy to put together some ELisp code
>> that allows one to toggle between showing and hiding such declarations.
>> Can anyone see a problem with this idea? Has someone tried this before?
>
> this would make for a great macro, something with-floats which would
> walk its body and insert all the various THE and DECLARE forms, maybe
> you'd limit the body of the macro to jsut certain arithmetic and array
> operations to make things easier.
I'm sure I recall seeing a macro just like that here not so long ago.
Yeah, maybe that's the way to go rather than getting Emacs to hide/show
things.
I suppose one could specify a list of operations that the optimisations
should be applied to, e.g.
(with-floats-for (+ - * / aref)
...)
Yeah, that's nicer than hacking ELisp.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
Martin Raspaud wrote:
> ...
> If lisp is so great (which I tend to believe, actually) are their so
> many people not using it ?
>
> I mean there must be flaws or something, otherwise everybody would use
> it I suppose.
i would say lots of it is historical baggage and the momentum of habit.
lisp was used a lot fr AI development, and the people using it typically
had access to resources that were considered luxurious in other
environments. this was reflected in early implementations. personal
anecdotal proof: i first encountered Lisp when i ran across a copy of
the Lisp1.5 manual in my university bookstore. I was intrigued, but no
accessible implementation, and with the hardware i had access to no
chance to get something remotely useful up (i did port SLIP to Algol60,
but to do even the simplest symbolic algebra problem, i had to break
down the program into 3 passes, with the intermediate text passed
between them on paper tape; you can figure out how useful a lisp
implementation would have been on that machine). My first practical
experience was with the first(?) release of franz lisp on vax BSD. I
played around with it, found programming in it quite nice (despite the
dynamic scoping), but resource requirements and performance made it
unusable with my regular work. i finally got around to using it (for
personal projects) when the hardware finally caught up with lisp's
needs, but by then the established languages had polluted the
management's and joe average programmer's mindset sufficiently that it
didn't have much of a chance displacing the established languages.
somehow the old observations have survived as myths abou lisp
> ...
hs
Hartmann Shaffer wrote:
> My first practical experience was with the first(?) release of franz
> lisp on vax BSD. I played around with it, found programming in it
> quite nice (despite the dynamic scoping), but resource requirements
> and performance made it unusable with my regular work. i finally
> got around to using it (for personal projects) when the hardware
> finally caught up with lisp's needs, but by then the established
> languages had polluted the management's and joe average programmer's
> mindset sufficiently that it didn't have much of a chance displacing
> the established languages.
This sounds a lot like my experience. In particular I kept trying
Lisp all during the '90s with increasingly more powerful hardware. At
some point I stopped thinking "too slow" and started thinking "not
bad".
--
Fred Gilham ······@csl.sri.com
I think it's pretty obvious that the worship of that false idol known
as the State has, in the 20th Century, had some very bad effects. The
historians I'm familiar with have settled on the number of dead as 177
million, although I've seen estimates of up to 200 million.
-Bob Wallace
Fred Gilham wrote:
> ...
> This sounds a lot like my experience. In particular I kept trying
> Lisp all during the '90s with increasingly more powerful hardware. At
> some point I stopped thinking "too slow" and started thinking "not
> bad".
same here, but this still seems to be the exception
hs
Hartmann Schaffer <··@hartmann.schaffernet> writes:
> Fred Gilham wrote:
> > ...
> > This sounds a lot like my experience. In particular I kept trying
> > Lisp all during the '90s with increasingly more powerful hardware. At
> > some point I stopped thinking "too slow" and started thinking "not
> > bad".
>
> same here, but this still seems to be the exception
I still think it is kind of odd that speed of execution would be an
issue where Python (the language) is being used as a comparison.
CMUCL/SBCL do pretty well optimizing floating point code.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Hartmann Schaffer <··@hartmann.schaffernet> writes:
>
> > Fred Gilham wrote:
> > > ...
> > > This sounds a lot like my experience. In particular I kept trying
> > > Lisp all during the '90s with increasingly more powerful hardware. At
> > > some point I stopped thinking "too slow" and started thinking "not
> > > bad".
> >
> > same here, but this still seems to be the exception
>
> I still think it is kind of odd that speed of execution would be an
> issue where Python (the language) is being used as a comparison.
>
> CMUCL/SBCL do pretty well optimizing floating point code.
Actually I was interested in GUI code, because I wanted to do
educational stuff, as with Logo. So I kept trying out Lisp GUIs. The
memory of building CLUE + CLIO under GCL on a Sparc 1+, clicking on a
button in the CLIO demo and watching the disk activity light go on and
stay on for more than 5 minutes before anything happened is still with
me. I'll resist the temptation to say it is seared --- seared --- in
me.... :-)
--
Fred Gilham ······@csl.sri.com
An ABC camera crew interviewed Hillary Clinton in the Bahamas, where
she was sunning herself on a flat rock to keep her body temperature
up. "Cookies," she said, eyeing the cameras. "Children." -- Fred Reed
Fred Gilham wrote:
> Actually I was interested in GUI code, because I wanted to do
> educational stuff, as with Logo. So I kept trying out Lisp GUIs. The
> memory of building CLUE + CLIO under GCL on a Sparc 1+, clicking on a
> button in the CLIO demo and watching the disk activity light go on and
> stay on for more than 5 minutes before anything happened is still with
> me. I'll resist the temptation to say it is seared --- seared --- in
> me.... :-)
For lisp GUI try Ltk :)
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Peter Herth wrote:
> For lisp GUI try Ltk :)
It's a point of pride with me that Lisp can host its own damn GUIs.
None of this ``talk to something at the end of a socket that's man
enough to do the drawing for you'' crud for me.
Though I suppose you *could* argue that every program written under X
does this.... :-)
--
Fred Gilham ······@csl.sri.com
``This is mere entertainment featuring fictional characters. No real
human relationships were shattered in the making of this TV series.''
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: troll's food (python vs lisp)
Date:
Message-ID: <87ekl080we.fsf@qrnik.zagroda>
Fred Gilham <······@snapdragon.csl.sri.com> writes:
>> For lisp GUI try Ltk :)
>
> It's a point of pride with me that Lisp can host its own damn GUIs.
I have never seen a native Lisp GUI, so this impression may be
completely wrong, but...
I've seen Squeak. They did everything themselves, in Smalltalk.
Impressive. They implemented their own windowing system (slow),
they made their own fonts (unusable for writing in Polish),
they've written their own web browser (crashes often).
This has shown me the value of interfacing to existing, mature tools.
Not to mention human factors: uniformity of look & feel.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Fred Gilham wrote:
> Peter Herth wrote:
>> For lisp GUI try Ltk :)
>
> It's a point of pride with me that Lisp can host its own damn GUIs.
> None of this ``talk to something at the end of a socket that's man
> enough to do the drawing for you'' crud for me.
It would be nice, if you could point out how this relates to Ltk. I agree
with you, that those GUI kits, which need a server be started before the
GUI program can be started are undesirable - I can only assume you mean
those with the socket reference. Ltk does not belong into this cathegory
in my opinion for several reasons. First of all it doesnt use sockets, but
that isn't the point. It is true that Ltk uses a pipe to talk to a separate
Tk process, but that is totally invisible to the programmer as well as the
user of the Ltk program. As is the network layer of X11 for every GUI
program, being written in C or whatever else.
So what in my opinion makes up a "native" GUI is foremost, that you can
use it from your language in a seamless way, and that was the mayor goal
of writing Ltk in contrast to bindings like "with-wish" which made the user
to see and use Tk code. That Ltk is very spammy in echoing the communication
currently serves as a debugging help, but is easily switched off by setting
*debug-tk* to nil.
But it should be invisible whether the communication runs over some layers
like pipes or whether the libs are linked to the lisp image itself. The
latter is not used as much simply because there is no standard for FFI yet.
As soon as for example UFFI covers enough to be a base (callbacks are
missing currenty), more directly linked libs may appear.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Peter Herth wrote:
> Fred Gilham wrote:
>
>>Peter Herth wrote:
>>
>>>For lisp GUI try Ltk :)
>>
>>It's a point of pride with me that Lisp can host its own damn GUIs.
>>None of this ``talk to something at the end of a socket that's man
>>enough to do the drawing for you'' crud for me.
>
>
> It would be nice, if you could point out how this relates to Ltk.
LTk or any interface to Tk is nifty, but it is not native. It is Tk. One
is restricted to Tk widgets and items (in a Tk canvas widget). The whole
thing works the way Tk says it will work. One gets anti-aliased text if
and only if TK on ones platform supports anti-aliased text. One does
layout The Tk Way. That hapens to be powerful, but one /is/ constrained
by the Tk design decisions.
A native GUI library gives the Lispnik an event stream and low-level
drawing. Widgets arise from Lisp code processing events and drawing. One
has the Lisp source to look at to understand or even debug a canned
widget. One can clone a widget and modify the Lisp to get a more or less
different widget by altering the low-level event handling and/or drawing.
Something like AllegroCl's Common Graphics gui lib or MCL's gui
framework are thin layers around the win32 or (back in the day) OS9
window system, such that one can easily custom-handle OS events or draw
custom widgets while at the same time using canned widgets where canned
behavior suffices.
Tk does offer some access to the event stream, so we are in a bit of a
gray area, but on the whole LTk is not a Lisp GUI, it is a Lisp
interface to a (fine) "C" GUI.
> So what in my opinion makes up a "native" GUI is foremost, that you can
> use it from your language in a seamless way, and that was the mayor goal
> of writing Ltk in contrast to bindings like "with-wish" which made the user
> to see and use Tk code.
I have been puzzled by this claim in the past. LTk hides some of the
work of talking to Tk, but one is still using Tk widgets and items and
needs to know their options. And one is still using the Tk layout
manager and needs to know how that works. Mind you, I do not see this as
a bad thing, because Tk itself is a fine toolkit with loads of options.
But the only way an LTk user can avoid stocking up on Tk manuals is to
limit oneself to the simple examples in the LTk demos. But real users
will quickly want to avail themselves of most of Tk's features--they
exist precisely because they are the things GUI programmers need.
In Celtic (my LTk derivative), all Tk widgets and items are exposed to
the Celtic developer with all options available, so as to give the user
the full power of Tk. The alternative would be to erect a new GUI
framework which only happens to be implemented by the Tk framework. Why
bother? Not simplicity; if the new framework has any success, users will
quickly demand all the functionality which led to Tk having as many
features as it does.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
> LTk or any interface to Tk is nifty, but it is not native. It is Tk. One
> is restricted to Tk widgets and items (in a Tk canvas widget). The whole
> thing works the way Tk says it will work. One gets anti-aliased text if
> and only if TK on ones platform supports anti-aliased text. One does
> layout The Tk Way. That hapens to be powerful, but one /is/ constrained
> by the Tk design decisions.
But is this really relevant to "native" or does this not apply to any
GUI lib that you link to your program ? If I use CAPI I only get
anti aliased text when the CAPI lib or the underlying OS provides it.
You are always constrained by design decisions of any library you use.
> A native GUI library gives the Lispnik an event stream and low-level
> drawing. Widgets arise from Lisp code processing events and drawing. One
> has the Lisp source to look at to understand or even debug a canned
> widget. One can clone a widget and modify the Lisp to get a more or less
> different widget by altering the low-level event handling and/or drawing.
Well looking that way, most languages do NOT have native GUI libs.
Java with Swing uses this approach and is not very highly regarded.
> Something like AllegroCl's Common Graphics gui lib or MCL's gui
> framework are thin layers around the win32 or (back in the day) OS9
> window system, such that one can easily custom-handle OS events or draw
> custom widgets while at the same time using canned widgets where canned
> behavior suffices.
>
> Tk does offer some access to the event stream, so we are in a bit of a
> gray area, but on the whole LTk is not a Lisp GUI, it is a Lisp
> interface to a (fine) "C" GUI.
Fine, then to get a true Lisp gui, we should use only graphics primitives
of the underlying system and build everything "by hand". I can remember
the long threads critisicing exactly that approach of your first GL based
cells gui...
> I have been puzzled by this claim in the past. LTk hides some of the
> work of talking to Tk, but one is still using Tk widgets and items and
> needs to know their options. And one is still using the Tk layout
> manager and needs to know how that works. Mind you, I do not see this as
> a bad thing, because Tk itself is a fine toolkit with loads of options.
> But the only way an LTk user can avoid stocking up on Tk manuals is to
> limit oneself to the simple examples in the LTk demos. But real users
> will quickly want to avail themselves of most of Tk's features--they
> exist precisely because they are the things GUI programmers need.
But again this has *nothing* to do with native/nonnative. Whenever
you use a library you need to know about its options, and how their
functions work. The only thing where Ltk is lagging a bit behind is
that the documentation I wrote does not completely cover all details,
but that will be fixed over time.
> In Celtic (my LTk derivative), all Tk widgets and items are exposed to
> the Celtic developer with all options available, so as to give the user
> the full power of Tk. The alternative would be to erect a new GUI
> framework which only happens to be implemented by the Tk framework. Why
> bother? Not simplicity; if the new framework has any success, users will
> quickly demand all the functionality which led to Tk having as many
> features as it does.
I fail to see the difference to the Ltk approach. Its aim is to cover
the full power of Tk and it is *very* close to that - there may be missing
bits and pieces and some improvements to come, but that is the target for
1.0.
To avoid any misunderstandings: I made my previous and this post not
to discuss how "good" Ltk is, I wanted to discuss what "native" truely
means and in which respects Ltk may not be considered native, compared
to any mayor GUI lib.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Peter Herth <·····@netcologne.de> writes:
> Kenny Tilton wrote:
> [about native gui in lisp]
If you want a native GUI in Lisp have a look at garnet
(http://garnetlisp.sourceforge.net/)
It even implements (some ten or fifteen years before) the "slots whose
values are determined by a formula" of Cells. (Granted, not on CLOS,
but on KR).
One advantage of Ltk and similar solutions is that you don't need to
install X to deploy your applications on MS-Windows or MacOSX (even if
MacOSX comes with an optional X server). But since you have to
install tcl/tk (or ensure that it is installed) anyway, you could do
the same job for X and deploy as easily garnet.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
On Sat, 18 Sep 2004 20:10:15 +0200, Pascal Bourguignon wrote:
> If you want a native GUI in Lisp have a look at garnet
> (http://garnetlisp.sourceforge.net/)
Garnet FAQ #12
(http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/garnet/garnet/FAQ)
is rather depressing :-(
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland <·······@abstractnonsense.com> writes:
> On Sat, 18 Sep 2004 20:10:15 +0200, Pascal Bourguignon wrote:
> > If you want a native GUI in Lisp have a look at garnet
> > (http://garnetlisp.sourceforge.net/)
>
> Garnet FAQ #12
> (http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/garnet/garnet/FAQ)
> is rather depressing :-(
Only the following point stays valid:
* Interfaces to interesting external stuff appears immediately in C
but often never in Lisp. We want to use X extensions, OpenGL, Display
Postscript, multimedia, IPC, network stuff, etc. There are still no
extensions to CLX for many of the additions to X since R3.
Keep in mind that this FAQ has been written ten or twelve years ago
(last modified eight years ago).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
On Sat, 18 Sep 2004 22:31:36 +0200, Pascal Bourguignon wrote:
> William Bland <·······@abstractnonsense.com> writes:
>> Garnet FAQ #12
>> (http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/garnet/garnet/FAQ)
>> is rather depressing :-(
>
> Only the following point stays valid:
>
> * Interfaces to interesting external stuff appears immediately in C
> but often never in Lisp. We want to use X extensions, OpenGL, Display
> Postscript, multimedia, IPC, network stuff, etc. There are still no
> extensions to CLX for many of the additions to X since R3.
>
> Keep in mind that this FAQ has been written ten or twelve years ago
> (last modified eight years ago).
Ah, that is encouraging - thanks!
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
From: Chris Capel
Subject: Re: For a native GUI in Lisp see GARNET! Was: troll's food (python vs lisp)
Date:
Message-ID: <10kps82d9t0h4ed@corp.supernews.com>
Pascal Bourguignon wrote:
> Only the following point stays valid:
>
(snip)
>
> Keep in mind that this FAQ has been written ten or twelve years ago
> (last modified eight years ago).
What about that 2-3 times slower than C++ thing? Would that be due to the
increase in the quality and maturity of Lisp compilers and profiling tools?
Or do you mean that that sort of difference in speed no longer matters, as
a GUI framework in any language is ten times too fast to have any
noticeable slowness?
Chris Capel
Chris Capel <······@iba.nktech.net> writes:
> Pascal Bourguignon wrote:
>
> > Only the following point stays valid:
> >
> (snip)
> >
> > Keep in mind that this FAQ has been written ten or twelve years ago
> > (last modified eight years ago).
>
> What about that 2-3 times slower than C++ thing? Would that be due to the
> increase in the quality and maturity of Lisp compilers and profiling tools?
> Or do you mean that that sort of difference in speed no longer matters, as
> a GUI framework in any language is ten times too fast to have any
> noticeable slowness?
Yes, both.
If you really wanted, you could render lisp garnet code as fast as any
C++ implementation. But it does not matter anymore on current and
future hardware.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Pascal Bourguignon wrote:
> Peter Herth <·····@netcologne.de> writes:
>
>>Kenny Tilton wrote:
>>[about native gui in lisp]
>
>
> If you want a native GUI in Lisp have a look at garnet
> (http://garnetlisp.sourceforge.net/)
>
> It even implements (some ten or fifteen years before) the "slots whose
> values are determined by a formula" of Cells. (Granted, not on CLOS,
> but on KR).
Oh, sure, I always cite KR of Garnet as prior art of Cells. Sketchpad in
63 was cited by Steele twenty years later in his CLP/thesis as perhaps
the first constraints hack. COSI (LUGM '99 talk) is another. In fact, I
think constraints is one of those deals where it is hard to find someone
who is not developing their own version.
Cells is just a popularizer. It is easier to program than true
constraint mechanisms (which are intractably hard to program), more
powerful than other linear dataflow mechanisms, and as you say has the
advantage of working with CLOS where Garnet has its own object model.
LTk is not a Lisp GUI because Tk is sitting there between the Lisp
application and the native GUIs. Cello is Lisp but not native, because
it bypasses the win32/Mac GUIs (and it is not even pure Lisp in that it
has Glut sitting between the Lisp app and the OS, but that is a
relatively thin layer one could excise if that is where one wants to
burn ones time).
Me, I think the Web eliminates the native issue, so I prefer the "more
Lisp, less native" tradeoff of Cello. But LTk is a great solution for
folks who can accept the Tk design decisions and LCD blandness in return
for rapid development of portable apps. Also Tk is mature, whereas Cello
is still just rising from the sea.
And yes, some folks still love Garnet, non-CLOS notwithstanding.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Joel Ray Holveck
Subject: Re: Continuation-based web server (Was: For a native GUI in Lisp see GARNET!)
Date:
Message-ID: <y7cacvkghrv.fsf@sindri.juniper.net>
> Unfortunately, Lisp doesn't have native continuations or coroutines,
[...]
> You could use a multithreaded model to simulate the needed
> coroutine support, where each transaction is held in its own thread,
Sorry to reply to myself, but it just occurred to me that coroutines
(and hence a multithreaded implementation of same) would break the
browser's back button. So there's a problem with that route as well.
joelh
From: Randall Randall
Subject: Re: Continuation-based web server (Was: For a native GUI in Lisp see GARNET!)
Date:
Message-ID: <414ffb75$1_1@alt.athenanews.com>
Joel Ray Holveck wrote:
> Since web interfaces are non-persistent, there's lots of things that
> don't easily get coded towards the web. In particular, anything that
> needs to maintain a lot of state ends up using a lot of its code for
> state management, and the transactional structure means much less
> flexibility in layout.
Once you've written a framework to handle that, though, you
don't really have to worry about it again.
> But what I've always wondered about is a Lisp web system that uses
> continuations or coroutines to implement form input. Last time I
> looked, I didn't see one, but I could be off my rocker here. Here's
> what I'm imagining:
>
> (defurl "/employee" ()
> (loop
> (print-string "What's the employee name or ID number?")
> (print-input-box 'name-box)
> (print-input-box 'id-box)
> (print-submit)
> (destructuring-bind (name id)
> (get-response '(name-box id-box))
> (let ((emp (if id (emp-by-id id) (emp-by-name name))))
> (print-string "Name:")
> (print-string (name emp))
> (print-string "Department:")
> (print-string (dept emp))))
> (print-string "You can find another employee if you want.")
> (print-string "Just use the box below.")))
>
> (Note that this is meant to give an idea of the general flow, not
> specific functions: in particular, defurl and print-* are obviously
> not thought out here. The main point is get-response.)
[snip]
> Has anybody seen a web server (or other system) that works about like
> this?
PSILISP, my webapp framework, does this:
(defun show-name-and-id (page session)
(write-box (session "css-id" "css-class"
:heading "Name/ID form" :nickname trickle)
(with-form (trickle :hash-keys (name id))
(deform ((atts "css-id" "css-class") :session session :show-form T)
(input (:name "name" :type "text" :value "your name here"))
(input (:name "id" :type "text" :value "your id here"))
(input (:name "submit" :type "submit" :value "Continue")))
(trickle (span (atts "css-id" "css-class") "Name: " name))
(trickle (span (atts "css-id" "css-class") "Id: " id)))))
Of course, you can nest (with-form ...) statements, too, and have
previous forms remembered, but with new information overriding saved
information, so that hitting the back button works exactly as the
user would hope.
PSILISP doesn't have much documentation as yet, but almost
everything has docstrings! :)
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
From: marco
Subject: Re: Continuation-based web server (Was: For a native GUI in Lisp see GARNET!)
Date:
Message-ID: <m2fz5bhkcm.fsf@bese.it>
Joel Ray Holveck <·····@juniper.net> writes:
> But what I've always wondered about is a Lisp web system that uses
> continuations or coroutines to implement form input. Last time I
> looked, I didn't see one, but I could be off my rocker here. Here's
> what I'm imagining:
UnCommon Web - http://common-lisp.net/project/ucw
> (defurl "/employee" ()
> (loop
> (print-string "What's the employee name or ID number?")
> (print-input-box 'name-box)
> (print-input-box 'id-box)
> (print-submit)
> (destructuring-bind (name id)
> (get-response '(name-box id-box))
> (let ((emp (if id (emp-by-id id) (emp-by-name name))))
> (print-string "Name:")
> (print-string (name emp))
> (print-string "Department:")
> (print-string (dept emp))))
> (print-string "You can find another employee if you want.")
> (print-string "Just use the box below.")))
[untested]
(defentry-point "/employee" () ()
(loop
for employee = (call 'get-employee)
do (call 'view-employee :employee employee)))
(defcomponent get-employee (standard-component)
((name :accessor name :initform nil)
(id :accessor id :initform nil)))
(defmethod render-on ((res response) (comp get-employee))
(<:html
(<:head (<:title "lookup employee"))
(<:body
(<ucw:form (lookup comp)
(<:p "Name: " (<ucw:input :type "text" :accessor (name comp)))
(<:p "Id: " (<ucw:input :type "text" :accessor (id comp)))
(<:p (<ucw:input :type "submit" :value "lookup"))))))
(defaction lookup ((comp get-employee))
;; if both name and id have been supplied we use id.
(with-slots (id name) comp
(cond
(id (if (emp-by-id id)
(answer (emp-by-id id))
(call 'error-message
:message (format nil "No employee with id ~S." id))))
(name (if (emp-by-name name)
(answer (emp-by-name name))
(call 'error-message
:message (format nil "No employee with name ~S." name))))
(t (call 'error-message
:message "You must supply either a name or an id."
:ok-text "Return te employee lookup page.")))))
(defcomponent view-employee (standard-component)
((employee :initarg :employee :accessor employee))
(:template "view-employee.tal"
;; access the employee's slots by name in the template.
(make-standard-environment (employee view-employee))))
i got bored and didn't bother implementating the template for
view-employee, but you get the idea. this example is pretty trivial,
you only have two pages, the order they're viewed in is always the
same. things don't get interesting until you have actions like this
one:
(defaction purchase ((cart cart))
(symbol-macrolet ((user (session.object-pool :user)))
(unless user (setf user (call 'login/register)))
(unless (and (one-click-shopper user)
(have-payment-methods user)
(have-shipping-method user))
(if (have-payment-methods user)
(call 'check-payment-methods :methods (payment-methods user))
(call 'get-payment-methods))
(if (have-shipping-method user)
(call 'check-shipping-method :method (shipping-method user))
(call 'get-shipping-method))
(call 'confirm-order :order cart))
(open-transaction cart)
(let ((purchase-result (call 'make-order)))
(if (eql :ok purchase-result)
(clear-cart cart)
(call 'cart-error :result purchase-result)))
(close-transaction cart)
(call 'orders-summary)))
in one block of code you (the developer) see every component involved
and how they interact. until you reach this level of complexity i'd
leave continuations alone.
> Unfortunately, Lisp doesn't have native continuations or coroutines,
> and I don't think that shoehorning them in with a library would be
> trivial.
it doesn't have to be trivial, it just has to require less work than
the other options. at the same time the "other options" basically
maount to writing your code in a very poor, very spaghetti cps anyway,
so you may as well just bit the bullet and make the machine do it.
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
>> But what I've always wondered about is a Lisp web system that uses
>> continuations or coroutines to implement form input. Last time I
>> looked, I didn't see one, but I could be off my rocker here. Here's
>> what I'm imagining:
> UnCommon Web - http://common-lisp.net/project/ucw
What you describe looks just like what I was asking about; thanks!
It apparently uses the arnesi library's WITH-CALL/CC to implement its
continuations. This isn't as complete of a call/cc implementation as
(for example) Scheme, but it does seem to be complete enough for the
purposes of this web page. I'll have to investigate this in more
detail.
Thanks for the link, that's exactly what I was looking for!
Cheers,
joelh
--
Joel Ray Holveck - ·····@piquan.org
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
Peter Herth <·····@netcologne.de> wrote:
+---------------
| Fred Gilham wrote:
| > It's a point of pride with me that Lisp can host its own damn GUIs.
| > None of this ``talk to something at the end of a socket that's man
| > enough to do the drawing for you'' crud for me.
|
| It would be nice, if you could point out how this relates to Ltk. I agree
| with you, that those GUI kits, which need a server be started before the
| GUI program can be started are undesirable - I can only assume you mean
| those with the socket reference. Ltk does not belong into this cathegory
| in my opinion for several reasons. First of all it doesnt use sockets, but
| that isn't the point. It is true that Ltk uses a pipe to talk to a separate
| Tk process...
+---------------
Uh... Under BSD Unix, pipes *are* sockets!! [Unnamed Unix-domain, but still.]
+---------------
| ...but that is totally invisible to the programmer as well as the
| user of the Ltk program.
+---------------
(*grumpf!*) It's certainly not "totally invisible" when the Ltk server
process crashes or hangs or fails to get killed when the Lisp process
exits, etc., etc. Don't get me wrong, the CMUCL "clm" Motif binding
works the same way, and has the same issues.
+---------------
| As is the network layer of X11 for every GUI program, being written
| in C or whatever else.
+---------------
I suspect what Fred was trying to point out is that classic Lisp GUIs
[especially anything based on CLX] connect *directly* to the X11 server
(or whatever the system GUI is), *without* accessing any C-coded library
of widgets. Look at the code for CLX, and you'll see what he means.
+---------------
| But it should be invisible whether the communication runs over some
| layers like pipes...
+---------------
Well, except for little things like performance and reliability.
+---------------
| ...or whether the libs are linked to the lisp image itself.
+---------------
What Fred is talking about is writing the libs *in* Lisp itself, running
in the same process image as the application. [Again, see CLX and the
hordes of GUIs built on top of it.]
+---------------
| The latter is not used as much simply because there is no standard
| for FFI yet.
+---------------
Again, the point is that CLX [and GUIs based on it] uses no FFI at all
(except for the socket connection to X11, if that's what the system has).
-Rob
p.s. Don't get us wrong: LTk is neat, and offers a quick way to get
started. But I also have several "production" tools that use CLX,
and once you've coded the basic CREATE-WINDOW/CREATE-GCONTEXT stuff
a couple of times, it's not too hard to do simple things in, either.
The real question will be to see how far intermediate-server-based
things like LtK (or CLM, for that matter) can grow before you need
to use some more complex widget infrastructure (nd whether that's
written directly in pure Lisp or with FFI bindings to C libraries).
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Uh... Under BSD Unix, pipes *are* sockets!! [Unnamed Unix-domain, but
> still.]
Ok - but as I said, the differentiation between pipe and socket was
not a relevant point in this discussion.
> (*grumpf!*) It's certainly not "totally invisible" when the Ltk server
> process crashes or hangs or fails to get killed when the Lisp process
> exits, etc., etc. Don't get me wrong, the CMUCL "clm" Motif binding
> works the same way, and has the same issues.
If you have issues there, please report them so I chan check how they
could be resolved.
> +---------------
> | As is the network layer of X11 for every GUI program, being written
> | in C or whatever else.
> +---------------
>
> I suspect what Fred was trying to point out is that classic Lisp GUIs
> [especially anything based on CLX] connect *directly* to the X11 server
> (or whatever the system GUI is), *without* accessing any C-coded library
> of widgets. Look at the code for CLX, and you'll see what he means.
I rather talked about the "native" GUIs you get in other languages, like
Swing, Gtk or QT.
> +---------------
> | But it should be invisible whether the communication runs over some
> | layers like pipes...
> +---------------
>
> Well, except for little things like performance and reliability.
It is obvious that Ltk tries not to be a performance leader. However it
should be quite good in the reliability section - if not, please bug me :)
> p.s. Don't get us wrong: LTk is neat, and offers a quick way to get
> started. But I also have several "production" tools that use CLX,
> and once you've coded the basic CREATE-WINDOW/CREATE-GCONTEXT stuff
> a couple of times, it's not too hard to do simple things in, either.
> The real question will be to see how far intermediate-server-based
> things like LtK (or CLM, for that matter) can grow before you need
> to use some more complex widget infrastructure (nd whether that's
> written directly in pure Lisp or with FFI bindings to C libraries).
Yes I said before: I don't consider this discussion about the pros
and cons of Ltk - rather I was a little bit irritatet how the term
"native" was used in general and in relation to Ltk in special.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Peter Herth wrote:
> Yes I said before: I don't consider this discussion about the pros
> and cons of Ltk - rather I was a little bit irritatet how the term
> "native" was used in general and in relation to Ltk in special.
My reaction is something along the same lines --- irritation ---
though the content is different. Many years ago CMUCL went away from
using a native CLX based inspector to a system with a toolkit that
talked to a Motif daemon that did the drawing. I found this really
strange, especially since the resulting setup was unreliable and hard
to keep working. I thought it was a waste of effort that could have
gone into building tools and toolkits based on CLX.
My own efforts have involved resurrecting some of the old Lisp code
such as Garnet. Garnet is a reasonably good system with one major
drawback --- it uses an object system that isn't standard. It runs
on X and also runs (ran) on the Mac and there are rumors of a Windows
port. So it could be a reasonable cross-platform system.
There is also McCLIM which is designed to be a cross-platform GUI
system.
Why is this important to me? Because the Lisp based GUIs are
mind-stretching. The Lisp approach seems to spill over into the way
the GUIs are designed. Garnet, for example, uses a prototype-instance
approach to building graphical objects, and a constraint system for
controlling them. Cello seems to be aimed at combining the best
features of constraint programming and CLOS for use in GUI
programming. CLIM uses a presentation system that exploits CLOS in a
clever way.
Ltk seems quite useful, especially for people who want to get
something programmed and working in a short time.
But it's not `macho' if I can be excused for using the term. That was
the intent of my original, tongue-in-cheek, posting. Lisp is a macho
programming environment, and deserves macho GUI systems.
BTW, please don't confuse the above use of `macho' with the Lisp-based
mail digest system of the same name. :-)
--
Fred Gilham ······@csl.sri.com
The opponents of income taxation in 1912 said that we would see the
day when taxes would extract 25% of people's income. Such Cassandras
were ridiculed. -- Gary North
Fred Gilham wrote:
> Ltk seems quite useful, especially for people who want to get
> something programmed and working in a short time.
>
> But it's not `macho' if I can be excused for using the term. That was
> the intent of my original, tongue-in-cheek, posting. Lisp is a macho
> programming environment, and deserves macho GUI systems.
I like the term "macho" much better :). And I think I can understand
how you feel. Actually I think Ltk should only be the first stage.
It aims to give uncomplicated access to a powerfull widget set. However
this can only be a start, a further aim would be to have a more Lispy
high-level layer above Ltk.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> My own efforts have involved resurrecting some of the old Lisp code
> such as Garnet. Garnet is a reasonably good system with one major
> drawback --- it uses an object system that isn't standard. It runs
> on X and also runs (ran) on the Mac and there are rumors of a Windows
> port. So it could be a reasonable cross-platform system.
That won't be anything from out of tomb! garnet works perfectly well
on current clisp for example.
> There is also McCLIM which is designed to be a cross-platform GUI
> system.
But it does not work yet with clisp...
> Why is this important to me? Because the Lisp based GUIs are
> mind-stretching. The Lisp approach seems to spill over into the way
> the GUIs are designed. Garnet, for example, uses a prototype-instance
> approach to building graphical objects, and a constraint system for
> controlling them. Cello seems to be aimed at combining the best
> features of constraint programming and CLOS for use in GUI
> programming. CLIM uses a presentation system that exploits CLOS in a
> clever way.
>
> Ltk seems quite useful, especially for people who want to get
> something programmed and working in a short time.
>
> But it's not `macho' if I can be excused for using the term. That was
> the intent of my original, tongue-in-cheek, posting. Lisp is a macho
> programming environment, and deserves macho GUI systems.
>
> BTW, please don't confuse the above use of `macho' with the Lisp-based
> mail digest system of the same name. :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Peter Herth wrote:
> Yes I said before: I don't consider this discussion about the pros
> and cons of Ltk - rather I was a little bit irritatet how the term
> "native" was used in general and in relation to Ltk in special.
Has a subtle distinction been lost? The rap is not that a Tk-based Lisp
GUI is not native, it is that it is not Lisp. AllegroCl offers Common
Graphics, and the last MCL I used (4.3) included a framework whose
classes thinly wrapped OS9 native widgets, and all that code is in Lisp
and available to developers during debugging or cloning. And those
frameworks are Lispy.
Translate Tk to Lisp and then LTk can be a Lisp GUI. as it is, LTk is a
quick, effective, but deeply limited way to leverage a C GUI framework
to give a Lisp app a GUI.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
On Fri, 17 Sep 2004 19:56:07 +0200, Peter Herth <·····@netcologne.de>
wrote:
> Fred Gilham wrote:
>
>> Actually I was interested in GUI code, because I wanted to do
>> educational stuff, as with Logo. So I kept trying out Lisp GUIs. The
>> memory of building CLUE + CLIO under GCL on a Sparc 1+, clicking on a
>> button in the CLIO demo and watching the disk activity light go on and
>> stay on for more than 5 minutes before anything happened is still with
>> me. I'll resist the temptation to say it is seared --- seared --- in
>> me.... :-)
>
> For lisp GUI try Ltk :)
>
> Peter
>
Me I've decided to jump in and buy a professional version of LispWorks.
CAPI a cross platform GUI which uses native windows look and feel is
one of the most important reasons. Also their IDE has a dialog builder and
access to most of the functionality of the symbolics lisp machine (GUI
wise).
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad wrote:
> On Fri, 17 Sep 2004 19:56:07 +0200, Peter Herth <·····@netcologne.de>
> wrote:
>
> > Fred Gilham wrote:
> >
> >> Actually I was interested in GUI code, because I wanted to do
> >> educational stuff, as with Logo. So I kept trying out Lisp GUIs.
> The >> memory of building CLUE + CLIO under GCL on a Sparc 1+,
> clicking on a >> button in the CLIO demo and watching the disk
> activity light go on and >> stay on for more than 5 minutes before
> anything happened is still with >> me. I'll resist the temptation to
> say it is seared --- seared --- in >> me.... :-)
> >
> > For lisp GUI try Ltk :)
> >
> > Peter
> >
>
> Me I've decided to jump in and buy a professional version of
> LispWorks. CAPI a cross platform GUI which uses native windows look
> and feel is one of the most important reasons. Also their IDE has a
> dialog builder and access to most of the functionality of the
> symbolics lisp machine (GUI wise).
Is this IDE only in the professional version (as opposed to the
personal one)? I love CAPI and am just inches from purchasing the
professional license -- I've just fallen in love with everything in
LispWorks. If it does have a dialog builder (ala Visual Studio) that
would definitely push me over the edge.
Jeff
--
Progress in computer technology is waiting for people to stop
re-inventing the wheel.
- Dr. William Bland (comp.lang.lisp)
On Sat, 18 Sep 2004 14:55:32 GMT, Jeff <···@nospam.insightbb.com> wrote:
>
> Is this IDE only in the professional version (as opposed to the
> personal one)? I love CAPI and am just inches from purchasing the
> professional license -- I've just fallen in love with everything in
> LispWorks. If it does have a dialog builder (ala Visual Studio) that
> would definitely push me over the edge.
>
> Jeff
>
Look at Tools->"Interface Builder" in the user guide.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
In article <················@mjolner.upc.no>,
"John Thingstad" <··············@chello.no> wrote:
> On Sat, 18 Sep 2004 14:55:32 GMT, Jeff <···@nospam.insightbb.com> wrote:
>
> >
> > Is this IDE only in the professional version (as opposed to the
> > personal one)? I love CAPI and am just inches from purchasing the
> > professional license -- I've just fallen in love with everything in
> > LispWorks. If it does have a dialog builder (ala Visual Studio) that
> > would definitely push me over the edge.
> >
> > Jeff
> >
>
> Look at Tools->"Interface Builder" in the user guide.
Though the Interface Builder is not available for Mac OS X and Unix.
It is available for Windows and Linux.
"John Thingstad" <··············@chello.no> writes:
> Me I've decided to jump in and buy a professional version of LispWorks.
> CAPI a cross platform GUI which uses native windows look and feel is
> one of the most important reasons. Also their IDE has a dialog builder and
> access to most of the functionality of the symbolics lisp machine (GUI
> wise).
Unfortunately, this no option for everyone. If I was to pay $999
(LispWorks Professional) for each platform I happen to use and want to
deploy software on (ok, FreeBSD is not supported, that leaves Windows
and Linux)...
Regards,
--
____________________________
Julian Stecklina / _________________________/
________________/ /
\_________________/ LISP - truly beautiful
In article <··············@goldenaxe.localnet>,
Julian Stecklina <··········@web.de> wrote:
> "John Thingstad" <··············@chello.no> writes:
>
> > Me I've decided to jump in and buy a professional version of LispWorks.
> > CAPI a cross platform GUI which uses native windows look and feel is
> > one of the most important reasons. Also their IDE has a dialog builder and
> > access to most of the functionality of the symbolics lisp machine (GUI
> > wise).
>
> Unfortunately, this no option for everyone. If I was to pay $999
> (LispWorks Professional) for each platform I happen to use and want to
> deploy software on (ok, FreeBSD is not supported, that leaves Windows
> and Linux)...
>
> Regards,
If you really want to buy LispWorks for several platforms with delivery
option, you should contact Xanalys for a pricing offer. ;-)
Anyway, it is quite a good deal for commercial development.
For comparison: I just saw a project paying probably more than
50000 Euro for a few licenses of Borland's Together.
But as you said, it is not an option for everyone...
Martin Raspaud wrote:
> I mean there must be flaws or something, otherwise everybody would use
> it I suppose.
Well, that doesn't follow unless you define "flaws"
rather oddly. But yes, of course Lisp has flaws, as
has every other language. It's just that what the
referenced page appears to say are flaws of Lisp
are mostly no such thing. (And, on closer inspection,
it turns out that it's mostly not actually saying
that anyway.)
I rather suspect that for most "minority" languages
there are widely held ideas about what their major
flaws are, which turn out to be incorrect. For instance,
"everybody knows" that Lisp's main flaws are that it
can't run quickly (not true), that its only data structure
is the list (not true), and that it has all those awful
bendy parenthesis things (not a flaw). "Everybody knows"
that Python's main flaws are that it has significant
whitespace (not a flaw) and that it's dynamically typed
(not a flaw). Oh, and that it's slow (true); score one
for popular prejudice. "Everybody knows" that Fortran's
main flaws are that it's only any use for numerical
computation (not true any more) and that it has a nasty
inflexible syntax with all uppercase and things in fixed
columns (not true any more).
I oversimplify, of course. But when someone who isn't
familiar with a programming language makes claims about
what's wrong with it, there's an excellent chance that
they're wrong. :-)
--
Gareth McCaughan
.sig under construc
Martin Raspaud <········@labri.fr> wrote in message
> Take for example speed. People say "C is faster than lisp". We (lispers)
> reply "With proper declaration, Lisp is as fast as C". But, people, how
> difficult is that ! I mean I've been declaring things in my code to make
> it efficient, and now I got something full of "the" and "declare", which
> makes the code lot less readable, and I don't mention the time I spend
> on it...
> Ok, maybe I'm wrong, but I think we have to admit lisp is not as
> straightforward as C for exemple.
I think you really should try out Bigloo, though, it is a Scheme
language.
Bigloo has definitely an easy to use type declaration facility, which,
always! works; even for the unexperienced and code is not cluttered
up!
I use Bigloo for numerical computations. There are two choices in
Bigloo:
a) For basic types you can use Bigloo its operators: fl*, fl+,... You
can write then a simple macro and you ensure than your code runs on
other Scheme implementations too. The aformentioned types make Bigloo
a rather picky compiler because it is always ensured then that your
array for example consists really only of lets say double precision
numbers.
b) A typical type declaration in Bigloo (syntax highlighting would be
cool now):
==
(define (add_a_b::double a::double b::double)
(+ a b))
==
Surely, Bigloo its type system is not perfect. I often had the wish to
create a type which says: "This list holds simply integer values".
Clearly, I assume, the latter has more to do with static type analysis
(which you would get in OCaml) for example. A typical list of type
"pair" may hold anything.
But Bigloo its type system is a huge step forward into a better world,
because it improves readability of code tremendously as compared to
lets say ordinary Scheme code:
==
(define (mul_x_y::vector a::pair b::pair c::vector d::bint e::double
f::double)
(....))
==
...it so much better than:
==
(define (mul_x_y a b c d e f)
(...))
==
Fensterbrett
Martin Raspaud wrote:
> If lisp is so great (which I tend to believe, actually) are their so
> many people not using it ?
Because most people are girlie programmers.
Wade
Wade Humeniuk <····································@telus.net> writes:
> Martin Raspaud wrote:
> > If lisp is so great (which I tend to believe, actually) are their
> > so many people not using it ?
>
> Because most people are girlie programmers.
>
> Wade
Best. Answer. Ever.
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
Szymon <···@bar.baz> writes:
> [ http://www.strout.net/python/pythonvslisp.html ]
How did you find this page? It used to be linked to from python.org
with a disclaimer that said "this page isn't very accurate", but the
whole page it was on has disappeared.
Anyway, old news, older page. It's been dissed on cll at least twice
already.
Cheers,
mwh
--
MGM will not get your whites whiter or your colors brighter.
It will, however, sit there and look spiffy while sucking down
a major honking wad of RAM. -- http://www.xiph.org/mgm/
Michael Hudson wrote:
> [.....] [ http://www.strout.net/python/pythonvslisp.html ] [......]
> How did you find this page?
Using google. (query: python + lisp)
> [.....] Anyway, old news, older page.
> It's been dissed on cll at least twice already.
I'm sorry. I should check this before posting the link.
> Cheers,
> mwh
Regards,
ssbm.
szymon <···@none.org> writes:
> Michael Hudson wrote:
> > [.....] [ http://www.strout.net/python/pythonvslisp.html ] [......]
>
> > How did you find this page?
>
> Using google. (query: python + lisp)
Heh, fair enough. I added a mention (and a warning) of it to:
http://www.python.org/moin/LanguageComparisons
I don't know if that really helps or not...
> > [.....] Anyway, old news, older page.
> > It's been dissed on cll at least twice already.
>
> I'm sorry. I should check this before posting the link.
Well, don't feel too bad, but your first post could have been taken as
a troll in itself...
Cheers,
mwh
--
3. Syntactic sugar causes cancer of the semicolon.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
··········@hotmail.com wrote:
> Szymon <···@bar.baz> wrote in message
> news:<··············@eva.rplacd.net>...
>
> raw scores * weight = adjusted scores
> > Python LISP Python LISP
> > Maturity 7 10 * 5 35 50
> > Syntax 10 2 * 8 80 16
> > Expressiveness 9 8 * 10 90 80
> > Functionality 10 10 * 5 50 50
> > Dev. Activity 4 5 * 8 32 40
> > Open Source 10 0 * 3 30 0
> > Available Modules 10 4 * 7 70 28
> > Extensibility 10 7 * 8 80 56
> > Documentation 8 7 * 6 48 42
> > Mac Integration 8 7 * 4 32 28
> > Current Code 1 10 * 5 9 45
> > Total 87 69 557 435
>
> I am really not fond of CommonLisp (nothing beats Scheme).
>
> However comparing CommonLisp to shit is insane.
>
> Sometimes I happen to read comp.lang.python for one reason: I haven't
> understood so far what motivates/drives people to using Python.
Tabs?
I, too, have always wondered about this. If I were to use a scripting
language to write a throw-away app, it would probably be Ruby (when
choosing between Ruby, Python and Perl). And for embedding a language
in C/C++, Lua is pretty hard to beat.
I just don't see the appeal of Python. Hard to describe, but I just
feel wrong inside when I look at the code. Especially when looking at
OO code in it.
Jeff
--
Progress in computer technology is waiting for people to stop
re-inventing the wheel.
- Dr. William Bland (comp.lang.lisp)
On Sat, 18 Sep 2004 14:59:30 GMT, Jeff <···@nospam.insightbb.com> wrote:
>
> I just don't see the appeal of Python. Hard to describe, but I just
> feel wrong inside when I look at the code. Especially when looking at
> OO code in it.
>
> Jeff
>
That, I suppose, goes to personal preference.
I believe the moral is "If you don't like it, don't use it".
I personally like Python. I find it easy to read and intuitive to program
in.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad wrote:
> On Sat, 18 Sep 2004 14:59:30 GMT, Jeff <···@nospam.insightbb.com>
> wrote:
>
> >
> > I just don't see the appeal of Python. Hard to describe, but I just
> > feel wrong inside when I look at the code. Especially when looking
> > at OO code in it.
> >
> > Jeff
> >
>
> That, I suppose, goes to personal preference.
I would agree. I think the "difficulty" I have with it is two-fold.
Like Java and C#, I don't like all the object methods being slammed
into the same code space as the definition of the class object. I
really prefer to separate interface and implementation. As you say,
it's a personal preference.
The only other "beautifying" issue I have with Python was the naming of
built in functions (ie __<name>__). I found it just extremely stressful
on the eyes.
Jeff
--
Progress in computer technology is waiting for people to stop
re-inventing the wheel.
- Dr. William Bland (comp.lang.lisp)
On Fri, 17 Sep 2004 07:24:42 -0700, chain_lube wrote:
> Sometimes I happen to read comp.lang.python for one reason: I haven't
> understood so far what motivates/drives people to using Python.
Python is extremely simple, actually you could learn earlyer version on an
afternoon and start working immeidately. And then you have those wonderful
libraries, for virtually everything. The applications I write (or wrote)
are typically very small, two or three or four hundred lines of code and I
can write them extremely fast. Often, they involved the Net and speed was
not important.
Or I had to write programs that helped me running a school (I was
headmaster of a small school at that time, and had no time of learning the
best language and looking for the libraries, which is a problem even in
C++). When I started out using Python, I had not heard of Lua nor of Ruby
and I had not liked Perl either (I always forgot the dollar sign).
Additionally, the Python community proved extremely responsive and they
helped me a lot (though as for that, with the Lisp community it would have
been the same).
So this is the reason, why I use Python and admire CL.
jb