It was nice to read the discussion "why LISP". BUT:
(1)
I completely understand that someone may prefer LISP to C++. But why should
I prefer LISP to PYTHON?
(2)
PYTHON works with Tk. But is there a similiar (FREE!) GUI tool for LISP?
Does LISP work with Tk? And I would need everythink on Windows NT!
(3)
New LISP books for beginners have not been published for years. (I shall
try to get the one written by Garaham though.) And I like those thick
O'REILLY books! They are so easily red! And so informative! On the other
hand I have to work seriously if I want to read the scholarly work by
STEELE.
Can ANYBODY answer my questions?
In article <····························@broadway.news.is-europe.net>,
"Janos Blazi" <······@netsurf.de> wrote:
> It was nice to read the discussion "why LISP". BUT:
>
> (1) I completely understand that someone may prefer LISP to C++. But
> why should I prefer LISP to PYTHON?
Performance, scalability, standarization. A native compiler is not
available for Python. The language is promoted as "glue". If all you
ever want to do is glue then that's fine. Occasionally you see a poster
who knows they've outgrown Python for their application and is taking
the time to move to Lisp (or something else). It happen's. Better to be
in Lisp from the start.
> (2) PYTHON works with Tk. But is there a similiar (FREE!) GUI tool for
> LISP? Does LISP work with Tk? And I would need everythink on Windows
> NT!
Maybe you might be interested in Corman Lisp (www.corman.net). Runs on
windows with a native compiler and you have access to the Windows API.
> (3) New LISP books for beginners have not been published for years.
> (I shall try to get the one written by Garaham though.) And I like
> those thick
> O'REILLY books! They are so easily red! And so informative! On the
> other hand I have to work seriously if I want to read the scholarly
> work by STEELE.
Oh come on now. Graham's last book was published in '96 and Slade's book
was published in late '97. Graham's book also has a second edition due
out next year. Slade's book is even 774 pages - big enough to be an
O'Reilly book. This is the first I've ever heard that someone is so
excited about how thick a book is. Folks use to disparage Lisp because
Steele's book and the language were so big. Now they aren't big enough
for some. If you want to learn Lisp, Steele's book is not the place to
start. It's mostly a language reference not a tutorial. Stick with
Graham's ANSI Common Lisp (432 pages) or even Slade's Object-Oriented
Common Lisp for learning. Lamkin's online book Successful Lisp is also a
good place to start (psg.com/~dlamkins). The price is unbeatable.
> Can ANYBODY answer my questions?
Lisp is not dying. To judge by my own company the number of active
Lispers went from a max of about 11 to 2. Now we are discussing hiring
another. To judge by those numbers there has been an 80% reduction in
Lisp development wordwide. I say worldwide because Alcoa is a global
company :-)
--
John Watton
Alcoa Inc.
Sent via Deja.com http://www.deja.com/
Before you buy.
Again!!
Will the next one try coming up with a new subject line, please? ;-)
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
This thread is so recurent that we should put something in the FAQ:
Is lisp dying: No!
Ok may be with some arguments...
Marc Battyani
Fernando D. Mato Mira <········@iname.com> wrote in message
······················@iname.com...
> Again!!
>
> Will the next one try coming up with a new subject line, please? ;-)
>
> --
> ((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
>
> Fernando D. Mato Mira
> Real-Time SW Eng & Networking
> Advanced Systems Engineering Division
> CSEM
> Jaquet-Droz 1 email: matomira AT acm DOT org
> CH-2007 Neuchatel tel: +41 (32) 720-5157
> Switzerland FAX: +41 (32) 720-5720
>
> www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
>
>
>
Erik Winkels <·······@casema.net> wrote in message
···················@sammael.downstairs.nl...
> "Marc Battyani" <·············@csi.com> writes:
>
> > This thread is so recurent that we should put something in the FAQ:
>
> FAQ?
The old FAQ :
http://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/top.html
The current source of information about lisp (more than a FAQ):
http://www.elwoodcorp.com/alu/index.htm
Marc Battyani
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> just trying to kill the title before we get another of these boring
> threads :-)
In answer to your subject line:
When the combined weight of all Java libraries and their documentation
will cause them to either a) collapse into a black-hole under their
own gravitational pull, or b) undergo spontaneous massive existence
failure, thereby ridding this world of Java, but sadly destroying it
in the process, so that all celebration parties will be cut rather
short.
Except of course on board of those space vehicles running Lisp and
commanded by autonomous robot agents, which will roam the galaxy to
warn other cultures of the sad fate the earth encountered... And so
maybe Lisp will out-survive not only all lesser programming languages,
but those Lisp doubters who raised threads with titles like "Is Lisp
dying?" as well...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
In article <··············@orion.dent.isdn.cs.tu-berlin.de>, ····@acm.org (Pierre R. Mai) wrote:
>Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
>
>> just trying to kill the title before we get another of these boring
>> threads :-)
>
>In answer to your subject line:
>
>When the combined weight of all Java libraries and their documentation
>will cause them to either a) collapse into a black-hole under their
>own gravitational pull, or b) undergo spontaneous massive existence
>failure, thereby ridding this world of Java, but sadly destroying it
>in the process, so that all celebration parties will be cut rather
>short.
>
>Except of course on board of those space vehicles running Lisp and
>commanded by autonomous robot agents, which will roam the galaxy to
>warn other cultures of the sad fate the earth encountered... And so
>maybe Lisp will out-survive not only all lesser programming languages,
>but those Lisp doubters who raised threads with titles like "Is Lisp
>dying?" as well...
>
Hmmmmm, deep space probe, programmed in Lisp, self-modifying code, a few
cosmic rays to stir things up a bit, a few million years of evolution... I
think I feel a sci-fi story coming on...
Martin
>Regs, Pierre.
>
From: Fernando D. Mato Mira
Subject: Re: When will java start dying?
Date:
Message-ID: <381753C3.D871D5C1@iname.com>
Martin wrote:
> IHmmmmm, deep space probe, programmed in Lisp, self-modifying code, a few
> cosmic rays to stir things up a bit, a few million years of evolution... I
> think I feel a sci-fi story coming on...
Producer: "What about my script?"
Screenwriter: "Done. I just changed that planet for cosmic rays"
··@capita.nildram.co.uk (Martin ) writes:
> Hmmmmm, deep space probe, programmed in Lisp, self-modifying code, a few
> cosmic rays to stir things up a bit, a few million years of evolution... I
> think I feel a sci-fi story coming on...
Yeah, you get the Ferengi. Their spaceships (the "Marauders") look a
bit like fat parenthesis.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Fernando D. Mato Mira
Subject: Re: When will java start dying?
Date:
Message-ID: <38183E5C.F85DFD1D@iname.com>
Marco Antoniotti wrote:
> ··@capita.nildram.co.uk (Martin ) writes:
>
> > Hmmmmm, deep space probe, programmed in Lisp, self-modifying code, a few
> > cosmic rays to stir things up a bit, a few million years of evolution... I
> > think I feel a sci-fi story coming on...
>
> Yeah, you get the Ferengi. Their spaceships (the "Marauders") look a
> bit like fat parenthesis.
What?? We're Ferengi? Ugh. Well, at least we get all the hot women.. [and the
cash ;-> ]
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
>>>>> "FDMM" == Fernando D Mato Mira <········@iname.com> writes:
FDMM> What?? We're Ferengi? Ugh. Well, at least we get all the hot
FDMM> women.. [and the cash ;-> ]
I hate to admit it, but hacking Lisp seems to have the effect of
scaring away the ladies, regardless of their attractiveness. :)
--
"My mind is like a steel trap - rusty and illegal in 37 states." -- Carrie Fish
From: Fernando D. Mato Mira
Subject: Re: When will java start dying?
Date:
Message-ID: <3819D363.2FFC239C@iname.com>
Matthew Economou wrote:
> >>>>> "FDMM" == Fernando D Mato Mira <········@iname.com> writes:
>
> FDMM> What?? We're Ferengi? Ugh. Well, at least we get all the hot
> FDMM> women.. [and the cash ;-> ]
>
> I hate to admit it, but hacking Lisp seems to have the effect of
> scaring away the ladies, regardless of their attractiveness. :)
Actually, I found CS ladies to intuitively `get' Lisp immediately.
This might be telling something deep about the `macho C coder' psychology..
Or is it a cash issue? :->
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
>>>>> "FDMM" == Fernando D Mato Mira <········@iname.com> writes:
FDMM> Actually, I found CS ladies to intuitively `get' Lisp
FDMM> immediately. This might be telling something deep about the
FDMM> `macho C coder' psychology..
Heh. I think it has a lot more to say about my pale complexion,
sleep-deprived growl, and forgetfulness of personal hygiene. ;)
FDMM> Or is it a cash issue? :->
Nope. I'm a conslutant. Cash isn't too much of a problem.
--
"I try to take life one day at a time, but lately several days have attacked me
at once." -- Carrie Fish
From: Fernando D. Mato Mira
Subject: Re: When will java start dying?
Date:
Message-ID: <381EF38F.342A70BD@iname.com>
Matthew Economou wrote:
> >>>>> "FDMM" == Fernando D Mato Mira <········@iname.com> writes:
>
> Heh. I think it has a lot more to say about my pale complexion,
> sleep-deprived growl, and forgetfulness of personal hygiene. ;)
>
> FDMM> Or is it a cash issue? :->
>
> Nope. I'm a conslutant. Cash isn't too much of a problem.
^^^^
Oops. Freudian slip... I hope it's not (your)blood-stained `Worse Is Better' cash
;->
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
no, lisp is not dying.
>>>> In message <····························@broadway.news.is-europe.net>
>>>> On the subject of "Is LISP dying?"
>>>> Sent on Tue, 26 Oct 1999 14:32:52 +0200
>>>> Honorable "Janos Blazi" <······@netsurf.de> writes:
>>
>> (1) I completely understand that someone may prefer LISP to C++. But
>> why should I prefer LISP to PYTHON?
the only thing I know about python is that it is defined by its unique
implementation (like perl). enough said.
see http://www.podval.org/~sds/tool.html
>> (2) PYTHON works with Tk. But is there a similiar (FREE!) GUI tool
>> for LISP? Does LISP work with Tk?
there is indeed cl-gtk (see http://www.uni-karlsruhe.de/~unk6/).
I would recommend using CLUE instead (the closure WWW brouser
http://www.uni-karlsruhe.de/~unk6/closure is based on CLUE)
--
Sam Steingold (http://www.podval.org/~sds/)
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Just because you're paranoid doesn't mean they AREN'T after you.
I don't really want to continue this thread but I can't let this
go.
Sam Steingold <···@ksp.com> wrote:
>the only thing I know about python is that it is defined by its unique
>implementation (like perl). enough said.
That is not true. There is a Java implementation of Python
(www.jpython.org). Please do a little research before you make
statements like that.
People are working another versions of Python as well. One is
called Viper, implemented in OCaml, and is showing promise (if we
can believe its creator). Another is Lunacy (www.nightmare.com).
Lunacy is very Scheme like right now but it is supposed to
eventually have a Python syntax. Originally it compiled to x86
machine code.
> >> (2) PYTHON works with Tk. But is there a similiar (FREE!) GUI tool
> >> for LISP? Does LISP work with Tk?
>
>there is indeed cl-gtk (see http://www.uni-karlsruhe.de/~unk6/).
>I would recommend using CLUE instead (the closure WWW brouser
>http://www.uni-karlsruhe.de/~unk6/closure is based on CLUE)
Neither one of those options let me develop an application on
Unix and deliver it for Windows (as Python and Tk do). AFAIK,
the only way of doing that is to use CLIM. I can't afford that,
especially when I am just testing the Common Lisp waters, so to
speak.
I really wish there was something like Tk for Lisp. Please don't
tell me about GCL and Tk. We just had a thread about how
outdated GCL is. I thought about using the FFI of CMUCL or ACL
to call Tk. Unfortunately I don't have time or the skill to do
such a thing.
I am curious as to why there is not more interest in a
cross-platfrom GUI toolkit for Common Lisp. It seems like a
reasonable thing to want.
Neil
--
"The percentage of users running Windows NT Workstation 4.0 whose PCs stopped
working more than once a month was less than half that of Windows 95 users."
-- microsoft.com/ntworkstation/overview/Reliability/Highest.asp
········@enme.ucalgary.ca (Neil Schemenauer) writes:
> I really wish there was something like Tk for Lisp. Please don't
> tell me about GCL and Tk. We just had a thread about how
> outdated GCL is. I thought about using the FFI of CMUCL or ACL
> to call Tk. Unfortunately I don't have time or the skill to do
> such a thing.
Check out
http://www.arch.usyd.edu.au/~thorsten/lisp/lisp.html
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> writes:
> ...
> Check out
> http://www.arch.usyd.edu.au/~thorsten/lisp/lisp.html
I tried, but didn't get any response. Is the URL correct or does the
server have access restrictions?
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
In article <··········@flint.sentex.net>, ··@inferno.nirvananet (Hartmann Schaffer) wrote:
> In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> writes:
> > ...
> > Check out
> > http://www.arch.usyd.edu.au/~thorsten/lisp/lisp.html
>
> I tried, but didn't get any response. Is the URL correct or does the
> server have access restrictions?
Works for me.
--
Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
Seems to be alright, I could access the site.
Janos B.
Rainer Joswig <·············@ision.de> schrieb in im Newsbeitrag:
······························@194.163.195.67...
> In article <··········@flint.sentex.net>, ··@inferno.nirvananet (Hartmann
Schaffer) wrote:
>
> > In article <·············@beta.franz.com>,
> > Duane Rettig <·····@franz.com> writes:
> > > ...
> > > Check out
> > > http://www.arch.usyd.edu.au/~thorsten/lisp/lisp.html
> >
> > I tried, but didn't get any response. Is the URL correct or does the
> > server have access restrictions?
>
> Works for me.
>
> --
> Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1,
> 21079 Hamburg, Germany, Tel: +49 40 77175 226
> Email: ·············@ision.de , WWW: http://www.ision.de/
Duane Rettig wrote:
>
> ········@enme.ucalgary.ca (Neil Schemenauer) writes:
>
> > I really wish there was something like Tk for Lisp. Please don't
> > tell me about GCL and Tk. We just had a thread about how
> > outdated GCL is. I thought about using the FFI of CMUCL or ACL
> > to call Tk. Unfortunately I don't have time or the skill to do
> > such a thing.
>
> Check out
> http://www.arch.usyd.edu.au/~thorsten/lisp/lisp.html
>
Thanks for this reference. I've seen this mentioned in passing but have
never found the home page. Has anyone used this? Does it work?
········@enme.ucalgary.ca (Neil Schemenauer) writes:
> Neither one of those options let me develop an application on
> Unix and deliver it for Windows (as Python and Tk do). AFAIK,
> the only way of doing that is to use CLIM. I can't afford that,
> especially when I am just testing the Common Lisp waters, so to
> speak.
Harlequin has the same Lisp GUI Toolkit (CAPI) in both it's Windows
and Linux versions (and it's other Unix 4.3 versions as well, I'd
imagine). It also has cost-free versions for personal use/evaluation
purposes of it's Windows and Linux (still Beta) environments available
for download from it's website. They have some limitations (there is
a 4h time-limit per session, and some heap limits, and it doesn't
include some tools of the professional edition), but for testing the
waters they should suffice. You can develop on Linux and "deliver" on
Windows without problems in this way.
And should you decide to purchase the professional editions (which are
quite inexpensive considering what you get), you can deliver
royalty-free applications (using CAPI or CLIM) to your hearts desire.
> I really wish there was something like Tk for Lisp. Please don't
> tell me about GCL and Tk. We just had a thread about how
> outdated GCL is. I thought about using the FFI of CMUCL or ACL
> to call Tk. Unfortunately I don't have time or the skill to do
> such a thing.
IIRC someone has produced a version of the GCL-TK interface that works
with CMUCL (but CMUCL isn't available on Windows either, so you've
gained nothing w.r.t. cross-platform portability). But if you simply
want a little GUI Toolkit for CMU CL, you can either use CMUCL's CLM
interface to Motif/Lesstif, or SLIK, or any of the more complex
toolkits like Garnet, CLUE/CLIO, etc.
And (not only since the advent of the Web), it's often useful to
separate out the GUI-part and communicate via sockets to the
work-horse backend. In this way you gain flexibility in two areas:
1) You can now use the GUI du jour at very short notice. Want an
HTML/CGI Interface? Or a java one? Or VB or Delphi? Or an
ncurses-based interface for terminals? No problem...
2) By separating the presentation part from the computation part, you
can move it to the client's computer which has snazzy graphics,
while keeping the computation engine on the work-horse server it
needs. Or you can let the user work with the application (and it's
precious data) even while at the other end of the world, were he
can only get access to a web-terminal...
> I am curious as to why there is not more interest in a
> cross-platfrom GUI toolkit for Common Lisp. It seems like a
> reasonable thing to want.
There is interest, and most commercial vendors offer one or two of
these beasts. It's just that there aren't enough people with time to
spend to write one for free... Most of them have other more pressing
problems, it seems.
This doesn't mean that CL couldn't use a nice, small, simple and clean
open-source cross-platform GUI toolkit...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
········@enme.ucalgary.ca (Neil Schemenauer) writes:
> Sam Steingold <···@ksp.com> wrote:
> >the only thing I know about python is that it is defined by its unique
> >implementation (like perl). enough said.
>
> That is not true. There is a Java implementation of Python
> (www.jpython.org). Please do a little research before you make
> statements like that.
Yeah, but being defined by two implementations is hardly better than
being defined by one. There should be a definition that is
independent from any implementation of it.
- Marius
Oh my goddess, yet another "imminent death of Lisp predicted, film at
eleven" thread. Next thing you know, somebody will proclaim the next
installment of "Learn FUBOL in 23 Days" as the ultimate guide to
programming, so we should all throw out SICP (or whatever).
>>>>> "NS" == Neil Schemenauer <········@enme.ucalgary.ca> writes:
NS> I really wish there was something like Tk for Lisp. Please
NS> don't tell me about GCL and Tk. We just had a thread about
NS> how outdated GCL is.
Woah, there. I never said GCL was worthless just because it doesn't
comply with the ANSI spec. You can still do a lot of useful things
with GCL---the intro to AI course at Rose-Hulman uses GCL on the UNIX
boxes, with Graham's _ANSI Common Lisp_ as the language reference, and
I never ran into a it's-not-ANSI-enough problem, even after writing a
few thousand lines of code. The ONLY time where its non-conformance
became an issue was when I started playing around with some of the
more esoteric things mentioned in the HyperSpec, like READTABLE-CASE.
My only big problem with GCL is porting it to the Alpha. Both CMU CL
and Clisp already run on the Alpha, and I never got around to digging
into GCL far enough to make a port. I probably will now that I'm
working on getting Slackware running on the Alpha (Pat Volkerding's
been including GCL in the D series since way back when).
Hell, SIOD doesn't come anywhere close to RxRS, and LOTS of people use
it for all sort of stuff. Albeit weird, godless, EVIL stuff, right
Chris? ;)
What exactly are you wanting to do that involves Lisp, TK, and NT? If
you just want to play around and explore (what I'm doing with ACL,
Clisp, CMU CL, and GCL), download ZIPslack onto your machine (only 38
megs zipped), install X, and go. It's not like getting Linux running
along side NT is difficult or anything.
Hmmm, then again... :)
--
"You are trapped in a maze of screens and ssh sessions all alike."
"It is dark, and you are likely to log off the wrong account." -- Nep.
I'm kind of a dabbler, but I've spent a lot of time trying the
different lisps and monitoring this group. So here goes
········@enme.ucalgary.ca (Neil Schemenauer) writes:
> I don't really want to continue this thread but I can't let this
> go.
>
> > >> (2) PYTHON works with Tk. But is there a similiar (FREE!) GUI tool
> > >> for LISP? Does LISP work with Tk?
All versions of lisp work with Tk. Albeit, they may have to use the
actual language. This comes from investigating some of the famed
(?infamous) Erik Naggum's messages. In one of them, he mentioned
hiring a programmer to do the windows gui thing. In another, he
lamented about the failure of some to learn to program separately the
gui and lisp. Finally, I reviewed a book called "Mixed Programming."
Even though the book focused on Visual Basic and C++, the issues were
similar to programming problems such as Lisp, Tk, and yes, Emacs.
Basicly through the files, pipes, stdin, command-line interfaces of any
backend (i.e. lisp), you can include any gui. Additionally, you can
write small C wrappers that call the C orientated guis and widgets.
Now I develop a lisp (or even a shell) program first that makes it
decisions based on information received in a file. I then choose a gui
(doesn't matter which, has even been netscape and roxen) that
generates the file.
> >there is indeed cl-gtk (see http://www.uni-karlsruhe.de/~unk6/).
> >I would recommend using CLUE instead (the closure WWW brouser
> >http://www.uni-karlsruhe.de/~unk6/closure is based on CLUE)
>
> Neither one of those options let me develop an application on
> Unix and deliver it for Windows (as Python and Tk do). AFAIK,
> the only way of doing that is to use CLIM. I can't afford that,
> especially when I am just testing the Common Lisp waters, so to
> speak.
>
That was my problem also. It was also the reason why I looked into
mixed programming. By the way, there are two programs that have
builtin gui -- "NewLisp" and "DrScheme". Both are scheme and
scheme-like. "NewLisp" only has the gui in its windows version. I tend
to like tk a little better.
> I really wish there was something like Tk for Lisp. Please don't
> tell me about GCL and Tk. We just had a thread about how
> outdated GCL is. I thought about using the FFI of CMUCL or ACL
> to call Tk. Unfortunately I don't have time or the skill to do
> such a thing.
I like GCL. For the life of me, I can't figure out what's outdated
about it or even "slow" as some writers have suggested. I personally
know that Bill is "slow" to respond to questions.
But I have a suggestion. Why don't you just use two lisps? The Tk
portion of GCl plus any other lisp that you feel does the job. This is
what most people do with Tcl/Tk anyway.
>
> I am curious as to why there is not more interest in a
> cross-platfrom GUI toolkit for Common Lisp. It seems like a
> reasonable thing to want.
>
Lisp provides ample opportunity to use any of the GUI platforms out
there. Even Visual Basic can be paired with Lisp. I suppose, lispers
don't want to reinvent the wheel when there's so many free
opportunities (with just a little a little coding).
i.b.
On 27 Oct 1999 09:04:13 -0500, IBMackey <····@stic.net> wrote:
>Now I develop a lisp (or even a shell) program first that makes it
>decisions based on information received in a file. I then choose a gui
>(doesn't matter which, has even been netscape and roxen) that
>generates the file.
Could you lease elaborate on this? O:-) How are you using Netscape as
a GUI, and what is Roxen? O:-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
·······@must.die (Fernando) writes:
> On 27 Oct 1999 09:04:13 -0500, IBMackey <····@stic.net> wrote:
>
> >Now I develop a lisp (or even a shell) program first that makes it
> >decisions based on information received in a file. I then choose a gui
> >(doesn't matter which, has even been netscape and roxen) that
> >generates the file.
>
> Could you lease elaborate on this? O:-) How are you using Netscape as
> a GUI, and what is Roxen? O:-)
>
Sorry, roxen's a server. I should have said cgi-programming with a
html as the gui interface language and a server to pass the information.
Theory's still the same. Use whatever's simplest to use (and your
platform) for gui programming. Pass responses thru the os to your
lisp backend.
i.b.
IBMackey <····@stic.net> writes:
> I like GCL. For the life of me, I can't figure out what's outdated
> about it or even "slow" as some writers have suggested. I personally
> know that Bill is "slow" to respond to questions.
I like GCL too. I do not like that it is (have not checked 2.3
though, so what I said may be wrong) that it is kept so hard-headedly
CLtL1, when it could be made to migrate toward ANSI in a relatively
easy way.
(WITH-MAJOR-GRIPE-AHEAD
"That is the reason why in ILISP, apart from welcome bug-fixing and feature
implementing activities, there is only one time when you have to
manually hack the code (remove a 'nil' :) ) to get the package to work
with GCL. You can accuse me of RMSite :), but that's the way it
is. ILISP uses many ANSI CL features and it is just a pain to
accommodate GCL and its gratuitous backwardness, at least as far as
ILISP is concerned.")
This goes for the (little :( ) code I write today in CL. A lot of it would
not work out of the box in GCL, while it works (almost) seamlessly in
all the other major implementations.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <·············@ksp.com>, Sam Steingold wrote:
> the only thing I know about python is that it is defined by its unique
> implementation (like perl). enough said.
The last time I looked python had at least two implementations, or isn't
JPython <URL:http://www.jpython.org/> considered to be an implementation?
--
Take a look in Hagbard's World: | boxquote.el - "Boxed" text quoting.
http://www.acemake.com/hagbard/ | binclock.el - emacs binary clock.
http://www.hagbard.demon.co.uk/ | uptimes.el - Record emacs uptimes.
emacs software, including.......| quickurl.el - Recall lists of URLs.
* "Janos Blazi" <······@netsurf.de>
| Can ANYBODY answer my questions?
call again tomorrow. today, we all have once again been called to the
morgue to identify whatever dead language some doofus believed was Lisp.
this is _such_ a drag, so please just refrain from asking the question in
the subject. thank you so much.
#:Erik
In article <····························@broadway.news.is-europe.net>,
"Janos Blazi" <······@netsurf.de> wrote:
> It was nice to read the discussion "why LISP". BUT:
>
> (1)
> I completely understand that someone may prefer LISP to C++. But why
should
> I prefer LISP to PYTHON?
As I said in a reply to the previous thread, the move from Python to
Lisp keeps going in the same direction. I have come along that path
(actually from Java more than C++, but the two are similar). Lisp is
like Python with speed, no strange scope rules, safe garbage collection,
and the freedom to program in whatever style you like (Python keeps
forcing you to do things the "right way", which means objects for
everything - and try timing a recursive function in Python).
I really like Python - it made programming fun again, for me, but all
the arguments for it are also arguments for Lisp...
Curiously, I started a thread with a similar name not that many months
ago :-)
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
>
> Curiously, I started a thread with a similar name not that many months
> ago :-)
And now you are hooked, aren't you? :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti wrote:
> And now you are hooked, aren't you? :)
I'm thinking about setting a self help group for addicts of the "Is LISP
Dying?" thread. This would involve a period of incremental withdraw,
self-help groups, individual councelling sessions, and training sessions
dealing with issues such as "interactive programming, the way forward", "Why
automatic memory allocation is a good thing" and "anybody who raises this
topic again should be required to look at deja.com and investigate the
arguments from the previous 137 times somebody asked this question"
Any takers?
:) will
Janos Blazi <······@netsurf.de> wrote:
>
> (1)
> I completely understand that someone may prefer LISP to C++. But why should
> I prefer LISP to PYTHON?
Because Lisp has macros. Neither Python nor Java has.
I'm going to tell you why macros make THE difference.
You know my CLN library. I started out writing it in C++ because C++ smelled
"modern" and "speedy". (That was before the templates became ubiquitous in
C++.) Wrote the number classes, started writing abelian groups and rings.
And then, after two years of development, I realized that the class for
"ring" must include lots of code already present in the class for "abelian
groups", with slight modifications. There is no way to write C++/Python/Java
in such a way. I hit the wall of unmaintainability. With Lisp macros it
would have worked.
> (2)
> PYTHON works with Tk. But is there a similiar (FREE!) GUI tool for LISP?
> Does LISP work with Tk? And I would need everythink on Windows NT!
On the Scheme side, you have STk by Erick Galligo. http://kaolin.unice.fr/STk/
On the Common Lisp side, you have GCL.
Both come with Tk bindings.
Bruno
"Janos Blazi" <······@netsurf.de> writes:
> [some questions snipped]
Please... we've just had this thread ad nauseam.
I'll answer with a question. Can you name me one ANSI/ISO standardized
language that has had a reasonable amount of commercial use that has
really died? Before you reply, I ought to tell you that I know some
PL/1 hackers who have recently started porting a lot of their
commercial work to the new IBM VisualAge compiler; that I know of
quite a bit of commercial APL work and that I recently have come
across some Jovial work. All of these languages can be said to be in a
worse shape than Lisp but I wouldn't call them dead. If on the other
hand you mean, is Lisp going to be the next hyped silver bullet a la
C++ or Java or <insert next flavour of the month>, I hope not.
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
"Janos Blazi" <······@netsurf.de> writes:
And here we go again into another "Is LISP dying?" thread... This
thread is repeated every couple of months/weeks on c.l.l, and is
really tiring, since it needs refutation every time, lest the next
round of newcomers get's the same misinformation again... Oh,
well...
> It was nice to read the discussion "why LISP". BUT:
>
> (1)
> I completely understand that someone may prefer LISP to C++. But why should
> I prefer LISP to PYTHON?
Among other reasons (note that it's been some time I did Python, so I
may be underestimating Python's power in these areas, although I doubt
it):
a) CL's macro system. This (together with Lisp's defined internal
representation for code, on which macros work) really is one of the
key strengths of Lisp, out of which many of it's other strong
features are derived. For example, you can implement both CLOS and
the condition system and complex loop in a ClTL1 Common Lisp, which
lacks all of these.
Add to this Lisp's syntax and it's extensible reader (that is the
parser that transforms Lisp's textual syntax into it's internal
representation prior to compilation, evaluation or any other source
transformation/analysis), and I have yet to meet a language that
provides this level of power to extend it's own syntax, semantics
and pragmatics.
This also enables the program author to write automatic optimizers
for his own (or other people's) code, in Lisp itself with a few
lines, using either normal macros, compiler-macros (part of the
current ANSI standard), or implementation-specific mechanisms:
Let foo and bar be functions that consume and produce expensive
datastructures, but which can communicate directly much more
efficiently. This design is the correct one though, for reasons of
modularization (e.g. foo and bar are both part of a published
interface, with many other clients). In other functions the only
thing you can do is to provide a specialized foobar function, which
is the more efficient concatenation of foo and bar. This is ugly
for two reasons:
1. It pushes the responsibility for recognizing and fixing the
ineffiency onto the shoulders of the library user, and
2. If we have more than one producer/consumer each in this
relationship, the redundant optimized functions grow
exponentially, making it difficult for both user and
implementer to keep things straight.
But using compiler macros, we can hide (and sometimes even
eliminate) much of this complexity underneath the normal syntax:
(defun foo (data)
;; Use expensive data
(blablabla data))
(defun bar (input)
;; Based on input produce expensive data and return it
expensive-data)
(defun foo-fast (iterator)
;; This is the fast variant, which uses an iteration closure
;; for access....
(loop for next = (funcall iterator) while next collect (blabla next)))
(defun bar-make-iterator (input)
;; This returns a closure for iteration...
(let ((current 0))
(lambda () (when (array-in-bounds-p input (incf current))
(process (aref input current))))))
(define-compiler-macro foo (data &whole whole)
(if (and (consp data) (eq (car data) 'bar))
;; We use the optimized interface via bar-make-iterator
`(foo-fast (bar-make-iterator ,(cadr data)))
;; We can't optimize
whole))
Now (foo (bar baz)) will get optimized automagically. This is a
contrived example, but I've done similar things in a number of
systems.
b) CL's object system CLOS (and the Metaobject Protocol a.k.a. MOP).
This is quite a bit more flexible and powerful than Python's (which
isn't bad as far as conventional OOP systems go), offering
multiple-dispatch, elaborate (and user-definable) method
combinations and generally many hooks to tune/extend it. Add to
that the Metaobject Protocol, and you can move much earth with
little effort. For example a simplistic in-core "persistent"
"OODB" that integrates seemlessly into CLOS takes < 300 lines of
code using the MOP, and gives you indexable classes with a nice
syntax (this is based on an idea by Kelly Murray):
(defclass employee (indexed-object)
((name :initarg :name :accessor employee-name :key equal :unique t
:lookup employee-by-name)
(salary :initarg :salary :accessor employee-salary)
(group :initarg :group :accessor employee-group :key eq
:lookup employees-by-group))
(:metaclass indexed-class))
(defclass special-employee (employee)
((group :key eq :lookup special-employees-by-group)
(task :initarg :task :accessor employee-task :key eq
:lookup employees-by-task))
(:metaclass indexed-class))
(defclass manager (employee)
((people :initarg :people :accessor employee-people
:key eq :unique t :set t :lookup manager-by-employee))
(:metaclass indexed-class))
This gives you a number of lookup functions that let you locate
instances by their keys. Given the following instances:
(make-instance 'employee :name "Mai, Pierre"
:salary 70000 :group 'lisp)
(make-instance 'employee :name "Hacker, Random J."
:salary 90000 :group 'lisp)
(make-instance 'special-employee :name "Doe, Jane" :salary 100000
:group 'lisp :task 'pr)
(make-instance 'manager :name "Flintstone, Fred"
:salary 120000 :group 'lisp
:people (employees-by-group 'lisp))
you could use the following calls to query this "database":
(employee-by-name "Doe, Jane") or
(retrieve-by-key 'employee 'name "Doe, Jane")
(employees-by-group 'lisp)
(employees-by-task 'pr)
(manager-by-employee (employee-by-name "Mai, Pierre"))
Many other exciting things can be done this way, that would be hard
or difficult in other languages. Try to get a copy of [1] to get a
glimpse of the things that are possible in CLOS/MOP. Also take a
look at [2] for an introduction and nice overview of what even pure
CLOS has to offer.
c) Common Lisp's Condition System. Again this offers far more power
and abstraction than any other condition system I know. Also read
Kent M. Pitman's paper[3] on exception handling in CL.
d) Speed. With CL you get implementations that compile to native code
and achieve speeds that are quite near to C/C++ or Fortran on many
occassions (sometimes even surpassing them), and only off by a small
factor at other times. Yet CL is even better at "scripting" than
most scripting languages, so you can write your whole system in one
language, instead of taking the "C/C++ plus scripting language plus
much glue code" approach that other languages necessitate.
e) CL is standardized, and implementors are very eager to conform to
this standard (unlike many other standards that are out there).
You can get a number of different high-quality implementations,
some of them free, some of them commercially licenced, with great
support. The amount of effort needed in porting between
implementations is usually quite small. The ANSI CL standard (of
which an equivalent version is available online for free) is very
well written and useful on a daily basis.
f) Common Lisp is based on over 40 years of experience with Lisp as a
language. Many mistakes that other languages have yet to make have
been made _and learned from_ in the Lisp community many ages ago.
The current ANSI CL standard gives you a very stable and useful
language to work from.
g) Many, many more things. Head over to Deja News, and re-read other
postings on this topic in this newsgroup from the past years, and
you will find many more examples of what CL has to offer, and
you'll also see that CL is far from dead...
> (2)
> PYTHON works with Tk. But is there a similiar (FREE!) GUI tool for LISP?
> Does LISP work with Tk? And I would need everythink on Windows NT!
I'm not uptodate with CL implementations for Windows, so I will leave
this to others who are better informed...
> (3)
> New LISP books for beginners have not been published for years. (I shall
> try to get the one written by Garaham though.) And I like those thick
> O'REILLY books! They are so easily red! And so informative! On the other
> hand I have to work seriously if I want to read the scholarly work by
> STEELE.
>
> Can ANYBODY answer my questions?
Slade for example has published his "Object-Oriented Common Lisp" in
1997, so there have been beginner's books published in recent times.
There's also Graham's books (again his ANSI Common Lisp has been
published only a few years ago), and Norvig's Paradigms of Artificial
Intelligence Programming. Head over to amazon.com which had a feature
on Lisp books some time ago, and have quite a list of books available.
AFAIK O'Reilly has no books on Common Lisp, although they have books
on Emacs Lisp and probably Guile (a Scheme)...
Regs, Pierre.
Footnotes:
[1] Gregor Kiczales, Jim des Rivi`eres and Daniel G. Bobrow:
"The Art of the Metaobject Protocol", MIT Press, 1991
[2] Sonya E. Keene: "Object Oriented Programming in Common Lisp -
A Programmer's Guide to CLOS", Addison-Wesley, 1988
[3] Exceptional Situations in Lisp
http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Your excellent argument convinces me, at least, that LISP is really an extremely
cool language. My only gripe is the insistence on the List-like syntax for
EVERYTHING. We've known infix notation since we started math. I think that's why
all these other "statement-oriented" languages are so much more popular. You can
just type what you're thinking and the compiler will figure the rest out.
And don't give me that same old BS about ambiguity. I agree that C++ has a /few/
too many levels of precendence... But I don't care, I just use parens, and I've
never had code that's not done what I've wanted it to do. (Maybe I'm just used
to the C operator precendence that it's just a part of my psyche.... scary
thought...)
But my point is, why not have a special operator that lets you specify an
operation in infix notation? Or better yet, have a way to make "statements" look
more like statements and have fewer parens lying around. 90% of the time, those
parens are useless. All I need are a few block delimiters like in C. (I don't
like python's use of whitespace as an indicator of the start and end of a block)
Maybe I'm just tired and somewhat delerious, but I know from the scheme I've
done for class that my fuctions have WAY more parens than I'd like, and the
bothersome part is that it's the right way...
Maybe this could be implemented with a sort of pre-processor that converts all
the code to list-style before "really" using it, somewhat like what happens in
Java (use the debug option on the compiler to see what I mean, if they still
have that in the newer versions -- 1.0.2 had it)
--
-> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <-
-> "I never could get the hang of Thursdays." -Douglas N. Adams <-
-> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <-
-> -=-=-=-=-=- E-mail: ·················@usa.net -=-=-=-=-=- <-
Version 9.105.999.1111111111111.23.042
(c)1996-1998, All rights reserved.
Disclaimer available upon request.
Rahul Jain <·····@owlnet.rice.edu> writes:
> Your excellent argument convinces me, at least, that LISP is really
> an extremely cool language. My only gripe is the insistence on the
> List-like syntax for EVERYTHING. We've known infix notation since we
> started math. I think that's why all these other
> "statement-oriented" languages are so much more popular. You can
> just type what you're thinking and the compiler will figure the rest
> out. And don't give me that same old BS about ambiguity. I agree
I could give you some reasons why Lisp's "everything is a s-exp"
approach is really the better approach, but you wouldn't believe me
anyhow. So I'd rather suggest another approach:
a) Make sure you get an editor/environment that really supports Lisp
programming. This means it offers automatic indenting and paren
blinking/highlighting, paren balancing commands and editing
commands that work on s-exps. Add to that the ability to run a
lisp listener in this environment and communicate with it, giving
access to it's built-in information on argument-lists, doc-strings,
etc. and automatic lookup of symbols in the HyperSpec (if you are
using CL and not Scheme). In other words this probably means an
Emacs (GNU Emacs or XEmacs) with ILISP or ELI and/or one of the
IDEs that come with your CL implementation.
Get to know this environment and start using it to your full
advantage. Let it take care of your parens and your indenting.
Don't ever count or balance parens by hand, don't even look at
them! Ignore them! I mean it!
Instead let the indentation of the code (which your editor will do
in the canonical way, see the code I or other regulars of c.l.l
post here) guide your understanding of code-nesting. This takes a
bit of practice and getting used to, but it will be worth it.
Keep your functions short, don't nest to deeply.
b) Try to do real work with this setup, writing programs, macros,
etc. Try not to think about whether sexps are cool or not. Just
do your work, trying to do it the Lisp way. Go with the flow.
After a while, one of two things will happen:
a) You decide that you really, really, really can't stand sexps, and
don't see the point of this exercise, and therefore decide to try
out Dylan, which has switched to an algol-like syntax (and has lost
some of the power of Lisp on the way, IMHO, but is still a nice,
powerful language), or
b) You will start to see why in 40 years of Lisp, we have stuck with
s-exps as the surface syntax. You will see that s-exps aren't
nearly as unworkable as you once thought, and that they offer a
number of very tangible advantages in shaping your thought
processes, increasing orthogonality and easing macro development
(and many other data-structure manipulation operations).
Indeed, the same approach will help you learn a number of other things
that CL does differently. At the start you will feel alienated, and
think "Why this way? Why not the usual way? There must be someway to
do it the usual way!". But remind yourself that Lisp is 40 years old,
and that all your first complaints about a feature will have been
voiced by generations of new-comers, and have been "ignored". So
either Lisp-folks are very stubborn, or they might have got a point.
Given that the Lisp community has had no problems changing very
fundamental things in trying to improve Lisp (like introducing lexical
scoping, or adding/removing namespaces, etc.), they may have good
reasons, which aren't easily apparent, for keeping this "silly"
feature. And often after just a little while, you will find out about
the reasons for a particular feature, and see why all the new-comer
complaints and arguments didn't quite cut it. And you will feel
enlightened... ;)
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre Mai writes:
>...And you will feel enlightened... ;)
Q: How can you tell when you've reached Lisp Enlightenment?
A: The parentheses disappear.
--
Fred Gilham ······@csl.sri.com
King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead
From: Christopher R. Barry
Subject: Re: The usual silly subject elided
Date:
Message-ID: <87u2nco8mj.fsf@2xtreme.net>
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> Pierre Mai writes:
> >...And you will feel enlightened... ;)
>
> Q: How can you tell when you've reached Lisp Enlightenment?
>
> A: The parentheses disappear.
And one that has attained this state of mind may be said to have
attained the holy Lambda-Nature.
Christopher
From: Fernando D. Mato Mira
Subject: Re: The usual silly subject elided
Date:
Message-ID: <38177E09.5497364F@iname.com>
Fred Gilham wrote:
> Pierre Mai writes:
> >...And you will feel enlightened... ;)
>
> Q: How can you tell when you've reached Lisp Enlightenment?
^^^^^^^^^^^^^^^^^
It's *REALLY BEAUTIFUL*?
It's *REALLY SLOW*?
[CLIM + E, BRRRR!!]
;-)
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
"Pierre R. Mai" wrote:
> a) Make sure you get an editor/environment that really supports Lisp
> programming. This means it offers automatic indenting and paren
> blinking/highlighting, paren balancing commands and editing
> commands that work on s-exps. Add to that the ability to run a
> lisp listener in this environment and communicate with it, giving
> access to it's built-in information on argument-lists, doc-strings,
> etc. and automatic lookup of symbols in the HyperSpec (if you are
> using CL and not Scheme). In other words this probably means an
> Emacs (GNU Emacs or XEmacs) with ILISP or ELI and/or one of the
> IDEs that come with your CL implementation.
If I have the time to set up a sane set of keybindings I will... until then
it's nedit for me...
If anyone has a good smart indent routine for nedit, I'd be much obliged.
> b) You will start to see why in 40 years of Lisp, we have stuck with
> s-exps as the surface syntax. You will see that s-exps aren't
> nearly as unworkable as you once thought, and that they offer a
> number of very tangible advantages in shaping your thought
> processes, increasing orthogonality and easing macro development
> (and many other data-structure manipulation operations).
No argument there, that's why I wanted the /option/ to do it. :)
But that question is already answered, and much to my satisfaction. The best
part is that it can give you the s-exp form of it without much work.
Thanks a billion, guys :)
Now to remap my parens so that I don't need to hit shift to use them ;)
--
-> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <-
-> "I never could get the hang of Thursdays." -Douglas N. Adams <-
-> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <-
-> -=-=-=-=-=- E-mail: ·················@usa.net -=-=-=-=-=- <-
Version 9.105.999.1111111111111.23.042
(c)1996-1998, All rights reserved.
Disclaimer available upon request.
And one other thing...
*puts on asbestos underwear*
How about some strong typing so that stupid me can avoid silly mistakes like
putting params in the wrong order or returning a struct instead of the symbol
that names it...
*smirk*
--
-> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <-
-> "I never could get the hang of Thursdays." -Douglas N. Adams <-
-> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <-
-> -=-=-=-=-=- E-mail: ·················@usa.net -=-=-=-=-=- <-
Version 9.105.999.1111111111111.23.042
(c)1996-1998, All rights reserved.
Disclaimer available upon request.
From: Christopher R. Barry
Subject: Re: The usual silly subject elided
Date:
Message-ID: <87so2vmne7.fsf@2xtreme.net>
Rahul Jain <·····@owlnet.rice.edu> writes:
> And one other thing...
> *puts on asbestos underwear*
> How about some strong typing so that stupid me can avoid silly mistakes like
> putting params in the wrong order or returning a struct instead of the symbol
> that names it...
> *smirk*
CMU CL prints warnings or even deletes code that is no longer
reachable when you get your declared types wrong.
Christopher
Rahul Jain <·····@owlnet.rice.edu> writes:
> And one other thing...
> *puts on asbestos underwear*
> How about some strong typing so that stupid me can avoid silly mistakes like
> putting params in the wrong order or returning a struct instead of the symbol
> that names it...
> *smirk*
Strong typing *doesn't* stop you from making errors in
parameter ordering. Next...
On a more useful note: Lisp *has* facilities for checking
types of parameters, and also value ranges of individual
parameters. C/C++ has the latter in a very limited form, by way of
assert(); the Lisp "equivalent" gives you the option of modifying the
parameter(s) and continue the program.
--
Raymond Wiker, Orion Systems AS
+47 370 61150
Raymond Wiker <·······@orion.no> writes:
> Rahul Jain <·····@owlnet.rice.edu> writes:
>
> > And one other thing...
> > *puts on asbestos underwear* How about some strong typing so that
> > stupid me can avoid silly mistakes like putting params in the
> > wrong order or returning a struct instead of the symbol that names
> > it... *smirk*
>
> Strong typing *doesn't* stop you from making errors in
> parameter ordering. Next...
>
> On a more useful note: Lisp *has* facilities for checking
> types of parameters, and also value ranges of individual
> parameters. C/C++ has the latter in a very limited form, by way of
> assert(); the Lisp "equivalent" gives you the option of modifying the
> parameter(s) and continue the program.
And any sane Lisp environment can get, display and event insert the
lambda list (i.e. the list which specifies which parameters in which
order (if ordered) the function takes) to the function by the touch of
a button (or 2). For example in Emacs with ILISP:
C-c a Return the arglist of the currently looked at function.
With a numeric prefix, the arglist will be inserted. With a negative
one, the symbol will be prompted for.
Another key-binding often used for this is C-M-a.
C-c d Return the documentation of the previous symbol.
It uses 'ilisp-documentation-command'. If the symbol is at the start
of a list, it is assumed to be a function, otherwise variable
documentation is searched for. With a minus prefix, prompt for the
symbol and type. With a numeric prefix always return the current
function call documentation.
The above work for all functions, i.e. your own functions or the
functions from the guy across the country, too.
If the function you are planning to call is part of ANSI CL, you can
look it up in the HyperSpec, too. Using Erik Naggum's hyperspec.el,
I've got
C-c h View the documentation on SYMBOL-NAME from the Common Lisp HyperSpec.
If SYMBOL-NAME has more than one definition, all of them are displayed with
your favorite browser in sequence. The browser should have a "back"
function to view the separate definitions.
The Common Lisp HyperSpec is the full ANSI Standard Common Lisp, provided
by Kent Pitman and the Harlequin Group. By default, the Harlequin WWW site
is visited to retrieve the information. The Harlequin Group allows you to
transfer the entire Common Lisp HyperSpec to your own site under certain
conditions. Visit http://www.harlequin.com/books/HyperSpec/ for more
information. If you copy the HyperSpec to another location, customize the
variable `common-lisp-hyperspec-root' to point to that location.
Add to this that you should use keyword arguments for seldomly used
parameters of functions (when defining them), like most functions in
ANSI CL itself do:
(remove #\E "A simple demonstration sentence with a lot of E's."
:test #'char-equal
:start 23)
So IMHO the danger of mixing up parameters can be reduced to a very
small epsilon, indeed. In fact, I can't remember when I last mixed up
parameters in a function call...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Rahul Jain <·····@owlnet.rice.edu> writes:
> And one other thing...
> *puts on asbestos underwear*
> How about some strong typing so that stupid me can avoid silly mistakes like
> putting params in the wrong order or returning a struct instead of the symbol
> that names it...
> *smirk*
How about getting CMUCL, DECLAREing your parameters and compiling the
code?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Rahul Jain <·····@owlnet.rice.edu> writes:
> "Pierre R. Mai" wrote:
>
> > a) Make sure you get an editor/environment that really supports Lisp
> > programming. This means it offers automatic indenting and paren
> > blinking/highlighting, paren balancing commands and editing
> > commands that work on s-exps. Add to that the ability to run a
> > lisp listener in this environment and communicate with it, giving
> > access to it's built-in information on argument-lists, doc-strings,
> > etc. and automatic lookup of symbols in the HyperSpec (if you are
> > using CL and not Scheme). In other words this probably means an
> > Emacs (GNU Emacs or XEmacs) with ILISP or ELI and/or one of the
> > IDEs that come with your CL implementation.
>
> If I have the time to set up a sane set of keybindings I
> will... until then it's nedit for me... If anyone has a good smart
> indent routine for nedit, I'd be much obliged.
[ Note: I assume, from a comment you made later in your post,
that parentheses were your main keybinding problem. ]
You think *you* have a problem, having to press shift to get
parentheses? What about people who use non-english keyboards, who have
to press AltGr to get braces and brackets? (Actually, this is a good
reason for switching to Lisp :-)
Also, in C/C++ (for example) the number of parentheses plus
braces in a typical program is *much* higher than the number of
parentheses in the equivalent Lisp program. (Proof left...)
> > b) You will start to see why in 40 years of Lisp, we have stuck with
> > s-exps as the surface syntax. You will see that s-exps aren't
> > nearly as unworkable as you once thought, and that they offer a
> > number of very tangible advantages in shaping your thought
> > processes, increasing orthogonality and easing macro development
> > (and many other data-structure manipulation operations).
>
> No argument there, that's why I wanted the /option/ to do it. :)
> But that question is already answered, and much to my satisfaction. The best
> part is that it can give you the s-exp form of it without much work.
> Thanks a billion, guys :)
> Now to remap my parens so that I don't need to hit shift to use them ;)
You're not going to get the most out of Lisp if you start by
camouflaging it as something else. I suggest that you take a look at
Graham's books (particularly "On Lisp"); if that doesn't make you see
the light about the s-exp form, nothing will.
--
Raymond Wiker, Orion Systems AS
+47 370 61150
Raymond Wiker wrote:
> [ Note: I assume, from a comment you made later in your post,
> that parentheses were your main keybinding problem. ]
That's the problem if I use nedit. In emacs, I'd want to change the bindings to
be a bit more like I want them (that's just a matter of me sitting down and
actually figuring out how to really use emacs and then configuring it)
> Also, in C/C++ (for example) the number of parentheses plus
> braces in a typical program is *much* higher than the number of
> parentheses in the equivalent Lisp program. (Proof left...)
I agree with that comment, but the parens are much more visible when there's 8 of
them in a row ;)
> You're not going to get the most out of Lisp if you start by
> camouflaging it as something else. I suggest that you take a look at
> Graham's books (particularly "On Lisp"); if that doesn't make you see
> the light about the s-exp form, nothing will.
I know the utility of the s-exp form, but it's a real pain to have to convert a
mathematical equation to it. Maybe it's just because I'm only used to in- and
postfix notation. Eventually I'll master prefix notation and be the master of all
notation (except for any really strange ones that I've never head of....) :P
--
-> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <-
-> "I never could get the hang of Thursdays." -Douglas N. Adams <-
-> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <-
-> -=-=-=-=-=- E-mail: ·················@usa.net -=-=-=-=-=- <-
Version 9.105.999.1111111111111.23.042
(c)1996-1998, All rights reserved.
Disclaimer available upon request.
Rahul Jain <·····@owlnet.rice.edu> writes:
> Raymond Wiker wrote:
>
> > [ Note: I assume, from a comment you made later in your post,
> > that parentheses were your main keybinding problem. ]
>
> That's the problem if I use nedit. In emacs, I'd want to change the bindings to
> be a bit more like I want them (that's just a matter of me sitting down and
> actually figuring out how to really use emacs and then configuring it)
No need to involve emacs at all - at least assuming that
you're using XWindows (Note: untested, but "should" work on english
(UK *and* US) keyboards):
xmodmap -e 'keysym bracketleft = parenleft bracketleft braceleft' \
-e 'keysym bracketright = parenright bracketright braceright'
> > Also, in C/C++ (for example) the number of parentheses plus
> > braces in a typical program is *much* higher than the number of
> > parentheses in the equivalent Lisp program. (Proof left...)
>
> I agree with that comment, but the parens are much more visible when there's 8 of
> them in a row ;)
Ah, but *those* are the _invisible_ kind of parens :-)
> > You're not going to get the most out of Lisp if you start by
> > camouflaging it as something else. I suggest that you take a look at
> > Graham's books (particularly "On Lisp"); if that doesn't make you see
> > the light about the s-exp form, nothing will.
>
> I know the utility of the s-exp form, but it's a real pain to have
> to convert a mathematical equation to it. Maybe it's just because
> I'm only used to in- and postfix notation. Eventually I'll master
> prefix notation and be the master of all notation (except for any
> really strange ones that I've never head of....) :P
That's a valid concern. On the other hand, if you have a
strict representation of equations (for example, based on s-exps, but
limited to unary and binary operations, plus n-ary functions), you can
easily use this form to create a variety of more readable forms (e.g,
TeX or PostScript output...)
Also, equations in s-exp form can *easily* be transformed -
examples are simplification, normalisation, symbolic derivation etc.
--
Raymond Wiker, Orion Systems AS
+47 370 61150
From: Christopher R. Barry
Subject: Re: The usual silly subject elided
Date:
Message-ID: <87aep2acjw.fsf@2xtreme.net>
Raymond Wiker <·······@orion.no> writes:
> xmodmap -e 'keysym bracketleft = parenleft bracketleft braceleft' \
> -e 'keysym bracketright = parenright bracketright braceright'
Your xinitrc file will typically have (or run a file that has)
something like this:
sysmodmap=/etc/X11/Xmodmap
usrmodmap=$HOME/.Xmodmap
Other popular names include .xmodmaprc. In this xmodmap dotfile put:
keysym 9 = 9 bracketleft
keysym 0 = 0 bracketright
keysym bracketleft = parenleft braceleft
keysym bracketright = parenright braceright
Christopher
* Rahul Jain
| I know the utility of the s-exp form, but it's a real pain to have to
| convert a mathematical equation to it. Maybe it's just because I'm only
| used to in- and postfix notation. Eventually I'll master prefix notation
| and be the master of all notation (except for any really strange ones
| that I've never head of....) :P
(defun trivial-infix-reader (input-stream char)
(declare (ignore char))
(let ((list (read-delimited-list #\] input-stream t)))
(cond ((null (cddr list)) list) ;trivial: 1- and 2-lists
((null (cdddr list)) ;swap first and second of 3-lists
(list (second list) (first list) (third list)))
(t (list* (second list) (first list)
(loop with operator = (second list)
for pair on (cdr list) by #'cddr
unless (cdr pair) do
(error "infix expression is not well-formed")
unless (eq operator (first pair)) do
(error "infix operator is not properly redundant")
collect (second pair)))))))
when this definition is available, you may evaluate
(set-macro-character #\[ 'trivial-infix-reader)
(set-syntax-from-char #\] #\))
and type things like [2 + 3], [sqrt pi], [10 log 2], [x < y < z], and
have them all come out right.
for a more powerful infix reader that does precedence and such, there is
some stuff available in the Common Lisp archives, but I suggest you stick
to the above simplicity so you don't get dragged into maintaining a mini-
language which nobody will benefit from, including yourself some ways
down the road.
enjoy!
#:Erik
>>>>> "EN" == Erik Naggum <····@naggum.no> writes:
EN> (defun trivial-infix-reader (input-stream char) ...)
Over in the other thread, someone was trying to make a case for Lisp
"power" or what-have-you. I think the relative ease (Erik's solution
is 17 lines of code) with which one can make radical changes to the
*language itself*, all on the fly no less, sets Lisp apart from e.g. C
or Java or Python. There is *no* way to do something equivalent
(e.g. switch to a prefix notation) in C without some serious hacking
on the C compiler's parser. C's macro system is only a glorified
search-and-replace, whereas Lisp's macro system (including reader
macros) allows the user to truly transform the language.
(I point this out because it's probably possible to build
continuations in C (with setjmp/longjmp). Not easy, like the LAMBDA
and CALL/CC operators, but possible.)
--
"I try to take life one day at a time, but lately several days have attacked me
at once." -- Carrie Fish
In article <·················@owlnet.rice.edu>,
Rahul Jain <·····@owlnet.rice.edu> wrote:
>"Pierre R. Mai" wrote:
>> a) Make sure you get an editor/environment that really supports Lisp
>> programming. This means it offers automatic indenting and paren
>> blinking/highlighting, paren balancing commands and editing
>> commands that work on s-exps. Add to that the ability to run a
>> lisp listener in this environment and communicate with it, giving
>> access to it's built-in information on argument-lists, doc-strings,
>> etc. and automatic lookup of symbols in the HyperSpec (if you are
>> using CL and not Scheme). In other words this probably means an
>> Emacs (GNU Emacs or XEmacs) with ILISP or ELI and/or one of the
>> IDEs that come with your CL implementation.
>
>If I have the time to set up a sane set of keybindings I will... until then
>it's nedit for me...
>If anyone has a good smart indent routine for nedit, I'd be much obliged.
I haven't heard of nedit, but if you are an emacsphobe
who doesn't mind vi, there is a Lisp indenter very
close to your stomping grounds:
http://www.cs.rice.edu/~dorai/scmindent/scmindent.html.
--d
From: Fernando D. Mato Mira
Subject: Re: The usual silly subject elided
Date:
Message-ID: <381751CB.AB459DA4@iname.com>
Rahul Jain wrote:
> Your excellent argument convinces me, at least, that LISP is really an extremely
> cool language. My only gripe is the insistence on the List-like syntax for
> EVERYTHING. We've known infix notation since we started math. I think that's why
"What's all this new arabic symbol stuff? We've known Roman numerals since we
started math"
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Rahul Jain <·····@owlnet.rice.edu> writes:
> But my point is, why not have a special operator that lets you specify an
> operation in infix notation?
There is a reader-macro package that does this, if you really care. It
can be found at the following gigantic URL:
http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/lang/lisp/code/syntax/infix/0.html
The documentation of what it supports and how it looks is included below.
> Or better yet, have a way to make "statements" look
> more like statements and have fewer parens lying around. 90% of the time, those
> parens are useless. All I need are a few block delimiters like in C.
Except that Lisp doesn't really have statements per se. All items are
expressions. That is why there is only one "IF" in CL, but both "if"
and "?" in C.
In any case, with a bit of experience, the parens don't really get in
the way, since almost all large collections of them are relegated to the
end of the line, and program structure is indicated by indentation.
(Any decent Lisp editor will do automatic indentation for you)
=============
Infix Documentation:
;;; ********************************
;;; Documentation ******************
;;; ********************************
;;;
;;; Syntax:
;;;
;;; Begin the reader macro with #I( and end it with ). For example,
;;; #I( x^^2 + y^^2 )
;;; is equivalent to the Lisp form
;;; (+ (expt x 2) (expt y 2))
;;; but much easier to read according to some folks.
;;;
;;; If you want to see the expansion, type a quote before the #I form
;;; at the Lisp prompt:
;;; > '#I(if x<y<=z then f(x)=x^^2+y^^2 else f(x)=x^^2-y^^2)
;;; (IF (AND (< X Y) (<= Y Z))
;;; (SETF (F X) (+ (EXPT X 2) (EXPT Y 2)))
;;; (SETF (F X) (- (EXPT X 2) (EXPT Y 2))))
;;;
;;;
;;; Operators:
;;;
;;; NOTE: == is equality, = is assignment (C-style).
;;;
;;; \ quoting character: x\-y --> x-y
;;; ! lisp escape !(foo bar) --> (foo bar)
;;; ; comment
;;; x = y assignment (setf x y)
;;; x += y increment (incf x y)
;;; x -= y decrement (decf x y)
;;; x *= y multiply and store (setf x (* x y))
;;; x /= y divide and store (setf x (/ x y))
;;; x|y bitwise logical inclusive or (logior x y)
;;; x^y bitwise logical exclusive or (logxor x y)
;;; x&y bitwise logical and (logand x y)
;;; x<<y left shift (ash x y)
;;; x>>y right shift (ash x (- y))
;;; ~x ones complement (unary) (lognot x)
;;; x and y conjunction (and x y)
;;; x && y conjunction (and x y)
;;; x or y disjunction (or x y)
;;; x || y disjunction (or x y)
;;; not x negation (not x)
;;; x^^y exponentiation (expt x y)
;;; x,y sequence (progn x y)
;;; (x,y) sequence (progn x y)
;;; also parenthesis (x+y)/z --> (/ (+ x y) z)
;;; f(x,y) functions (f x y)
;;; a[i,j] array reference (aref a i j)
;;; x+y x*y arithmetic (+ x y) (* x y)
;;; x-y x/y arithmetic (- x y) (/ x y)
;;; -y value negation (- y)
;;; x % y remainder (mod x y)
;;; x<y x>y inequalities (< x y) (> x y)
;;; x <= y x >= y inequalities (<= x y) (>= x y)
;;; x == y equality (= x y)
;;; x != y equality (not (= x y))
;;; if p then q conditional (when p q)
;;; if p then q else r conditional (if p q r)
;;;
;;; Precedence:
;;;
;;; The following precedence conventions are obeyed by the infix operators:
;;; [ ( !
;;; ^^
;;; ~
;;; * / %
;;; + -
;;; << >>
;;; < == > <= != >=
;;; &
;;; ^
;;; |
;;; not
;;; and
;;; or
;;; = += -= *= /=
;;; ,
;;; if
;;; then else
;;; ] )
;;;
;;; Note that logical negation has lower precedence than numeric comparison
;;; so that "not a<b" becomes (not (< a b)), which is different from the
;;; C precedence conventions. You can change the precedence conventions by
;;; modifying the value of the variable *operator-ordering*.
;;;
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
Rahul Jain <·····@owlnet.rice.edu> writes:
> Your excellent argument convinces me, at least, that LISP is really
> an extremely cool language. My only gripe is the insistence on the
> List-like syntax for EVERYTHING. We've known infix notation since we
> started math. I think that's why all these other
> "statement-oriented" languages are so much more popular. You can
> just type what you're thinking and the compiler will figure the rest
> out. And don't give me that same old BS about ambiguity. I agree
> that C++ has a /few/ too many levels of precendence... But I don't
> care, I just use parens, and I've never had code that's not done
> what I've wanted it to do. (Maybe I'm just used to the C operator
> precendence that it's just a part of my psyche.... scary thought...)
> But my point is, why not have a special operator that lets you
> specify an operation in infix notation?
And you think it ahs not been done yet? :) Of course in Common Lisp?
Check out the AI repository at CMU for the Infix Package by Mark
Kantrowitz.
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/air.html
> Or better yet, have a way to make "statements" look more like
> statements and have fewer parens lying around. 90% of the time,
> those parens are useless. All I need are a few block delimiters
> like in C.
The reality is that you don't need them. All you need is a simple and
regular syntax, like '(operator arg1 arg2 ... argN)' :)
> (I don't like python's use of
> whitespace as an indicator of the start and end of a block) Maybe
> I'm just tired and somewhat delerious, but I know from the scheme
> I've done for class that my fuctions have WAY more parens than I'd
> like, and the bothersome part is that it's the right way...
Are you sure your functions are not too long? :)
> Maybe
> this could be implemented with a sort of pre-processor that converts
> all the code to list-style before "really" using it, somewhat like
> what happens in Java (use the debug option on the compiler to see
> what I mean, if they still have that in the newer versions -- 1.0.2
> had it)
Why not just let the editor do the work for you? You *are* using
Emacs, *aren't* you? :)
Cheers
--
Marco Antoniotti =========================================== PARADES,
Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17,
fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
Rahul Jain <·····@owlnet.rice.edu> wrote in message
······················@owlnet.rice.edu...
...
> But my point is, why not have a special operator that lets you specify an
> operation in infix notation? Or better yet, have a way to make
"statements" look
...
You can use "Infix notation for Common Lisp" from Mark Kantrowitz.
NDT 5 > #I(1+2*3-5)
2
NDT 8 > '#I(a+2*b[i]-f(x[j]))
(+ a (* 2 (aref b i)) (- (f (aref x j))))
It can be found at
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/lang/lisp/0.ht
ml
Marc Battyani
Rahul Jain <·····@owlnet.rice.edu> writes:
> Your excellent argument convinces me, at least, that LISP is really
> an extremely cool language. My only gripe is the insistence on the
> List-like syntax for EVERYTHING. We've known infix notation since we
> started math. I think that's why all these other
> "statement-oriented" languages are so much more popular. You can
> just type what you're thinking and the compiler will figure the rest
> out.
Maybe I am spoiled by the reverse notation of my HP-calculator (I
actually think that way), but I would presume that when one thinks of
f.i. and additon, one thinks of the _operation_ first, not one of the
numbers. So then it seems quite logical to write the operation
first. This also seems quite practical when adding several numbers.
Asbj.S.
--
Asbj�rn S�b� (Asbjoern Saeboe), E-mail: ······@tele.ntnu.no
NTNU - Norwegian University of Science and Technology, Acoustics group
<URL: http://www.tele.ntnu.no/users/saeboe/>
Public PGP-key: <URL: http://www.tele.ntnu.no/users/saeboe/pgp/pgp.html>
If your only gripe is that you don't personally like Lisp syntax -- fair
enough -- don't use it.
Alternatives:
+ Others have pointed out infix packages available for your favorite
Common Lisp.
+ I've heard it said that the first thing many creative people do on
learning Lisp is to create an Algol-syntax Lisp. (I never did; I guess I
don't cut it.) McCarthy himself intended to do the same when he created
Lisp: the S-expression syntax was only meant to be for "internal use".
(See http://www.elwood.com/alu/table/syntax.htm). The latest and most
advanced of these efforts that is widely available (from multiple
sources) is Dylan.
(http://www.elwood.com/alu/table/related-langues.htm#dylan) use it if
you prefer. More are being created all the time. (Charlotte?)
+ Use a structure editor so you never even see the syntax directly. If
you can't find one, write one.
Understanding:
The reason that infix syntax for Lisp has never really caught on in the
Lisp community is that they syntax is so useful:
1. It's easy to learn and explain.
2. It's easy to write programs that work off this.
Stig points out in a related thread that Lispers are a community of
tool-builders. Writing macros, reader macros, and even code walkers is
something that we do, not just occasionally, but ALL THE TIME. Yes, it
is true that such tools could be written to process the internal
S-expressions rather than a surface infix syntax. But if you are writing
such tools all the time, then you are working with the S-expression
syntax all the time. You quickly find it inconvenient to "force
yourself" to write code in infix that processes code in prefix.
Rahul Jain wrote:
>
> Your excellent argument convinces me, at least, that LISP is really an extremely
> cool language. My only gripe is the insistence on the List-like syntax for
> EVERYTHING. We've known infix notation since we started math. I think that's why
> all these other "statement-oriented" languages are so much more popular. You can
> just type what you're thinking and the compiler will figure the rest out.
> And don't give me that same old BS about ambiguity. I agree that C++ has a /few/
> too many levels of precendence... But I don't care, I just use parens, and I've
> never had code that's not done what I've wanted it to do. (Maybe I'm just used
> to the C operator precendence that it's just a part of my psyche.... scary
> thought...)
> But my point is, why not have a special operator that lets you specify an
> operation in infix notation? Or better yet, have a way to make "statements" look
> more like statements and have fewer parens lying around. 90% of the time, those
> parens are useless. All I need are a few block delimiters like in C. (I don't
> like python's use of whitespace as an indicator of the start and end of a block)
> Maybe I'm just tired and somewhat delerious, but I know from the scheme I've
> done for class that my fuctions have WAY more parens than I'd like, and the
> bothersome part is that it's the right way...
> Maybe this could be implemented with a sort of pre-processor that converts all
> the code to list-style before "really" using it, somewhat like what happens in
> Java (use the debug option on the compiler to see what I mean, if they still
> have that in the newer versions -- 1.0.2 had it)
>
> --
> -> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <-
> -> "I never could get the hang of Thursdays." -Douglas N. Adams <-
> -> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <-
> -> -=-=-=-=-=- E-mail: ·················@usa.net -=-=-=-=-=- <-
> Version 9.105.999.1111111111111.23.042
> (c)1996-1998, All rights reserved.
> Disclaimer available upon request.
From: Gareth McCaughan
Subject: Common Lisp and Python -- was Re: Is LISP dying?
Date:
Message-ID: <86ln8piss5.fsf@g.local>
[I've changed the subject line to something less inflammatory.]
Janos Blazi wrote:
> (1)
> I completely understand that someone may prefer LISP to C++. But why should
> I prefer LISP to PYTHON?
1. A good Lisp implementation will give you execution speeds
impossible in Python.
2. There are some things Lisp does much better than Python.
For instance, closures (= functions complete with their
lexical environments) are useful more often than you might
think. Python can sort of do them (via the default-argument
hack), but that's not terribly satisfactory.
3. Many things that both languages do are more general in
Lisp. For instance, Lisp and Python both have associative
arrays (or, if you prefer, hash tables); but Lisp gives
you more choice over things like when two keys should be
considered equal. (You can always roll your own class
with different behaviour in Python, but you lose badly
on efficiency.)
4. Lisp offers much more syntactic flexibility. Its powerful
macro system lets you redesign the language to suit the
problems you're trying to solve.
By the way, I'm not trying to knock Python; I use it often
and with pleasure.
> (2)
> PYTHON works with Tk. But is there a similiar (FREE!) GUI tool for LISP?
> Does LISP work with Tk? And I would need everythink on Windows NT!
I don't know of any Tk-on-Lisp thing. There are some Tk-on-Scheme
things, but I think they're Unix-only; and, anyway, with Scheme
you'd lose many advantages of Common Lisp.
> (3)
> New LISP books for beginners have not been published for years. (I shall
> try to get the one written by Garaham though.) And I like those thick
> O'REILLY books! They are so easily red! And so informative! On the other
> hand I have to work seriously if I want to read the scholarly work by
> STEELE.
You could try David Lamkins's "Successful Lisp", available for
free on the WWW. A book called something like "Object-oriented
Common Lisp" was published some time in the last few years.
Peter Norvig's "Paradigms of Artificial Intelligence Programming"
is recent-ish, though not strictly for beginners (though it is
a superb book).
It's true that there are no books on Common Lisp published
by O'Reilly.
--
Gareth McCaughan ················@pobox.com
sig under construction
From: Russell Senior
Subject: Re: Common Lisp and Python -- was Re: Is LISP dying?
Date:
Message-ID: <86bt9l2snx.fsf@coulee.tdb.com>
>>>>> "Gareth" == Gareth McCaughan <················@pobox.com> writes:
Gareth> I don't know of any Tk-on-Lisp thing. There are some
Gareth> Tk-on-Scheme things, but I think they're Unix-only; and,
Gareth> anyway, with Scheme you'd lose many advantages of Common Lisp.
For what it is worth, STk (an implementation of `Tk-on-Scheme' with a
TinyCLOS-like object system) reportedly works on w32 these days. In
my experience, though not CL, STk tries to be useful and pleasant to
use. For me, it succeeded.
--
Russell Senior ``The two chiefs turned to each other.
·······@teleport.com Bellison uncorked a flood of horrible
profanity, which, translated meant, `This is
extremely unusual.' ''
On 27 Oct 1999 00:52:42 +0100, Gareth McCaughan
<················@pobox.com> wrote:
>By the way, I'm not trying to knock Python; I use it often
>and with pleasure.
Why? What advantage does Python give you over
Lisp?
From: Matt Wette
Subject: Re: Common Lisp and Python -- was Re: Is LISP dying?
Date:
Message-ID: <7k904ouy2d.fsf@jpl.nasa.gov>
·@nospam.net writes:
> On 27 Oct 1999 00:52:42 +0100, Gareth McCaughan
> <················@pobox.com> wrote:
>
> >By the way, I'm not trying to knock Python; I use it often
> >and with pleasure.
>
> Why? What advantage does Python give you over
> Lisp?
OK, I'll bite. Goto http://www.python.org, or http://www.perl.com for
that matter. Check out the list of modules built into python, or
perl. Want something else? Go to http://www.python.com and look at
the extras. Or go to http://www.perl.com/CPAN and look at the list of
modules.
If I want to write beautiful code, then I might use LISP. If I want
to get my hooks into the OS to do system programming or want to bang
through text files to quickly get info out, or if I need to interface
to some oddball internet protocol and I want a high probably of
finding something that someone else has already done, then right now I
check out the python and/or perl sites. I don't see this sort of
thing on www.cons.org. Where does one go to get lisp code to do this
sort of stuff.
Put another way, putting together a program to interface with NIS and
HTTP and HTML and LDAP and be able to grind the output of HTTP and
LDAP queries through regular expressions and generate whatever in PERL
or probably Python is doable in a day, mostly because most of the code
is already done and available easily. Is this the picture with LISP?
Matt
--
Matthew.R.Wette at jpl.nasa.gov -- I speak for myself, not for JPL.
From: Gareth McCaughan
Subject: Re: Common Lisp and Python -- was Re: Is LISP dying?
Date:
Message-ID: <86n1t4h2wx.fsf@g.local>
Someone with no name said:
[I wrote:]
>> By the way, I'm not trying to knock Python; I use it often
>> and with pleasure.
>
> Why? What advantage does Python give you over
> Lisp?
A different set of libraries, handier for some uses.
A usable and very portable GUI.
A more congenial syntax when what I want to do is
rather unsophisticated. (For more sophisticated
purposes, Lisp's syntax is often more congenial.)
--
Gareth McCaughan ················@pobox.com
sig under construction
Gareth McCaughan <················@pobox.com> wrote:
> > Why? What advantage does Python give you over
> > Lisp?
>
> A different set of libraries, handier for some uses.
> A usable and very portable GUI.
Could we just take the python GUI and use it from say clisp, acl, lcl,
cmucl via a ffi? Would this work on Unix and Windows? Would this have
advantages over using Tk?
Yours,
Clemens
--
Clemens Heitzinger
http://ag.or.at:8000/~clemens
From: Gareth McCaughan
Subject: Re: Common Lisp and Python -- was Re: Is LISP dying?
Date:
Message-ID: <86so2vurec.fsf@g.local>
Clemens Heitzinger wrote:
[someone asked me:]
>>> Why? What advantage does Python give you over
>>> Lisp?
>>
>> A different set of libraries, handier for some uses.
>> A usable and very portable GUI.
>
> Could we just take the python GUI and use it from say clisp, acl, lcl,
> cmucl via a ffi? Would this work on Unix and Windows? Would this have
> advantages over using Tk?
The GUI *is* Tk. Python has a tolerable set of wrappers
for it.
--
Gareth McCaughan ················@pobox.com
sig under construction
Gareth McCaughan <················@pobox.com> wrote:
> The GUI *is* Tk. Python has a tolerable set of wrappers
> for it.
Well, the most popular of the cross platform Python GUIs is Tk.
There are several others, most of which are actively maintained
and evolving. There are also several platform specific ones.
Dan Pierson, Control Technology Corporation
···@control.com
From: Gareth McCaughan
Subject: Re: Common Lisp and Python -- was Re: Is LISP dying?
Date:
Message-ID: <86d7tvt3a8.fsf@g.local>
Dan L. Pierson wrote:
>> The GUI *is* Tk. Python has a tolerable set of wrappers
>> for it.
>
> Well, the most popular of the cross platform Python GUIs is Tk.
> There are several others, most of which are actively maintained
> and evolving.
Quite true. The GUI to which I was referring, however, was Tk. :-)
(Does any of the others support all three of Unix, Windows and Mac?)
--
Gareth McCaughan ················@pobox.com
sig under construction
Gareth McCaughan <················@pobox.com> wrote:
> Dan L. Pierson wrote:
>
> >> The GUI *is* Tk. Python has a tolerable set of wrappers
> >> for it.
> >
> > Well, the most popular of the cross platform Python GUIs is Tk.
> > There are several others, most of which are actively maintained
> > and evolving.
>
> Quite true. The GUI to which I was referring, however, was Tk. :-)
> (Does any of the others support all three of Unix, Windows and Mac?)
Hmmm, don't know for sure because I don't do any Mac development.
- wxWindows claims that a Mac version is underway
- OpenAmulet claims Mac support but doesn't appear to have
downloadable binaries for it.
Dan Pierson, Control Technology Corporation
···@control.com
In article <····························@4ax.com>,
Dan L. Pierson <···@control.com> wrote:
>Gareth McCaughan <················@pobox.com> wrote:
>
>> Dan L. Pierson wrote:
>>
>> (Does any of the others support all three of Unix, Windows and Mac?)
>
>Hmmm, don't know for sure because I don't do any Mac development.
>- wxWindows claims that a Mac version is underway
I've downloaded a Mac version, and have done absolutely nothing with
it since. Once I actually read the documentation, I supposed I can
write some MCL bindings. (Maybe I'll see if it actually works well
on the Mac first.)
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
On 27 Oct 1999 00:52:42 +0100, Gareth McCaughan <················@pobox.com>
wrote:
> [I've changed the subject line to something less inflammatory.]
>
> Janos Blazi wrote:
>
> > (1)
> > I completely understand that someone may prefer LISP to C++. But why should
> > I prefer LISP to PYTHON?
A real GC? I believe the original C-based version of Python just has
reference-counting.
__Jason
Jason Trenouth <·····@harlequin.com> wrote in message
·································@4ax.com...
> On 27 Oct 1999 00:52:42 +0100, Gareth McCaughan
<················@pobox.com>
> wrote:
>
> > [I've changed the subject line to something less inflammatory.]
> >
> > Janos Blazi wrote:
> >
> > > (1)
> > > I completely understand that someone may prefer LISP to C++. But why
should
> > > I prefer LISP to PYTHON?
>
> A real GC? I believe the original C-based version of Python just has
> reference-counting.
>
> __Jason
Interesting point, but working programmers don't choose their tools for the
language features they can tick off. In practice, reliability and acceptable
performance are what count. Python's reference counting doesn't seem to
cause many problems to its users.
I think the advantages of Lisp over Python are obvious - execution speed,
abstraction. But although
I prefer Lisp to Python as a language, but the libraries I can access while
using Lisp are comparatively impoverished. There are advantages to using a
language exactly because it's widely used. The "widely used" thing happened
to Python because it's free to acquire, and easy to learn. Compare that to
Lisp, which scares a lot of programmers - probably wrongly - and which
doesn't have seem to have an acceptable free implementation that's available
for all the major platforms. The lack of a Windows CMUCL make's me wince.
Of course, this is understandable. Decent Lisp compilers are obviously
*much* harder to engineer than Python or C++ tools. Dynamic typing plus
speed - ouch!
Jonathan
Hi again Jonathan,
> > A real GC? I believe the original C-based version of Python just has
> > reference-counting.
>
> Interesting point, but working programmers don't choose their tools for the
> language features they can tick off. In practice, reliability and acceptable
> performance are what count. Python's reference counting doesn't seem to
> cause many problems to its users.
Posters in the Python newsgroup report having to workaround this limitation by
avoiding cycles or snipping them before dropping all external references. In
practice Python programs are probably shorter scripts and either don't build
such complicated data structures or don't care so much about leakage as they
do their job quickly and then terminate.
> I think the advantages of Lisp over Python are obvious - execution speed,
> abstraction.
I would hope that's not all, but perhaps "abstraction" covers a multitude of
virtues.
> But although
> I prefer Lisp to Python as a language, but the libraries I can access while
> using Lisp are comparatively impoverished.
Well most Lisps can invoke existing C APIs which is how many OS services are
exported. Moreover some Lisps can load them dynamically without having to
pre-link them into the Lisp executable. E.g. you can sit in a Lisp listener
pick a library, load it, describe the function you want to call, and call it.
Perhaps what you meant was that there are fewer standardized Common Lisp
wrappers that hide the grotty details of existing C libraries?
__Jason
* Jonathan wrote:
> Jason Trenouth <·····@harlequin.com> wrote in message
>> A real GC? I believe the original C-based version of Python just has
>> reference-counting.
> Interesting point, but working programmers don't choose their tools for the
> language features they can tick off. In practice, reliability and acceptable
> performance are what count. Python's reference counting doesn't seem to
> cause many problems to its users.
I guess that means that python gets used only for short-runtime rather
simple programs or something (or perhaps that its programmers are
really good at doing steam memory management). My experience is that
reference-counted systems are really a pain for long-lived programs
which build complex data structures, since they tend to leak in
obscure ways. Interlisp-D for instance, which was reference-counted
used to generate circular structure for closures which could really be
bad, as you had no real way of breaking it.
I think perl may be refcounted too incidentally.
I have nothing against languages for short-lived simple programs -- I
use perl a lot for exactly this, and I might use python if I had the
time to learn it.
--tim
From: Christopher R. Barry
Subject: Re: Common Lisp and Python -- was Re: Is LISP dying?
Date:
Message-ID: <87g0yora7l.fsf@2xtreme.net>
Tim Bradshaw <···@tfeb.org> writes:
> I think perl may be refcounted too incidentally.
I know it used to be. I think in the newest versions they may have
moved to something more sophisticated. Similarly, many Java
implementations started out with just copying collectors, but now it
seems many (like IBM's) have or are getting generational collectors.
Christopher
From: Malcy
Subject: Re: Common Lisp and Python -- was Re: Is LISP dying?
Date:
Message-ID: <m24sf45x9u.fsf@oyster.home>
Tim Bradshaw <···@tfeb.org> writes:
>
> I guess that means that python gets used only for short-runtime rather
> simple programs or something (or perhaps that its programmers are
> really good at doing steam memory management). My experience is that
> reference-counted systems are really a pain for long-lived programs
> which build complex data structures, since they tend to leak in
> obscure ways. Interlisp-D for instance, which was reference-counted
> used to generate circular structure for closures which could really be
> bad, as you had no real way of breaking it.
http://www.zope.org
--
···········@chat.ru
From: Paolo Amoroso
Subject: Tk with Lisp - Recent Lisp books [was: Re: Is LISP dying?]
Date:
Message-ID: <3816c3db.48218@news.mclink.it>
On Tue, 26 Oct 1999 14:32:52 +0200, "Janos Blazi" <······@netsurf.de>
wrote:
> PYTHON works with Tk. But is there a similiar (FREE!) GUI tool for LISP?
> Does LISP work with Tk? And I would need everythink on Windows NT!
It depends on your definition of "Lisp". If by Lisp you mean a family of
programming languages including Scheme http://www.schemers.org besides
Common Lisp, then yes, Lisp does work with Tk and there is--at least--one
free Scheme implementation supporting Tk that also runs under Win32:
STk
http://kaolin.unice.fr/STk
> New LISP books for beginners have not been published for years. (I shall
Again, this depends on your definition of "publishing". If it includes
electronic publishing, then there are--at least--a couple of recent online
Lisp (see the extended definition above) books for beginners published no
earlier than last year:
Successful Lisp
http://psg.com/~dlamkins/left/sl/sl.html
[this is about Common Lisp]
Teach Yourself Scheme in Fixnum Days
http://www.cs.rice.edu/~dorai/t-y-scheme/t-y-scheme.html
[this is about Scheme]
Have (de)fun,
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Marco Antoniotti
Subject: Re: Tk with Lisp - Recent Lisp books [was: Re: Is LISP dying?]
Date:
Message-ID: <lwg0yx13m7.fsf@parades.rm.cnr.it>
·······@mclink.it (Paolo Amoroso) writes:
> On Tue, 26 Oct 1999 14:32:52 +0200, "Janos Blazi" <······@netsurf.de>
> wrote:
>
> > PYTHON works with Tk. But is there a similiar (FREE!) GUI tool for LISP?
> > Does LISP work with Tk? And I would need everythink on Windows NT!
BTW. CMUCL ocmes with Motif/Lesstif. Does Python have a Motif binding?
> Teach Yourself Scheme in Fixnum Days
> http://www.cs.rice.edu/~dorai/t-y-scheme/t-y-scheme.html
> [this is about Scheme]
To be followed by a
"Re-implement all missing CL features in Scheme in Bignum days." :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Fernando D. Mato Mira
Subject: Re: Tk with Lisp - Recent Lisp books [was: Re: Is LISP dying?]
Date:
Message-ID: <38174E5D.60C37019@iname.com>
Marco Antoniotti wrote:
> BTW. CMUCL ocmes with Motif/Lesstif. Does Python have a Motif binding?
Is this a trick question? ;-)
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Marco Antoniotti
Subject: Re: Tk with Lisp - Recent Lisp books [was: Re: Is LISP dying?]
Date:
Message-ID: <lwwvs73oaa.fsf@parades.rm.cnr.it>
"Fernando D. Mato Mira" <········@iname.com> writes:
> Marco Antoniotti wrote:
>
> > BTW. CMUCL ocmes with Motif/Lesstif. Does Python have a Motif binding?
>
> Is this a trick question? ;-)
Aren't you supposed to answer a question with another one? :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa