Why learn Lisp
Mr. Neutron
I don't want to start a religious war. I am on my travels through
learning computing, and wanting to explore the universe of Computer
Science. This is just my opinions of Lisp so far.
I have learned the very basics of Lisp. It is in my opinion a weird
language. It uses strange named operators (car...) and lots of (() ).
I am left witha very superficial look at what appears to be a retro
language, a throwback to a time when computers were the size of
buildings. It is hard to think in Lisp or what I can use it for.
I can not imagine why I should keep trying to program in this language when I have
better, easier modern languages with a cleaner syntax and operators with
names that make sense to me. SO far everything I understand I can do in
Lisp I can just as well do in another language I know. I know not the
ways of Lisp or what it is about that has enabled it survive this long.
So far the only thing I have learned to do with Lisp is make a stack
using a very strange syntax. I could easily code this same problem in
Python or C or Java much faster and easier to read (to me).
What oh what makes Lisp or Scheme useful? Are they just hacker languages
that a hacker must know to be accepted by the hacker community? Or is
there really something about Lisp (or Scheme) that makes them stand apart
from the easier (IMO) to understand languages like Python, Java or C/C++?
How has Lisp survived through the years? I have come across many many
computer languages in my studies, and the majority of them died before
they were even conceived. Yet Lisp, Fortran, and C survived. I know C and
Fortran. They are not too hard to understand. But Lisp is IMO very hard to
understand (first, everything is literally backwards in it...).
I would like to learn how to program in Lisp, so I can appreciate
something of the history of Computer Science. I am also interested
in understanding Lisp, because I have read that it teaches you to think
about problems recursively. But I am still struggling to figure out how
to write an interesting program in the language.
If you can explain to a neophyte Computer Scientist why learning to code
in Lisp will enlighten me and will be worth the pain of getting
acquainted with it, I'd like to know!
Also are there any free e-books on programming in Lisp or Scheme?
Are there any places I can get Lisp (or Scheme) code so I can look at to
learn how to think in these languages?
I am still interested in the way of Lisp and Scheme so I am not closed to
learning about it. But my only experience with it is a funny taste. It is
completely opposite of how I think and I can not think at all in this
language. I just stare at the clisp prompt wondering what I should do
next. I can write simple programs that process a list, but it is a toy.
There must be more to it than just making toys.
hehe.
Thanks
Wojciech Sobczuk
answered many times already.
Greetings,
Wojtek
Edi Weitz
> I can not imagine why I should keep trying to program in this
> language when I have better, easier modern languages with a cleaner
> syntax [...]
The very reason why Lisp might look silly to you on first encounter is
that it has a _very_ clean syntax as opposed to other languages like
C, Java or Perl (!!) which have things like curly braces, parentheses,
brackets, semicolons, commas and more all over the place and use it
pretty arbitrarily.
Most people here won't agree with you that other (more "modern")
languages are better than Lisp. Maybe they seem easier to learn, yes,
but it's also easier to drive a Toyota than to drive a Ferrari.
You might want to read a text that another Lisp newbie has written
some days ago. It also includes some useful links for further reading
at the end:
<http://www.cs.uni-bonn.de/~costanza/lisp/guide.html>
Edi.
Mr. Neutron
>
> Most people here won't agree with you that other (more "modern")
> languages are better than Lisp. Maybe they seem easier to learn, yes,
> but it's also easier to drive a Toyota than to drive a Ferrari.
>
Hi sorry, I am not trying to aggravate Lispers. The real problem is I
I have only 1 book on Lisp that was written over twenty years ago. You
have to understand that so far my only introduction to Lisp has been
through a book that is almost as old as I am. I am stumped imagining how
to use Lisp for anything useful (like maybe downloading files from an FTP
site, or accessing a database..). I am very anxious to see what makes
Lisp an AI language. But all I have is a dumb book that talks about
making a stack or two and moving items around on a list. You have to
understand from my perspective, I can accomplish the same thing in just
about any language i know and without any learning curve.
Now this is the kind of statement that makes me interested in Lisp! Why
is it considered a Ferrari? It looks like a VW beetle when I play with
it.
Where do I find the archives and other ****modern**** resources on
Lisp that will help me in my understanding of why Lisp is cool!
> You might want to read a text that another Lisp newbie has written some
> days ago. It also includes some useful links for further reading at the
> end:
>
> <http://www.cs.uni-bonn.de/~costanza/lisp/guide.html>
>
I am finding this introduction useful thanks.
Alexey Dejneka
> Where do I find the archives and other ****modern**** resources on
> Lisp that will help me in my understanding of why Lisp is cool!
Take a look at Document -> "Common Lisp, Typing and Mathematics".
--
Regards,
Alexey Dejneka
---
CMUCL-specific packages:
C: Python compiler
...
cr88192
> "Mr. Neutron" <nickts...@charter.net> writes:
>
>> I can not imagine why I should keep trying to program in this
>> language when I have better, easier modern languages with a cleaner
>> syntax [...]
>
> The very reason why Lisp might look silly to you on first encounter is
> that it has a _very_ clean syntax as opposed to other languages like
> C, Java or Perl (!!) which have things like curly braces, parentheses,
> brackets, semicolons, commas and more all over the place and use it
> pretty arbitrarily.
>
yes, this is one good point. even though I have been using scheme (not so
much cl) for a while now I still do not like the abundance of parenthesis
around, though the syntax pointed out in my spec has a few bad points for
many things I would still rather use it.
at present my plans also include keeping an s-expr parser around so people
could code in that if they wanted, and display will still continue to
output s-exprs (likely anyways, I have not gotten as far as defining
structured/console input/output yet though, or much of any io...).
> Most people here won't agree with you that other (more "modern")
> languages are better than Lisp. Maybe they seem easier to learn, yes,
> but it's also easier to drive a Toyota than to drive a Ferrari.
>
yep. besides lisp I consider python a possible alternative (if I need
something more popular), though I still have plenty of reasons to use the
lisps.
personally I still feel that room for improvement exists (though I can not
argue that mine is any better...). mine at present, like scheme, still
holds the ideal of keeping the core language small and consistent.
my idea is to try to develop an effective module system and try to promote
this as a major means of extending the language. unlike modules in many
other languages, the ones in mine are also conceptually capable of
extending/altering the syntax as well (though this has yet to be
specified...).
from experience it seems though that very few people are actually willing
to contribute ideas though. a problem is that language design leaves
problems in that there may be plenty of issues for which I am not aware,
and language design pushes my language knowlege limits at present...
> You might want to read a text that another Lisp newbie has written
> some days ago. It also includes some useful links for further reading
> at the end:
>
> <http://www.cs.uni-bonn.de/~costanza/lisp/guide.html>
>
> Edi.
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
Wade Humeniuk
"Mr. Neutron" <nickts...@charter.net> wrote in message
news:pan.2002.08.25.09....@charter.net...
> On Sun, 25 Aug 2002 08:18:35 -0400, Edi Weitz wrote:
> Hi sorry, I am not trying to aggravate Lispers. The real problem is I
> I have only 1 book on Lisp that was written over twenty years ago. You
> have to understand that so far my only introduction to Lisp has been
You can download a better book for free,
see http://www.paulgraham.com/onlisp.html
Also see http://www.norvig.com
When I started to learn Lisp, I started very simply, simple interactions with the Lisp
Listener, stuff like (+ 3 4), (list 1 2 3 4). I worked through my text's chapters
systematically, doing all the examples, until I understood the the simple syntax of what I
was doing. Doing it this way with no preconceived notions of what is "right" allows the
brain to catch on to what is going on. Its like learning a foreign language, it just
looks like nonsense at the beginning, but then suddenly you begin to see letters, then
words and then sentences. But you have to give yourself time to understand, it does not
happen instantly (especially when one is used to C-like-syntax languages).
Wade
Edi Weitz
> > On Sun, 25 Aug 2002 08:18:35 -0400, Edi Weitz wrote:
> > Hi sorry, I am not trying to aggravate Lispers. The real problem is I
> > I have only 1 book on Lisp that was written over twenty years ago. You
> > have to understand that so far my only introduction to Lisp has been
This quote looks as if I had written the above paragraphy. I haven't.
Edi.
Wade Humeniuk
through it in combination with the Common Lisp Hyperspec.
http://www.lispworks.com/reference/HyperSpec/Front/index.htm
See attached file. It is fairly limited in the CL functionality used but it may push you
into exploring aspects of CL. (things like multiple-value-bind, macrolet (macros),
funcall, structs, vectors, types, format,...)
Wade
Wade Humeniuk
Friedrich Dominicus
> On Sun, 25 Aug 2002 08:18:35 -0400, Edi Weitz wrote:
>
> >
> > Most people here won't agree with you that other (more "modern")
> > languages are better than Lisp. Maybe they seem easier to learn, yes,
> > but it's also easier to drive a Toyota than to drive a Ferrari.
> >
> Hi sorry, I am not trying to aggravate Lispers. The real problem is I
> I have only 1 book on Lisp that was written over twenty years ago.
Than get a more decent book.
And get the Hyperspec
http://www.lispworks.com/reference/HyperSpec/index.html
> You
> have to understand that so far my only introduction to Lisp has been
> through a book that is almost as old as I am. I am stumped imagining how
> to use Lisp for anything useful (like maybe downloading files from an FTP
> site, or accessing a database..). I am very anxious to see what makes
> Lisp an AI language.
See Paradigms or Artificial Intelligence Programming. And you got a
good ide on how Lisp programming could look
>But all I have is a dumb book that talks about
> making a stack or two and moving items around on a list. You have to
> understand from my perspective, I can accomplish the same thing in just
> about any language i know and without any learning curve.
Can you really? So please write such thing in C, without knowing any C
of course.
Friedrich
Erik Naggum
| I don't want to start a religious war.
Do /not/ feed the trolls.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Fred Gilham
> I have learned the very basics of Lisp. It is in my opinion a weird
> language. It uses strange named operators (car...) and lots of (()).
> I am left witha very superficial look at what appears to be a
> retro language, a throwback to a time when computers were the size
> of buildings. It is hard to think in Lisp or what I can use it for.
One comment about `car' and `cdr' and the like. This is one where
people disagree, but I still like them. The way I think about them is
like `x' and `y' in a coordinate system. Why do you call it `x'? How
about `horizontal'? Wouldn't that make more sense? But that misses
the point --- `x' and `y' are abstractions. So are `car' and `cdr'.
The other thing is that you can do `cadr', `caar' and so on. Some
people hate this but I think it's kind of neat.
> I can not imagine why I should keep trying to program in this
> language when I have better, easier modern languages with a cleaner
> syntax and operators with names that make sense to me. SO far
> everything I understand I can do in Lisp I can just as well do in
> another language I know. I know not the ways of Lisp or what it is
> about that has enabled it survive this long.
You didn't give examples. So I'm not sure which languages you prefer
as having cleaner syntax etc.
If you are unhappy with prefix --- that is, the way lisp does (+ 2 3)
as opposed to 2 + 3 --- then I can only say that you'll get used to
it, and you'll be happy when you find yourself doing (+ 2 3 4 5) or
(= x y z) or things like that.
Lisp uses a `regular' syntax, with parentheses as its primary
structure-creating mechanism. For this reason, it's easy to read
Lisp. You always know what's going on. Almost all the semantics is
pushed into named operators.
For example, instead of
a[4]
you say
(aref a 4)
Instead of
for(i = 0; i < 5; i++) {
...do something....
}
you say
(dotimes (i 5)
(...do something))
Note in the examples from C you see braces, brackets, semicolons and
parentheses to indicate structure of one kind or another. In Lisp you
see parentheses. (Lisp programs are `line noise free zones'!)
> So far the only thing I have learned to do with Lisp is make a stack
> using a very strange syntax. I could easily code this same problem
> in Python or C or Java much faster and easier to read (to me).
I guess you must have been writing a stack using the Common Lisp
Object System? Otherwise, in Lisp, stacks are trivial:
(defvar *my-stack* nil)
(push 3 *my-stack*)
(push 4 *my-stack*)
(push 12 *my-stack*)
(push 7 *my-stack*)
(pop *my-stack*)
(pop *my-stack*)
(etc.)
Of course, this isn't an `information-hiding' version of a stack, but
it's easy enough to do that in Lisp too using closures.
(let ((my-stack nil))
(defun my-push (e)
(push e my-stack))
(defun my-pop ()
(if my-stack
(pop my-stack)
(error "Stack empty!"))))
> What oh what makes Lisp or Scheme useful? Are they just hacker
> languages that a hacker must know to be accepted by the hacker
> community? Or is there really something about Lisp (or Scheme) that
> makes them stand apart from the easier (IMO) to understand languages
> like Python, Java or C/C++?
I like the distinction people make with regard to GUIs: easy to learn
vs. easy to use. Some people call a GUI "easy to use" when they mean
"easy to learn", or easy to get started with. Lisp really isn't THAT
hard to learn, but some people find languages like Java or C++ more
familiar (at first). But after a while you find that Lisp is easer to
use. That's because as time goes on, in C++ or Java you start getting
bogged down in language-induced complexity. Things become harder to
do because the language makes them harder to do. In Lisp, there isn't
as much language-induced complexity; things become harder because of
problem-induced complexity (that is, because the problem itself is
harder).
An example of language-induced complexity that someone posted in this
newsgroup some time ago can be found in the following paper:
http://www.oonumerics.org/tmpw00/eisenecker.html
I am not sure I understand this paper, but it seems to me that in Lisp
the problem doesn't arise at all.
For example, here's my Lisp code that does what I think they were
trying to do in the paper:
;;;;
(defclass customer ()
((first-name :initarg :first-name)
(last-name :initarg :last-name)))
(defmethod print-it ((cust customer))
(with-slots (first-name last-name) cust
(format t "~&First name: ~A~%Last name: ~A~%" first-name last-name)))
(defclass phone-contact (customer)
((phone-number :initarg :phone-number)))
(defmethod print-it ((phone phone-contact))
(with-slots (phone-number) phone
(call-next-method)
(format t "~&Phone number: ~A~%" phone-number)))
(defclass email-contact (customer)
((email-address :initarg :email-address)))
(defmethod print-it ((email email-contact))
(with-slots (email-address) email
(call-next-method)
(format t "~&Email address: ~A~%" email-address)))
(defclass postal-address (customer)
((postal-address :initarg :postal-address)))
(defmethod print-it ((address postal-address))
(with-slots (postal-address) address
(call-next-method)
(format t "~&Postal address: ~A~%" postal-address)))
(defclass customer-info (phone-contact email-contact postal-address)
())
(setf *my-info*
(make-instance 'customer-info
:first-name "Foo" :last-name "Bar"
:phone-number "555-1212"
:email-address "f...@bar.com"
:postal-address "1234 Main. St. Anytown, CA"))
(print-it *my-info*)
;;;
It all works as it is. (I think I'd write it a little differently,
though.)
The working code at the end of the paper contains a lot of extra
mechanism and complexity, and I claim that this is all
language-induced, that is, necessary to work around shortcomings in
the language.
To put it somewhat hyperbolically, Lisp lets you solve problems, while
other languages let you solve problems AFTER you've solved the
problems presented by using that language in the first place.
> I would like to learn how to program in Lisp, so I can appreciate
> something of the history of Computer Science. I am also interested
> in understanding Lisp, because I have read that it teaches you to
> think about problems recursively. But I am still struggling to
> figure out how to write an interesting program in the language.
Just take an interesting program that you want to write, and write it
in Lisp. You'll find it pretty hard at first, but if you persist,
one day you'll reach enlightenment.
One thing to realize. If Lisp is really snake-oil, it will seem weird
and quirky because it is just a collection of poorly thought-out hacks
and frauds. But if Lisp really is a serious alternative, it will also
seem weird and quirky because it doesn't follow various fundamental
assumptions about how things must be done. That's the very thing that
makes it a serious alternative.
The only way to find out which is true (snake oil or serious
alternative) is to take Lisp on its own terms, and NOT impose those
fundamental assumptions on it. Don't expect anything in Lisp to work
the way it does in any other language and you'll get it faster.
--
Fred Gilham gil...@csl.sri.com
Lisp has jokingly been called "the most intelligent way to misuse a
computer". I think that description is a great compliment because it
transmits the full flavor of liberation: it has assisted a number of
our most gifted fellow humans in thinking previously impossible
thoughts. E. Dijkstra
Kaz Kylheku
wrote:
> language. I just stare at the clisp prompt wondering what I should do
> next. I can write simple programs that process a list, but it is a toy.
> There must be more to it than just making toys.
This is your personal problem that has nothing to do with any programming
language. If you can't think of what to do, it can only be because you have
reached your wit's end.
You should go back to one of those programming languages that you cited; these
will give you enough impedance so that you can push against them and dissipate
your energy to create the feeling that you are accomplishing something.
C is great for this; you can start with no idea at all, and starting writing
thousands of lines of supporting code in hopes that the idea will materialize
in the meanwhile.
``Gee, I don't know what I will write, but I bet it will need a linked list, a
better malloc routine, some binary trees and reference-counted strings,
a buffer management module, ...''
Kaz Kylheku
>> The very reason why Lisp might look silly to you on first encounter is
>> that it has a _very_ clean syntax as opposed to other languages like
>> C, Java or Perl (!!) which have things like curly braces, parentheses,
>> brackets, semicolons, commas and more all over the place and use it
>> pretty arbitrarily.
>>
> yes, this is one good point. even though I have been using scheme (not so
> much cl) for a while now I still do not like the abundance of parenthesis
> around, though the syntax pointed out in my spec has a few bad points for
> many things I would still rather use it.
Nobody cares about the braindamaged spec for your nonexistent language, so stop
bringing it up, you lunatic. It's not topical here. Maybe try the patience of
comp.compilers for a change.
Christopher Browne
>> I have learned the very basics of Lisp. It is in my opinion a weird
>> language. It uses strange named operators (car...) and lots of (()).
>> I am left witha very superficial look at what appears to be a
>> retro language, a throwback to a time when computers were the size
>> of buildings. It is hard to think in Lisp or what I can use it for.
>
> One comment about `car' and `cdr' and the like. This is one where
> people disagree, but I still like them. The way I think about them is
> like `x' and `y' in a coordinate system. Why do you call it `x'? How
> about `horizontal'? Wouldn't that make more sense? But that misses
> the point --- `x' and `y' are abstractions. So are `car' and `cdr'.
>
> The other thing is that you can do `cadr', `caar' and so on. Some
> people hate this but I think it's kind of neat.
.. And if your code is filled with this stuff, it _usually_
demonstrates that you're not making particularly good use of the rest
of the language.
It is really painful to read "cadaverous" code; not unlike fiddling
with assembler, or FORTH code that's full of ROT, -ROT, SWAP, and
ROLL.
If you're using Lisp _well_, you'll have a nice set of defuns,
defmethods, perhaps some macros, and such, that make it largely
unnecessary to fill your code with rubbish looking like
(cons (cdddadar a) (cddar (car b)))
When I finish working on some Lisp code, I usually do a read through
it to see where there are references to CAR and CDR, with a view to
seeing if they couldn't be replaced with something a little more
elegant.
> Instead of
> for(i = 0; i < 5; i++) {
> ...do something....
> }
>
> you say
>
> (dotimes (i 5)
> (...do something))
And you do _that_ instead of
(do ((i 0 (incf i)))
((= i 5))
(format t "Value: ~A~%" i))
It's pretty likely that the introductory texts on Lisp mention DO, and
say little, if anything, about the other alternatives. The only place
I _ever_ use DO is if I'm building an iteration macro, and even _that_
is rare. DO is almost perfectly analagous to the C "for(;;) {}" loop,
with the difference that the order of the three statements changes a
bit.
> Note in the examples from C you see braces, brackets, semicolons and
> parentheses to indicate structure of one kind or another. In Lisp
> you see parentheses. (Lisp programs are `line noise free zones'!)
Mind you, the DO example is filled with somewhat non-obvious sets of
list structure:
(do ((variable initial-value update-form))
(termination-test)
(body-of-loop))
The only piece of that which is expressly identified as what it is is
the DO at the start. And I downright _hate_ looking at DO loops,
pretty much as a result of that.
One thing that I kind of like about the syntax of ML is that it puts
fairly sensible names to the pieces.
The similarly-not-overly-obvious LET statement
(let ((a b) (c d)) (foo a) (bar c))
in ML would look something like:
let
a = b and
c = d
in
foo(a);
bar(c);
And while I wouldn't argue that it's worth leaping to ML _just_
because of that, I _would_ argue that it's likely to be more
"intuitive," initially, than the Lisp way of expressing it, and that
the ML representation is a pretty nice way of _explaining_ what is
going on to the beginner.
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www3.sympatico.ca/cbbrowne/oses.html
"What you end up with, after running an operating system concept
through these many marketing coffee filters, is something not unlike
plain hot water." -- Matt Welsh
cr88192
hell, at least this is some feedback.
if others feel similar I guess it explains the lack of reply.
if I write a compiler will this topic be more acceptable?...
Thien-Thi Nguyen
> If you can't think of what to do, it can only be because you have
> reached your wit's end.
OP needs inspiration. OP: maybe a good idea to take a step back, look
at yourself, see what is your personality, then try to express yourself
somehow. some humble suggestions:
if you are artistic, write programs that are artistic (and produce art,
bonus!).
if you rage against the machine, write simulation programs, and build a
better society.
if you are lazy, write screensavers.
if you are curious, write virii.
if you are a slave, convince your fellows that lisp is no good and talk
amongst yourselves.
if you are kind, learn what you can learn and teach what you can teach.
if you are whiny, write programs that filter spam (please).
if you want to cash in on the programming "profession", hire lisp
programmers and give them some slack.
thi
Thomas Stegen CES2000
news:umi9336...@corp.supernews.com...
> if I write a compiler will this topic be more acceptable?...
His point if more than likely that in this newsgroup lisp is the
topic. If your language is not a Lisp then it is off topic here.
--
Thomas.
Approaching singularity.
Kaz Kylheku
> Kaz Kylheku wrote:
>> Nobody cares about the braindamaged spec for your nonexistent language, so
>> stop
>> bringing it up, you lunatic. It's not topical here. Maybe try the
>> patience of comp.compilers for a change.
>
> hell, at least this is some feedback.
> if others feel similar I guess it explains the lack of reply.
>
> if I write a compiler will this topic be more acceptable?...
Not in this forum unless it is a compiler for the language ANSI Common Lisp.
Not in comp.lang.scheme, unless it contains an implementation of an RnRS spec.
cr88192
my last compiler was scheme.
no one in comp.lang.misc seemed to care either when I had posted there.
Erik Naggum
| no one in comp.lang.misc seemed to care either when I had posted there.
Why does it matter to you whether people on Usenet care? Usenet is a good
place to people who already care about the same things; they congregate in
newsgroups according to what they care about. When people in a newsgroup do
not care about what you care about, they are extremely unlikely to /start/ if
you somehow imply that they /ought/ to.
If you feel that people /should/ care about what you care about, you have only
set out to become a nuisance to others in their eyes. They will want you to
go away more than anything else. If even this conducive to your personal
needs, you should really talk to someone who already cares about /you/.
Mr. Neutron
>> making a stack or two and moving items around on a list. You have to
>> understand from my perspective, I can accomplish the same thing in just
>> about any language i know and without any learning curve.
> Can you really? So please write such thing in C, without knowing any C
> of course.
>
do.
I am just experiencing a problem in learning a new language. You could
imagine that I am fluent in a certain type of language. Lisp and Scheme
are a very different type of language.
I can not see in my mind how to translate my ideas from my native tongue
to my new language. All I can do in my new language is make toys. While
that is an interesting career, I want to build rocket ships.
I can build rocket ships in my native tongue (C). Translating my rocket
ship into Lisp results in a broken machine. I am missing doors, windows,
glass, steering controls, landing gear, wings, and fuel. I have a
complete toolbox in C. In Lisp, I just have a screwdriver.
That is my frustration with Lisp so far. I can build rockets. But in Lisp
I am starting all over again. It is sort of intimidating. I am actually
kind of interested in the challenge. But I need a guide to teach me.
I just can't find a guide. It would be nice if there was a Lisp for C
programmers book around.
That's why I am griping. It's not that I think Lisp sucks. It is that I
can not communicate in it at all. I am a stranger in a strange land in
Lisp.
Bye
Jacek Podkanski
Because everybody seems to love to discuss this subject
--
Jacek Podkanski
cr88192
> * cr88192 <cr8...@hotmail.nospam.com>
> | no one in comp.lang.misc seemed to care either when I had posted there.
>
> Why does it matter to you whether people on Usenet care? Usenet is a
> good place to people who already care about the same things; they
> congregate in
> newsgroups according to what they care about. When people in a
> newsgroup do not care about what you care about, they are extremely
> unlikely to /start/ if you somehow imply that they /ought/ to.
>
> If you feel that people /should/ care about what you care about, you
> have only
> set out to become a nuisance to others in their eyes. They will want
> you to
> go away more than anything else. If even this conducive to your
> personal needs, you should really talk to someone who already cares
> about /you/.
>
I have not really found any real language design groups which have very
many people in them. I could try again on comp.lang.misc, but it would
probably be more of the same.
in life I have no freinds, and I am alone. I guess I wanted people to talk
to about something so that I am not in more isolation...
before I could talk to my ex about stuff, then she left me. since then I
have made little progress on anything, everything now seems to be in the
past. I still do not really understand why she left, just at the end she
said she did not care about me anymore. that was 2 months ago...
all my life has been like that, people get bored with me then they leave.
everyone else avoids me altogether...
being online has been an attempt to escape that, hoping somewhere somehow
what I said would mean something. due to my lack of productivity this is
too large of a goal, thus I continue to be worthless...
Christopher Browne
Why would you _expect_ them to care?
There is a sizable population of people in these newsgroups that are
much more interested in figuring out ways of using the "industrial
grade" systems that they have than they are in hearing about the
latest techniques you just heard about (that they likely knew of ten
years ago) that you added, then took out because it didn't turn out
well.
In comp.lang.scheme, there are _barrels_ of free implementations out
there that are likely a whole lot more featureful than your language
is at this point. There are _largely disused_ implementations that
are likely of wider interest.
On comp.lang.lisp, the main dialect of Lisp under discussion is one
that has been fairly well specified since the 1980s, and your language
doesn't hold a candle to it in terms of overall functionality. Why
SHOULD people on comp.lang.lisp be interested in something that's not
compatible with their favored language, and which lacks a whole lot of
the functionality that they expect and demand.
If you need for people to "care" about your language design
discussion, then perhaps you need to work on a language implementation
that _will_ seem consequential to them. If you were to add a few
features to CLISP, _that_ would be of some interest to people. Ditto
for SBCL or CMUCL. A while back you were looking into Yale T; if you
were to resurrect the code base, and get a compiler running on a
modern Linux or FreeBSD system, I'm _sure_ that would attract some
interest. (Albeit from a different direction.)
But when what you're essentially doing is to fiddle with your own
private language implementation, why WOULD other people find this of
immense interest?
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/sgml.html
"I support Microsoft's right to innovate. I just wish they would make
use of that right." - Steve Shaw
Hartmann Schaffer
"Mr. Neutron" <nickts...@charter.net> writes:
> Hi,
> I don't want to start a religious war. I am on my travels through
> learning computing, and wanting to explore the universe of Computer
> Science. This is just my opinions of Lisp so far.
>
> I have learned the very basics of Lisp. It is in my opinion a weird
> language. It uses strange named operators (car...) and lots of (() ).
> I am left witha very superficial look at what appears to be a retro
> language, a throwback to a time when computers were the size of
> buildings. It is hard to think in Lisp or what I can use it for.
anything new can be hard to learn if you don't have the right
tutorial. unfortunately, you don't mention which book you are using
as an introduction
your impression of lisp's syntax seems to be solely based on it being
deviating from the syntax of the languages you used. in fact, it is
amazingly simple, using only very few rules. the languages you
mentioned use an algebraic syntax, which is well established for
numeric problems, but tends to become pretty complex once you go
beyond the normal arithmetic operations (how many C programmers do you
know who don't use superfluous parantheses because they have problems
remembering the precedence rules once shift and logical operators
become involved). once you have become used to the unfamiliar syntax,
you most likely will appreciate its simplicity and consistency.
parantheses are only a problem if you use the wrong editor. most
editors that are meant for programmers now support lisp and eliminate
the parenthesis problem. after a while you won't even notice the
parentheses, esp. if you format your code logically.
depending on what examples you have tried so far, the advantages of
lisp might not be that obvious, esp. if you limit yourself to simply
transcribing programs you have written in familiar languages. i wold
suggest you have a look at books like "paradigms of artificial
intelligence - case studies in common lisp" (norvig) or "the structure
and implementation of computer programs" (abelson/sussman) to get an
appreciation of how simple problems can be expressed in lisp like
languages.
yes, function names carry a lot of historical baggage that often is
troublesome for newcomers, but this is simply something you have to
get used to. scheme, a language of the lisp family, has made an
attempt to remove some of this historical baggage, i.e. introduced
more consistent naming conventions for the standard functions. most
people in this newsgroup think that think that this is not enough of
an advantage to give up the advantages common lisp has over scheme.
hs
--
don't use malice as an explanation when stupidity suffices
Wade Humeniuk
Windows), download
http://www3.telus.net/public/whumeniu/runnerslog-140.exe
Its a self-installing application (shaken at delivery level 5).
Manual is:
http://www3.telus.net/public/whumeniu/Manual.html
I have also posted the source code. Maybe if you stare at it long enough it will make
some sense and you will get the idea of how to get your ideas down in Lisp. (Hint: Just
like in C, a Lisp app is built up of functions and expressions). Load defs.lisp first and
then see run.lisp for the main functionality. The main entry function is make-running-log
http://www3.telus.net/public/whumeniu/running-140-src.zip
In theory this all runs on LispWorks for Linux, though I have not tried.
Wade
Steven T Abell
> in Lisp will enlighten me and will be worth the pain of getting
> acquainted with it, I'd like to know!
It will definitely be worth it,
but things will look really strange to you for a while.
Part of the problem is that you seem to be trying to build things
using the mental tools you developed for other languages.
You can write C in Lisp, but you won't be happy about it.
Since you already know several traditional procedural languages,
you've noticed that they're all about the same under their skins.
Smalltalk is not like that.
APL is not like that.
Lisp is *definitely* not like that.
The skills you've developed elsewhere will still be useful to you,
but you have an entirely different outlook to acquire
before you can turn those skills to your benefit in Lisp.
Traditional procedural languages
are concerned with managing the memory field of a VonNeumann machine.
Lisp is concerned with construction using some very general ideas,
memory field be damned,
and the realm of what you can construct is considerably larger
that what you're used to thinking about in a traditional language.
Yes, you can do these things in C,
but some of them hurt so much that you'd never think to do them,
and those are often the things that are most useful in real programs.
Higher-order functions are a case in point.
A lot of people complain about it,
but I think the Abelson & Sussman book is a decent piece of work,
and you'll learn some other good stuff along the way.
Here's a guideline you can use in this matter,
regardless of how you pursue it:
as long as you're inclined to complain about all those silly parentheses
and CARs and CDRs and lack of significant syntax,
you haven't yet understood what Lisp is about.
Once you get it, you'll never think the same way about programming again.
I wish I could be more specific,
but there's a change that has to happen in your head,
and the only way I know to make that happen
is to look at some good examples and keep trying to make your own.
It's worth doing.
Steve
--
Steven T Abell
Software Designer
http://www.brising.com
In software, nothing is more concrete than a good abstraction.
larry
>> It uses strange named operators (car...) and lots of (() ).
Why do people coming to lisp complain about all the parenthesis?
Take c code, change { } to parenthesis and move the position a little and
you get something like
(for (i=0;i<10;i++)
(for (j=0;j<10;j++)
(if i == j
(printf "i =j\n");
(printf "i not j\n");
)
)
)
That looks just like lisp, but nobody notices it because they're used to seeing
it. What about all the damn semi-colons in c-- weird.
Adam Warner
> yes, function names carry a lot of historical baggage that often is
> troublesome for newcomers, but this is simply something you have to get
> used to.
Not in my limited experience. For example I've been using first, second,
rest, last, etc. in my code. There's no historical baggage associated with
those terms. There isn't a car or cdr in sight.
Sure you might come across mapcar etc. but they are such powerful
operators that many people will be learning them for the first time
anyway.
> scheme, a language of the lisp family, has made an attempt to remove
> some of this historical baggage, i.e. introduced more consistent naming
> conventions for the standard functions. most people in this newsgroup
> think that think that this is not enough of an advantage to give up the
> advantages common lisp has over scheme.
I found it to be the other way around Hartmann. Scheme forces you to use
more historical baggage (at least initially before you define new
functions) since you must use function names like car, cdr, etc.
But defining new functions with common names doesn't help because the
single namespace forces you to avoid those names in variables (along with
remembering to avoid all the common built in names such as list and
string). The more obvious the function name, the more likely it's going to
bite you.
CLISP:
[1]> (setf list '(this is a list))
(THIS IS A LIST)
[2]> (list "a" "b" "c")
("a" "b" "c")
MZScheme:
> (set! list '(this is a list))
> (list "a" "b" "c")
procedure application: expected procedure, given: (this is a list);
arguments were: "a" "b" "c"
You don't have to know any of the function names in Common Lisp to avoid
redefining them as variables. While it's a big language it doesn't get in
your way.
Given Common Lisp's long history the level of historical baggage is
remarkably low. And the more I learn about the language the more I
appreciate the skill of all its designers over the decades.
Regards,
Adam
Software Scavenger
> Now this is the kind of statement that makes me interested in Lisp! Why
> is it considered a Ferrari? It looks like a VW beetle when I play with
> it.
As an electric drill looks like an awkward hammer. It doesn't even do
a very good job of driving nails. And what's that wire thing sticking
out of it, with the plug on the end? Is that some kind of
compatibility adaptor or something? The whole thing seems awkward and
backward. And it's too heavy to be handy.
The electricity you need to make Lisp come alive is available if you
know where to look for it. It's simply learning. The more Lisp you
learn, the more power you have, and the closer you are to making it
spin.
cr88192
> But when what you're essentially doing is to fiddle with your own
> private language implementation, why WOULD other people find this of
> immense interest?
not sure, I could just continue where I left off and add everything I was
thinking to my scheme implementation, this would save having to redesign
and reimplement everything...
the only possible relavence in any case will be that it will be the
language I use for my projects.
it does not matter, I had just wondered if anyone would be interested...
Luis Guillermo RESTREPO RIVAS
on LISP) is somewhat illuminating:
http://www.paulgraham.com/lib/paulgraham/acl1.txt
As the language best suited, for example, to work on Genetic
Programming, see section 4.3, pages 71-72 of "Genetic Programming" by
John R. KOZA: "Reasons for choosing LISP".
As a language to explore fundamental things of math and computer
science, see the book by Grogory J. CHAITIN:
"The limits of Mathematics", pages 31-44
"Whay I love (pure) LISP" and
"Proving LISP Programs are elegant")
"The Unknowable".
It have bee said that LISP is a "programmable programing language",
where the programmer has power to define his/her own language for the
problem at hand.
Also, think that the languge has been actively used and developed by a
community of computer scientists, mathmeticians, researches solving
difficult problems, and exploring the challenges of AI, so the time
past from the begginings of LISP doesn't mean obsolescence but
maturity, compared with new languages as Java, even in the Object
Oriented trend, with te power of CLOS.
Best regards,
Luis G. RESTREPO
http://LuisGuillermo.com
Erik Naggum
| if people don't care I have little reason to implement it...
That kind of attitude is just so /stupid/ I could scream. Well, let me
scream. THAT ATTITUDE IS SO GODDAMN STUPID! (Thank you.)
What you do with your time should be /completely/ unaffected by what other
people find valuable. You could not possibly attract anyone with some half-
assed non-implementation of an idea, so just give that part of the task up
right now. What you /can/ do, however, is prove to yourself first, and then
to others, that you can accomplish something worth accomplishing. Some
people prove this with degrees in educational institutions. Others start
small companies in their garage with the proceeds of their past successes.
If you are starting out in life and treat creating a language as a means to
learn something, which I do not even consider a worthwhile task if you are
into compiler design, you should not even /ask/ people to care. You have
set out to learn something by explicitly rejecting everything that other
people have done before you. Create your own language and be on your own.
Frank A. Adrian
> in life I have no freinds, and I am alone. I guess I wanted people to talk
> to about something so that I am not in more isolation...
So go to a local bar and quit bothering us.
> all my life has been like that, people get bored with me then they leave.
> everyone else avoids me altogether...
Yup, people tend to get that way around a whiney little troll like you. Go
away.
faa
Fred Gilham
> if people don't care I have little reason to implement it...
You have to do some `supply-side' thinking --- `build it and they will
come'. Of course, you are taking the risk that you will build it and
they'll stay away in droves. But if you win, you win really big.
If you decided to revive the T implementation, personally I'd
definitely comment on it, and one part of my comment would be `thank
you very much'.
But I found your language design really frustrating. You seemed to
want to combine some aspects of Python, Scheme and Common Lisp. It
didn't seem at all promising to me and I thought silence would be the
most charitable response.
You should realize that good self-image comes from accomplishment. If
you do something good, you WILL become world famous. I kid you not.
That's just the way the Internet is. You will get messages from all
over the world either praising you or asking for free upgrades. :-)
So you've got a lot of time on you hands: pick a project and see it
through. Then put it out there. Repeat until satisfied.
--
Fred Gilham gil...@csl.sri.com
Do remember you're there to fuddle him. From the way some of you
young fiends talk, anyone would suppose it was our job to teach!
-- The Screwtape Letters, C. S. Lewis
Charlton Wilbur
EN> If you are starting out in life and treat creating a language
EN> as a means to learn something, which I do not even consider a
EN> worthwhile task if you are into compiler design, you should
EN> not even /ask/ people to care. You have set out to learn
EN> something by explicitly rejecting everything that other people
EN> have done before you. Create your own language and be on your
EN> own.
On the contrary, I think this is a valuable exercise -- but its end is
not producing a useful language, especially not one that will be
useful to other people, but in learning about why things are done the
way they are in a particular language. When I was an undergraduate, I
looked at the dozen languages I had been exposed to, and decided that
I didn't like any of them completely, and that I could do a lot better
if I designed a language on my own. I was wrong; my pet language
wound up looking a lot like Objective-C, but I learned an enormous
amount about language design in the process.
All computer languages -- indeed, all engineering decisions -- involve
choices among various sets of tradeoffs. Sometimes the best way to
understand this principle, as well as to see it in action, is to
explicitly reject all existing solutions and to design one from the
ground up. The ancients were wise, but they were also foolish or
short-sighted; how many things in computer languages are there because
of historical precedent? If we were designing LISP today, would we
have functions named car and cdr? If we were designing C++ today,
would we put such immense importance on avoiding run-time typing
decisions?
And even then, designing a new language does not necessarily mean
rejecting all that has gone before. Did Bertrand Meyer discard what
he had learned from other languages when he designed Eiffel? Did
Bjarne Stroustrup discard what he had learned from other languages
when he started down the path that led to C++? Did Kernighan,
Ritchie, and Thompson discard what they had learned when they created
C? Of course not. All of them saw deficiencies in the existing
languages, and created a new language with what they considered
strengths and with as few weaknesses as possible.
Still, it's hardly surprising that comp.lang.lisp doesn't care. I
wouldn't expect it to; the language is neither LISP nor LISP-like, and
it doesn't seem to address any need I might have that isn't already
addressed by a more mature language.
Charlton
Erik Naggum
| And even then, designing a new language does not necessarily mean rejecting
| all that has gone before.
After you know what has gone before, you can be more intelligently creative
than when you start out from scratch.
| Did Bertrand Meyer discard what he had learned from other languages when he
| designed Eiffel? Did Bjarne Stroustrup discard what he had learned from
| other languages when he started down the path that led to C++? Did
| Kernighan, Ritchie, and Thompson discard what they had learned when they
| created C? Of course not.
Of course not. Were they 18-year-old whining loners who craved attention
for their inventions created in a vacuum? Of course not. Do you know
anything worth beans to anyone else when you are 18? Of course not.
| Still, it's hardly surprising that comp.lang.lisp doesn't care.
So far, the willingness to listen does not even extend to Paul Graham's Arc.
Novices with a desire to reinvent the world before they know what it is like
should take notice of this. Improving on Common Lisp is /very/ hard. And
most of the "improvements" on Scheme are neither improvements nor Scheme.
Friedrich Dominicus
> >>But all I have is a dumb book that talks about
> >> making a stack or two and moving items around on a list. You have to
> >> understand from my perspective, I can accomplish the same thing in just
> >> about any language i know and without any learning curve.
> > Can you really? So please write such thing in C, without knowing any C
> > of course.
> >
> I *do* know C. If I *didn't* know C, obviously it would be hard to
> do.
Well why don't you expect the same for Lisp? How can you expect that
learning is *not* necessary?
>
> I am just experiencing a problem in learning a new language. You could
> imagine that I am fluent in a certain type of language. Lisp and Scheme
> are a very different type of language.
You're right they are different. But there are other "foreign"
languages for users of C, Pascal and how they are all named. Look at
Haskell, OCaml, Forth etc.
>
> I can not see in my mind how to translate my ideas from my native tongue
> to my new language. All I can do in my new language is make toys. While
> that is an interesting career, I want to build rocket ships.
Well I would expect to start small and grow with the tasks at
hand. But you could write Lisp simular to C and it would work. This is
one of the difference to other languages.
>
> I can build rocket ships in my native tongue (C). Translating my rocket
> ship into Lisp results in a broken machine. I am missing doors, windows,
> glass, steering controls, landing gear, wings, and fuel. I have a
> complete toolbox in C.
What does this toolbox contain?
> In Lisp, I just have a screwdriver.
Lisp is you toolbox. And you can translitereate C code nearly to Lisp
and it will work why should anything get lost?
>
> That is my frustration with Lisp so far. I can build rockets. But in Lisp
> I am starting all over again. It is sort of intimidating.
This is the usualy feeling one have while starting something new. You
even get this feeling while beeing perfectly fluent in one language
but while starting at a topic which you never have touched before. At
the moment you got a problem because you entry no-where land for
you.
> I am actually
> kind of interested in the challenge. But I need a guide to teach me.
> I just can't find a guide. It would be nice if there was a Lisp for C
> programmers book around.
Well the problem can be that C has certain kind of world-view. One
thing differently in Lisp is it's functional side. I suggest looking
at a "pure" functional language and see how programming works
there. Than you understand the "functional" side from Lisp much
better.
And then you can check out
http://www.bagley.org/~doug/shootout/
Well and got and idea that a Lisp solution must not look much
different from a C solution.
>
> That's why I am griping. It's not that I think Lisp sucks. It is that I
> can not communicate in it at all. I am a stranger in a strange land in
> Lisp.
You can't expect to learn a language without that feelings. And you
need patience, write some code in Lisp polish it, tackle it from
different angles and you will feel much more comfortable soon.
Just an very simple example. Write down different ways to "sum up
elements". Write it C-ish, write it a functional way, and and
Regards
Friedrich
Bruce Hoult
"Adam Warner" <use...@consulting.net.nz> wrote:
> But defining new functions with common names doesn't help because the
> single namespace forces you to avoid those names in variables (along with
> remembering to avoid all the common built in names such as list and
> string). The more obvious the function name, the more likely it's going to
> bite you.
>
> CLISP:
> [1]> (setf list '(this is a list))
> (THIS IS A LIST)
> [2]> (list "a" "b" "c")
> ("a" "b" "c")
>
> MZScheme:
> > (set! list '(this is a list))
> > (list "a" "b" "c")
> procedure application: expected procedure, given: (this is a list);
> arguments were: "a" "b" "c"
>
> You don't have to know any of the function names in Common Lisp to avoid
> redefining them as variables. While it's a big language it doesn't get in
> your way.
This is a point I hadn't seen before. However:
- avoiding shadowing a function name is only of importance if
you're intending to use that function (in a lexically enclosed
scope).
- if you don't know some function exists then you're not likely
use it, or care if it gets shadowed.
I gusss the exception to this is if you use some macro that expands to a
function you don't know about, and accidentally shadowed. Which would
be a problem in CL (butfor the two namespaces), but isn't in a language
with hygienic macros, such as Scheme or Dylan.
-- Bruce
Duane Rettig
> >>But all I have is a dumb book that talks about
> >> making a stack or two and moving items around on a list. You have to
> >> understand from my perspective, I can accomplish the same thing in just
> >> about any language i know and without any learning curve.
> > Can you really? So please write such thing in C, without knowing any C
> > of course.
> >
> I *do* know C. If I *didn't* know C, obviously it would be hard to
> do.
Precisely. So don't assume any different for Lisp.
> I am just experiencing a problem in learning a new language. You could
> imagine that I am fluent in a certain type of language. Lisp and Scheme
> are a very different type of language.
>
> I can not see in my mind how to translate my ideas from my native tongue
> to my new language. All I can do in my new language is make toys. While
> that is an interesting career, I want to build rocket ships.
>
> I can build rocket ships in my native tongue (C). Translating my rocket
> ship into Lisp results in a broken machine. I am missing doors, windows,
> glass, steering controls, landing gear, wings, and fuel. I have a
> complete toolbox in C. In Lisp, I just have a screwdriver.
Translating to _any_ language you do not know will result in brokenness.
Take a look at http://www.engrish.com/recentdiscoveries.html for
some examples of broken translations to English by people who never
bothered to really learn the language.
> That is my frustration with Lisp so far. I can build rockets. But in Lisp
> I am starting all over again. It is sort of intimidating. I am actually
> kind of interested in the challenge. But I need a guide to teach me.
> I just can't find a guide. It would be nice if there was a Lisp for C
> programmers book around.
But Lisp is not for C programmers; Lisp is for Lisp programmers. You
can be both, but you must decide that you will learn to be a Lisp
programmer, or it will never happen. Just decide to do it and start
learning. Others have already given you plenty of material to start
working with.
> That's why I am griping. It's not that I think Lisp sucks. It is that I
> can not communicate in it at all. I am a stranger in a strange land in
> Lisp.
The strangeness will only disappear when you start becoming familiar
with it, rather than relating it to your own C experience.
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Adam Warner
It's a point I discovered in my learning. And I don't think it is best
practice for programmers to be generating unintended side effects such as
shadowing core functions and relying upon lexical scope to protect them.
Your comment that "if you don't know some function exists then you're not
likely use it, or care if it gets shadowed" still means that as you gain
understand of the language you may start to care about rewriting your code
to avoid those side effects. You may even add one of those newly learned
functions into your code and then witness it break.
> I guess the exception to this is if you use some macro that expands to a
> function you don't know about, and accidentally shadowed. Which would
> be a problem in CL (butfor the two namespaces), but isn't in a language
> with hygienic macros, such as Scheme or Dylan.
Common Lisp certainly doesn't need hygienic macros. Why does Dylan? (Sorry
Bruce I'm pretty ignorant about Dylan. Does it have a single namespace?)
By the way, I've come to realise that my initial emphasis of a few months
ago that Lisp symbols should be case sensitive was misplaced. There's also
a nice discussion about case sensitivity in Ian Joyner's C++ Critique:
http://www.elj.com/cppcv3/s4/#s04-12
Still it would be nice if the information wasn't just thrown away but was
instead available as some aspect of a symbol's property.
Regards,
Adam
Alain Picard
> By the way, I've come to realise that my initial emphasis of a few months
> ago that Lisp symbols should be case sensitive was misplaced.
>
> Still it would be nice if the information wasn't just thrown away but was
> instead available as some aspect of a symbol's property.
Where did you get the idea that lisp symbols are case insensitive?
Adam Warner
I don't have that idea but the sentence was very sloppy. The Lisp Reader
throws away the case information by default (that is it converts all
symbols to uppercase).
As I understand it symbols have a number of properties associated with
them. It would be nice if one of those properties was information about
the original case of the symbol (e.g. it may be helpful when trying to
generate case sensitive markup such as XML or be especially helpful when
trying to make foreign interface calls that require the use of
StudlyCaps).
It would seem to be a modest and compatible addition to the language that
would not break any existing code. The drawback would be the manipulation
and storage of extra strings.
I am aware that the read table can be set to case sensitive and the
inplications for existing code and development environments breaking.
Regards,
Adam
Pascal Costanza
>
> Hi,
[...]
> I have learned the very basics of Lisp. It is in my opinion a weird
> language. It uses strange named operators (car...) and lots of (() ).
> I am left witha very superficial look at what appears to be a retro
> language, a throwback to a time when computers were the size of
> buildings. It is hard to think in Lisp or what I can use it for.
>
> I can not imagine why I should keep trying to program in this language when I have
> better, easier modern languages with a cleaner syntax and operators with
> names that make sense to me.
IMHO, the strongest point for Lisp is the fact that it includes a
complete theory of computation. What does this mean?
It's clear that software is more powerful than hardware - you can start
a program and this virtually turns your computer into a new machine. The
reason for this power lies in the fact that inside the computer,
programs and data are treated in the same way. So starting a program X
means that a different program, part of the operating system, loads X
into main memory - here X is treated as pure data being loaded from hard
disk - and then arranges for the CPU to treat X like a program.
Turing machines are a theoretical means to abstract away from concrete
hardware issues but still retain this notion: data on a Turing tape can
either be treated as raw data or can be interpreted as instructions to
be carried out by the Turing machine. This is one possible basis for a
theory of computation.
The core of Lisp is another abstraction of this notion of treating data
and programs uniformly. However, the difference to Turing machines is
that Lisp is an executable "theory" of computation. The core of Lisp can
be defined in terms of itself, just because in Lisp data and programs
are essentially the same. Moreover, Lisp can be efficiently implemented
and it is relatively handy in order write serious programs in it. So
consequently and by definition, with Lisp you can make use of all the
power software provides. (By the way, you will quickly realize that
Lisp's apparently strange syntax is also a consequence of the unified
treatment of data and programs. You might even appreciate it by then. ;)
Almost all other languages deliberately restrict this power for several
reasons. Especially the unified treatment of data and programs is cut
from other languages in order to make them one or more of the following:
more safe, more intuitive, more efficient, more suited to particular
domains, and so on. However, there's always a price to pay for these
qualities and there is always a chance that you might run into problems
because of these deliberate limitations.
There's a lot to learn from Lisp about computer science as a whole. If
you understand Lisp's essentially ingredients - like closures,
higher-order functions, macros and so on - it's very likely that no
other programming language will ever surprise you again. For example, by
understanding Lisp, you will also have the means to understand in a
short amount of time concepts like inner classes and dynamic proxy
classes in Java, the essential ingredients of Dylan, Python or Ruby,
what Generative Programming in C++ is all about, what the strengths of
ML, CAML or Haskell are, and so on. In short, it will make you a better
programmer in general.
Pascal
--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Dave Bakhash
> I am aware that the read table can be set to case sensitive and the
> inplications for existing code and development environments breaking.
It seems that the underlying problem is that the symbols in the :cl
package are uppercased, which is why the default reader upcases symbols.
If you want case sensitivity, but still want to use lower-case, then use
:invert (and probably some implications on *print-case* as well, and
will cause problems when using existing code, etc.)
I don't do this, but I wonder if this (or something similar) is what
people who want a case-sensitive CL do.
dave
Ziv Caspi
It's not weird at all. In C (and many similar languages), there are a
lot of different "syntax embellishments" to actually help reading.
LISP uses only parentheses. This makes it very easy to parse by a
computer, but not by (mant? most?) humans.
In your example above you didn't go all the way. You should also have
removed all semicolons and replace them with parentheses, etc. Making
everything look the same has lots of advantages, but some
disadvantages. The equivalent C code would look like:
for ( i=0; i<10; i++ )
for ( j=0; i<10; j++ )
if (i==j)
printf( "i=j\n" );
else
printf( "i not j\n" );
This is a very mild example, BTW. In C++ and C99, for example,
variable definitions (although properly nested) don't have to be
defined at the beginning of scope. The following C++ program would
look like parentheses soup in LISP:
{
File reader( ... parameters... );
...do something with reader...
File writer( ... parameters... );
...do something with both reader and writer...
}
In LISP, you either have to group all these declarations in a single
let-like expression (assuming the semantics of your algorithm allow
it), or open more and more explicit scopes, which make reading more
and more difficult.
Paolo Amoroso
wrote:
> Kaz Kylheku wrote:
[...]
> > Nobody cares about the braindamaged spec for your nonexistent language, so
> > stop
> > bringing it up, you lunatic. It's not topical here. Maybe try the
> > patience of comp.compilers for a change.
>
> hell, at least this is some feedback.
> if others feel similar I guess it explains the lack of reply.
Lisp was created by some of the most creative minds in the computing field
over the course of several decades, after considerable thought,
experimentation, discussion and design tradeoff evaluation. Lisp's motto
should be: "been there, done that".
With due respect for your enthusiasm, I don't think that a few weeks worth
of thinking can bring any significant innovation. The tough part is not to
understand why a new feature may be useful, but to realize why it may not
be a good idea.
It takes much, much more to get a Lisper notice something "new", let alone
get excited about it.
If you are interested in language design and compilers, why you don't
contribute to improving the ANSI compliance of existing Lisp
implementations?
> if I write a compiler will this topic be more acceptable?...
I don't think so.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso
> * Mr. Neutron
> | I don't want to start a religious war.
>
> Do /not/ feed the trolls.
That's good advice. But leaving the troll's claims unchallenged may give
the wrong messages to those with limited or no Lisp background who may
later happen to check the comp.lang.lisp archive. What do you think?
Andreas Hinze
>
> With due respect for your enthusiasm, I don't think that a few weeks worth
> of thinking can bring any significant innovation. The tough part is not to
> understand why a new feature may be useful, but to realize why it may not
> be a good idea.
>
standard (AFAIK they are reviewed all five years) ? Are there any activities to
add new features or cleaning up ambiguous items ?
Best
AHz
Kaz Kylheku
> rejecting all that has gone before. Did Bertrand Meyer discard what
> he had learned from other languages when he designed Eiffel? Did
> Bjarne Stroustrup discard what he had learned from other languages
> when he started down the path that led to C++? Did Kernighan,
> Ritchie, and Thompson discard what they had learned when they created
> C? Of course not.
Actually I dare say that the answer is yes on all counts. And I would
add the remark that the world would have been better off without
these,
with the possible exception of Eiffel.
These designers, deliberately or not, discarded lots of useful ideas
for
which efficient compilation is difficult to implement. Multiple
dispatch,
garbage collection, dynamic typing.
Stroustrup declined nearly every opportunity to improve on weak areas
of C, in the name of preserving backward compatibility. Actually, many
things can be fixed in an entirely backward compatible way, for
example
allowing arrays to be assigned and returned from functions, or
allowing
the . and -> operators to be interchangeable. Stroustrup could have
specified that C++ evaluation takes place left to right, thereby
eliminating those stupid sequence points that only serve as
programming
pitfalls. That would have been completely backward-compatible as well.
He introduced a completely useless keyword, ``class'' which behaves
only slightly differently from ``struct'', yet he did not fix the
stupid
overloading of the meaning of ``static'', which could have been done
by a new keyword. For example the ``private'' and ``public'' keywords
introduced for writing access specifiers could be used at file scope
to
determine the linkage of an external declaration.
> All of them saw deficiencies in the existing
> languages, and created a new language with what they considered
> strengths and with as few weaknesses as possible.
That's not the case with C; C started out as a deliberately
dumbed-down
imitation of BCPL called B that could fit onto a machine with 8
kilowords
of memory. C was designed to to do job, not to be a showcase of
language
design. That job was maintaining an operating system and related tools
in a reasonably portable and maintainable expression.
In a paper called _The Development of the C Language_, Ritchie admits
that he did not fix the precedence of the & and | operators when
&& and || were added because a whopping 600 kilobytes of C code
already existed.
Friedrich Dominicus
>
> And then you can check out
> http://www.bagley.org/~doug/shootout/
>
> Well and got and idea that a Lisp solution must not look much
> different from a C solution.
Ok I'm sorry, english has catched me. Of course it should be "that a
Lisp solution does not have look much different".
I'm sorry for that confusion.
Friedrich
Fred Gilham
> It's not weird at all. In C (and many similar languages), there are
> a lot of different "syntax embellishments" to actually help reading.
> LISP uses only parentheses. This makes it very easy to parse by a
> computer, but not by (mant? most?) humans.
Well, the argument is that in Lisp, eventually you don't `see' the
parentheses --- the mind filters them out as irrelevant to
understanding what's going on. Then you just start reading code in a
literal sense. The syntax embellishments aren't necessary.
--
Fred Gilham gil...@csl.sri.com
If there is one consistent theme to be found in the great works of the
20th century, it seems to me to be the presentation of a doomed quest:
the search to find something capable of filling that great void that
has been left in the soul of man by the repudiation of God.
--- Skylar Hamilton Burris
Richard Krush
> Paolo Amoroso wrote:
>
> This might be a little bit off-topic, but what is the current state of
> the ANSI standard (AFAIK they are reviewed all five years) ? Are there
> any activities to add new features or cleaning up ambiguous items ?
>
According to the annual report for year 2000 from the committee [1],
there has been no active projects and generally the committee has been
falling apart.
[1] http://www.ncits.org/tc_home/j13.htm
Here are some interesting quotes from the aforementioned web-site:
"Membership was stable at eleven in 1999 and 2000, but 2001 paid renewals
may have fallen as low as three."
"J13 continues with no active projects. There was one meeting during
2000, conducted by electronic online chat."
"Despite the best of intentions and genuine interest in standardizing
areas of current development, no project proposals have been
generated. The Chair does not foresee any to be immediately
forthcoming."
--
Richard Krushelnitskiy "I know not with what weapons World War III will
rkrush (at) gmx.net be fought, but World War IV will be fought with
http://rkrush.cjb.net sticks and stones." -- Albert Einstein
Andreas Hinze
i changed the topic because i found that this now goes far away from the
original thread. I'm not very experienced with Lisp history and when to
introduce new stuff but i'm still wondering about that:
Richard Krush wrote:
>
> According to the annual report for year 2000 from the committee [1],
> there has been no active projects and generally the committee has been
> falling apart.
>
> [1] http://www.ncits.org/tc_home/j13.htm
>
> Here are some interesting quotes from the aforementioned web-site:
>
> "Membership was stable at eleven in 1999 and 2000, but 2001 paid renewals
> may have fallen as low as three."
>
> "J13 continues with no active projects. There was one meeting during
> 2000, conducted by electronic online chat."
>
Why aren't there active projects ? At least multithreading and foreign function
support are concepts that would be nice to have in the standard. And i think there
are a lot of other topics too.
> "Despite the best of intentions and genuine interest in standardizing
> areas of current development, no project proposals have been
> generated. The Chair does not foresee any to be immediately
> forthcoming."
Is this process that complicated ? If i look at CLOCCs port library i find the
first "proposal". AFAIK the only purpose of this library is to "hide" differences
in implementations that are not covered by the standard.
I'm _not_ talking about bigger libraries. Erik Naggum made some good comments
about that some time ago. What i mean is that it is less usefull to have a set
of features in almost every lisp implementation when every implementation does
it in their own way (i.e. FFI).
Any idea's ?
Best
AHz
Kent M Pitman
This isn't OT.
> Hi all,
> i changed the topic because i found that this now goes far away from the
> original thread. I'm not very experienced with Lisp history and when to
> introduce new stuff but i'm still wondering about that:
>
> Richard Krush wrote:
> >
> > According to the annual report for year 2000 from the committee [1],
> > there has been no active projects and generally the committee has been
> > falling apart.
> >
>
> > [1] http://www.ncits.org/tc_home/j13.htm
> >
> > Here are some interesting quotes from the aforementioned web-site:
> >
> > "Membership was stable at eleven in 1999 and 2000, but 2001 paid renewals
> > may have fallen as low as three."
> >
> > "J13 continues with no active projects. There was one meeting during
> > 2000, conducted by electronic online chat."
>
> Why aren't there active projects ? At least multithreading and foreign
> function support are concepts that would be nice to have in the standard.
> And i think there are a lot of other topics too.
Speaking personally as someone who would have been first in line if he
thought this was a productive tack to take, but not in any official
representative of anything, the answer is simply this:
I personaly think ANSI is a large, too-slow, not-very-useful entity to
be accomodating all but the most low-level basic standards. It was
probably appropriate to standardize CL itself this way, but even then
it's quite clear that the long time-line caused by ANSI resulted in
some companies going bankrupt in the meanwhile. Was ANSI the cause?
Probably not. But did producing an ANSI standard cost a serious lot of
money on the part of all Lisp vendors? Yes.
Further, there is no evidence that the support already present in the
existing vendors is an impediment to anyone. The amount of work required
to hook yourself into the multithreading component of most vendors is quite
small, and even to port to a different system is often quite small. There
is a bigger difference on the foreign function call thing, but even then,
it should be possible in most cases to keep that work to a relative minimum.
Users love to point to things like this because they want everything on a
silver platter if they can get it, but the cost of getting this silver platter
is high enough that the rough edges present will buy you more in terms of
other things vendors could provide.
In sum, if vendors perceived that users were failing to buy Lisp
merely because of lack of a standard system of the kind you're talking, then
vendors themselves would rush to advertise these facilities.
If users perceived that the differences were annoying enough, they would
get together themselves and make an informal standard and insist that vendors
adhere, but no such movement has occurred.
The fact that there is no motion on either of these leads me to believe that
users just find this easy to grumble about because it's visible and "seems"
easy.
There is a hidden assumption in all of this that ANSI is the only kind of
standard, and that things are only worthy "community achievements" if they
are standards. I think these are bad assumptions. There are more streamlined
ways to make standards, and there are not-formally-standardized-things that
are nevertheless fine good community achievements and resources. Often,
standards bodies want you to believe otherwise because, after all, they are
in the commercial business of selling you their stamp of approval. But
think of college degrees: they're nice for those of have them, but their
absence is not proof that the person does not know what they're doing.
> > "Despite the best of intentions and genuine interest in standardizing
> > areas of current development, no project proposals have been
> > generated. The Chair does not foresee any to be immediately
> > forthcoming."
> Is this process that complicated ?
EXPENSIVE.
> If i look at CLOCCs port library i find the first "proposal". AFAIK
> the only purpose of this library is to "hide" differences in
> implementations that are not covered by the standard.
You can't just open the process of change to only a set of known outcomes.
You mostly can just either open to editorial correction to arbitrary change
or nothing.
> I'm _not_ talking about bigger libraries. Erik Naggum made some good
> comments about that some time ago. What i mean is that it is less
> usefull to have a set of features in almost every lisp
> implementation when every implementation does it in their own way
> (i.e. FFI).
If you are a customer of the implementation that isn't meeting your
needs, complain to that vendor. If you are a customer, why isn't "I
need this" a stronger argument than "the standard requires this"
(which personally to me sounds like make-work). If you're not a
customer, why do you care (other than, again, make-work) whether some
vendor you don't use carries it? Yes, it might win the occasional debate
point to say CL had these features, but all useful CL's have these features
and you should just assert that fact anyway in a debate.
My bottom line points:
* I allege that these issues do not stand in the way of anyone
deploying a successful commercial product.
* I further allege that money which you want to go to these
things could better be used addressing vendor-specific issues
that do stand in the way of successful commercial products.
Marc Battyani
"Mr. Neutron" <nickts...@charter.net> wrote
> I can build rocket ships in my native tongue (C). Translating my rocket
> ship into Lisp results in a broken machine. I am missing doors, windows,
> glass, steering controls, landing gear, wings, and fuel. I have a
> complete toolbox in C. In Lisp, I just have a screwdriver.
Sigh... This subject comes so often here that we could think that there
exists people that know how to post to comp.lang.lisp but not how to use
google.
FYI here is a quote from message news:4wutlo...@beta.franz.com by Jor
Marshall
(with-quote
Item # 3021 - C Tool Belt Suggested Price $9.95 Our Price $6.50
A true classic, our C Tool Belt comes with all the tools you'll need
for fashioning quality software. Comfortable, natural material can
be draped around hips. Basic instruction manual includes directions
for making a buckle. Rock is made of genuine granite, the same material
used in many of the finest buildings in the world. Pointy stick has
built-in hardwood handle and may be used by left-handed or right-handed
people with equal ease.
Features: all hide construction
pocket for spare rock
holster for pointy stick
Spare rock sold separately. Not for sale to residents of
Massachusetts, California, or any other state with restrictions upon
ownership of rocks and/or pointy sticks.
Item # 5274 - Common Lisp Tool Belt Suggested Price $40,000. Our Price
$10,000.
Our Common Lisp tool belt is designed with the tinkerer in mind. The
three-axis Bridgeport Series I Standard Mill (included) is located
on the hip pocket for easy access, while the high-speed Intaglio
Printer is tucked away in the back for more convenient carrying.
Detachable GPS may be worn on wrist.
Features: dual cutting heads -- water jet and plasma
Computer Numerical Control interface
CRC Handbook, OED, PDR, and DSM IV included
in documentation
Item # 38661 - C++ Tool Belt Suggested Price $100.00 Our Price $69.95
Make a fashion statement with our modern C++ Tool Belt. Features
genuine synthetic rock and over 3,000 custom made pointy sticks so
you'll always have exactly the right tool for the job. Belt comes
with heavy duty buckles, zippers, velcro, buttons, hook and eye
fasteners, snaps, frogs (both the fastener and the amphibian), clasps,
sequins, lace trim, and mounting points for clip-on suspenders.
Expansion kits of pointy sticks available.
Features: trendy colors
pocket for spare rock
holster for pointy stick
Note: Synthetic rock should not be used in situations where it may
come into contact with other objects such as the pointy stick.
Synthetic rock composed of man-made materials, repeated use may cause
skin irritation or death.) ;*** note the parent nicely closing the
with-quote form ***
If you try goole with "group:comp.lang.lisp lisp better" you find 14500
messages.
The first 3 of these threads are :
Re: *Why* is LISP better?
comp.lang.lisp - 05 Aug 2002, posté par Erik Naggum - Afficher l'
arborescence (97 articles)
Re: How is Lisp "better"?
comp.lang.lisp.x - 28 Jul 1998, posté par Blake McBride - Afficher l'
arborescence (21 articles)
Re: Lisp better than C?
comp.lang.lisp - 25 Dec 1991, posté par U20...@uicvm.uic.edu - Afficher l'
arborescence (17 articles)
As you can see the last one is rather recent. So read before always asking
the same question.
I suggest that we make a few biased demos of lisp features for this kind of
question and then ask people to do the same in C[#,++], J[#,++,ava],
[J]Python, etc.
Marc
Christopher Browne
> Hi all,
> i changed the topic because i found that this now goes far away from the
> original thread. I'm not very experienced with Lisp history and when to
> introduce new stuff but i'm still wondering about that:
>
> Richard Krush wrote:
>>
>> According to the annual report for year 2000 from the committee [1],
>> there has been no active projects and generally the committee has been
>> falling apart.
>
>> [1] http://www.ncits.org/tc_home/j13.htm
>>
>> Here are some interesting quotes from the aforementioned web-site:
>>
>> "Membership was stable at eleven in 1999 and 2000, but 2001 paid renewals
>> may have fallen as low as three."
>>
>> "J13 continues with no active projects. There was one meeting during
>> 2000, conducted by electronic online chat."
> Why aren't there active projects ? At least multithreading and
> foreign function support are concepts that would be nice to have in
> the standard. And i think there are a lot of other topics too.
"Nice to have" does not mean that it's likely to actually happen.
>> "Despite the best of intentions and genuine interest in
>> standardizing areas of current development, no project proposals
>> have been generated. The Chair does not foresee any to be
>> immediately forthcoming."
> Is this process that complicated ? If i look at CLOCCs port library
> i find the first "proposal". AFAIK the only purpose of this library
> is to "hide" differences in implementations that are not covered by
> the standard.
> I'm _not_ talking about bigger libraries. Erik Naggum made some good
> comments about that some time ago. What i mean is that it is less
> usefull to have a set of features in almost every lisp
> implementation when every implementation does it in their own way
> (i.e. FFI).
For there to be a standards meeting costs a pile of people a pile of
money, because they have to see about getting together in one spot.
In order for the committee to start a meeting and then say "meeting
adjourned" more than likely costs $100K, and that's a meeting in which
NOTHING actually gets accomplished.
It is _vastly_ more likely that you'd find better value in working on
the "UFFI" project, more than likely by building/improving the binding
to one CL implementation or another. If you spent $100K on that,
you'd probably be able to get some meaningful improvements and make it
work with a goodly number of CL implementations.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www3.sympatico.ca/cbbrowne/rdbms.html
Zaphod's just zis guy, you know?
cr88192
>
>> if people don't care I have little reason to implement it...
>
> You have to do some `supply-side' thinking --- `build it and they will
> come'. Of course, you are taking the risk that you will build it and
> they'll stay away in droves. But if you win, you win really big.
>
maybe.
> If you decided to revive the T implementation, personally I'd
> definitely comment on it, and one part of my comment would be `thank
> you very much'.
>
t was pretty cool, and also a few details of my current scheme vm were
borrowed from t. now that I think of it though still substantial work is
needed on the vm, and maybe I should work more on making persistence work...
I could look into implementing t, and consider how much work it would be
for my current vm. allready many of the internals of my vm have been being
altered, however most of the changes were intended to make it more
general...
I was considering making a kind of "glue" interface to allow persistent
stuff to reference stuff generated at runtime, this would likely solve a
few problems of mine.
> But I found your language design really frustrating. You seemed to
> want to combine some aspects of Python, Scheme and Common Lisp. It
> didn't seem at all promising to me and I thought silence would be the
> most charitable response.
>
I had thought the mishmash aspect was a good point, oh well...
or was it the features from the various languages I had chosen?...
> You should realize that good self-image comes from accomplishment. If
> you do something good, you WILL become world famous. I kid you not.
> That's just the way the Internet is. You will get messages from all
> over the world either praising you or asking for free upgrades. :-)
>
yes, but accomplishment is the hard part. at present my most promising
project is my os, even though development has been slow recently.
my language would have been a branch of my vm, which is a branch of my os.
my vm is still cruddy, as an os involves plenty of other work as well...
> So you've got a lot of time on you hands: pick a project and see it
> through. Then put it out there. Repeat until satisfied.
>
maybe can do...
the simplest approach for me right now would be to continue using scheme
but probably add what stuff I was thinking on top.
the alternate syntax could be a different reader, though selecting which
reader to use might be difficult or kludgy. one idea is to select via a
command line option, or the file suffix. another option could be to have
reader and language configuration stuff embeded in comments, though
possibly this would be annoying...
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
Fred Gilham
I've been thinking recently that Mike McDonald deserves kudos, and
perhaps apotheosis, for his work on Free CLIM (aka McCLIM). I know
it's not finished yet, but IMHO it is usable by the adventurous.
(This is not to minimize the contributions of others who worked on
Free CLIM. The whole thing is amazing to me.)
I recently had occasion to want to experiment with the graph stuff in
CLIM. I noticed that it wasn't in the Free CLIM I'd checked out, so I
did a CVS update, and lo and behold, there it was, about 90%
functional too! :-)
--
Fred Gilham gil...@csl.sri.com
When an economist criticizes any human institution because it has
failed to convey to mankind an incommunicable attribute of God, we can
safely dismiss that economist. The trouble is, there remains a market
for these economists in academia. I regard this fact as one more piece
of evidence for the failure of tax-subsidized education. -- Gary North
news.verizon.net
http://www.paulgraham.com/icad.html. Even if you don't agree you will see
why we like Lisp.
Regards,
John
"Mr. Neutron" <nickts...@charter.net> wrote in message
news:pan.2002.08.25.07....@charter.net...
> Hi,
> I don't want to start a religious war. I am on my travels through
> learning computing, and wanting to explore the universe of Computer
> Science. This is just my opinions of Lisp so far.
>
> I have learned the very basics of Lisp. It is in my opinion a weird
> language. It uses strange named operators (car...) and lots of (() ).
> I am left witha very superficial look at what appears to be a retro
> language, a throwback to a time when computers were the size of
> buildings. It is hard to think in Lisp or what I can use it for.
>
> I can not imagine why I should keep trying to program in this language
when I have
> better, easier modern languages with a cleaner syntax and operators with
> names that make sense to me. SO far everything I understand I can do in
> Lisp I can just as well do in another language I know. I know not the
> ways of Lisp or what it is about that has enabled it survive this long.
>
> So far the only thing I have learned to do with Lisp is make a stack
> using a very strange syntax. I could easily code this same problem in
> Python or C or Java much faster and easier to read (to me).
>
> What oh what makes Lisp or Scheme useful? Are they just hacker languages
> that a hacker must know to be accepted by the hacker community? Or is
> there really something about Lisp (or Scheme) that makes them stand apart
> from the easier (IMO) to understand languages like Python, Java or C/C++?
>
> How has Lisp survived through the years? I have come across many many
> computer languages in my studies, and the majority of them died before
> they were even conceived. Yet Lisp, Fortran, and C survived. I know C and
> Fortran. They are not too hard to understand. But Lisp is IMO very hard to
> understand (first, everything is literally backwards in it...).
>
> I would like to learn how to program in Lisp, so I can appreciate
> something of the history of Computer Science. I am also interested
> in understanding Lisp, because I have read that it teaches you to think
> about problems recursively. But I am still struggling to figure out how
> to write an interesting program in the language.
>
> If you can explain to a neophyte Computer Scientist why learning to code
> in Lisp will enlighten me and will be worth the pain of getting
> acquainted with it, I'd like to know!
>
> Also are there any free e-books on programming in Lisp or Scheme?
> Are there any places I can get Lisp (or Scheme) code so I can look at to
> learn how to think in these languages?
>
> I am still interested in the way of Lisp and Scheme so I am not closed to
> learning about it. But my only experience with it is a funny taste. It is
> completely opposite of how I think and I can not think at all in this
> language. I just stare at the clisp prompt wondering what I should do
> next. I can write simple programs that process a list, but it is a toy.
> There must be more to it than just making toys.
>
> hehe.
>
> Thanks
Adam Warner
>> It's not weird at all. In C (and many similar languages), there are a
>> lot of different "syntax embellishments" to actually help reading. LISP
>> uses only parentheses. This makes it very easy to parse by a computer,
>> but not by (mant? most?) humans.
>
> Well, the argument is that in Lisp, eventually you don't `see' the
> parentheses --- the mind filters them out as irrelevant to understanding
> what's going on. Then you just start reading code in a literal sense.
> The syntax embellishments aren't necessary.
Yes, you can rely upon an editor's automatic indenting to let you see
whether parentheses are out of place without needing to explicitly count
them.
Furthermore the spare characters like [ ] { } come in really handy when
implementing reader macros.
Regards,
Adam
Donald Fisk
>
> In article <umi9336...@corp.supernews.com>, cr88192 wrote:
> > Kaz Kylheku wrote:
> >> Nobody cares about the braindamaged spec for your nonexistent language, so
> >> stop
> >> bringing it up, you lunatic. It's not topical here. Maybe try the
> >> patience of comp.compilers for a change.
> >
> > hell, at least this is some feedback.
> > if others feel similar I guess it explains the lack of reply.
> >
>
Since when? As far as I'm aware, it's for any kind of Lisp
except Scheme, which has its own group, and maybe Emacs Lisp and
AutoLisp for the same reason.
I've posted stuff on MacLisp here not so long ago. Sosumi. And
if Paul Graham or anyone else wants to post Arc stuff here for
general discussion, he's welcome to, at least until Arc gets its
own group.
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Donald Fisk
> So far, the willingness to listen does not even extend to Paul Graham's Arc.
> Novices with a desire to reinvent the world before they know what it is like
> should take notice of this. Improving on Common Lisp is /very/ hard. And
> most of the "improvements" on Scheme are neither improvements nor Scheme.
Agreed. Common Lisp is the best language we have.
It even bothers me that people are busy inventing new languages
which are clearly inferior to existing ones in all important
aspects.
This is not to say that people shouldn't try, but that they should
bear in mind that if they cannot claim their language is better
than Common Lisp (or at least a useful subset of it) in at least
one important way, maybe they should keep it to themselves. It
isn't needed, and there are too many languages already.
And language designers should be able to program in numerous
quite different languages, and should maybe cut their teeth by
designing a few special purpose languages, as I have done.
This doesn't prevent people inventing languages which aren't
as good as Lisp -- False was worth inventing, to show what could
still be done even if you limit your compiler size to one
kilobyte, for example.
> Erik Naggum, Oslo, Norway
Donald Fisk
>
> In article <pan.2002.08.25.07....@charter.net>, Mr. Neutron
> wrote:
> > language. I just stare at the clisp prompt wondering what I should do
> > next. I can write simple programs that process a list, but it is a toy.
> > There must be more to it than just making toys.
>
> language. If you can't think of what to do, it can only be because you have
> reached your wit's end.
>
> You should go back to one of those programming languages that you cited; these
> will give you enough impedance so that you can push against them and dissipate
> your energy to create the feeling that you are accomplishing something.
>
> C is great for this; you can start with no idea at all, and starting writing
> thousands of lines of supporting code in hopes that the idea will materialize
> in the meanwhile.
>
> ``Gee, I don't know what I will write, but I bet it will need a linked list, a
> better malloc routine, some binary trees and reference-counted strings,
> a buffer management module, ...''
BTDT. Implemented in C (for my last employer) a library containing
heap
management, (singly, as God intended) linked lists, side-effect free
functions for C's ASCIZ strings, hash tables and a better interface
to Regex.h
This saved me lots of effort.
Greenspun's tenth rule in action, but at least, having implemented
Lisp several times previously, I knew how to do it properly.
Donald Fisk
> I would like to learn how to program in Lisp, so I can appreciate
> something of the history of Computer Science. I am also interested
> in understanding Lisp, because I have read that it teaches you to think
> about problems recursively. But I am still struggling to figure out how
> to write an interesting program in the language.
I was for many months trying to think of an interesting program
to write in Fortran, because number crunching didn't interest me.
Then I discovered Artificial Intelligence. I was soon pointed
in the direction of Lisp and never looked back.
Almost all programs written nowadays could just as well be
written in COBOL, Fortran, or something similar. Most programming
problems are deadly dull, and you don't need Lisp for these. AI
is a different matter -- nothing suffices except Lisp or Prolog.
So look for a problem that you cannot solve easily in your favourite
languages and try Lisp on it.
> If you can explain to a neophyte Computer Scientist why learning to code
> in Lisp will enlighten me and will be worth the pain of getting
> acquainted with it, I'd like to know!
>
> Also are there any free e-books on programming in Lisp or Scheme?
> Are there any places I can get Lisp (or Scheme) code so I can look at to
> learn how to think in these languages?
Paul Graham's On Lisp, and if you want Scheme there's SICP.
> I am still interested in the way of Lisp and Scheme so I am not closed to
> learning about it. But my only experience with it is a funny taste. It is
> completely opposite of how I think and I can not think at all in this
> language. I just stare at the clisp prompt wondering what I should do
> next. I can write simple programs that process a list, but it is a toy.
> There must be more to it than just making toys.
This is because you're having to think up (Lisp is higher level than
C or Java). I had the same problem with Prolog, which is higher level
than Lisp, but I persevered, and after heavy use grokked it.
> Thanks
Kaz Kylheku
wrote:
> glass, steering controls, landing gear, wings, and fuel. I have a
> complete toolbox in C. In Lisp, I just have a screwdriver.
What toolbox would that be?
The one with strcat and strcpy?
Or the one with malloc and free?
sort and bsearch?
setjmp and longjmp?
Are you aware that Lisp has an object oriented programming system, dynamic
typing, complex numbers, bignum integers, rational numbers, packages,
structural macros, lexical closures, restartable conditions, a sequence
processing library, strings, symbols, vectors, multidimensional arrays,
structs, packages, sophisticated stream I/O, built-in parser and evaluator, ...
Get real.
>
> That is my frustration with Lisp so far. I can build rockets. But in Lisp
> I am starting all over again. It is sort of intimidating. I am actually
> kind of interested in the challenge. But I need a guide to teach me.
> I just can't find a guide. It would be nice if there was a Lisp for C
> programmers book around.
>
> That's why I am griping. It's not that I think Lisp sucks. It is that I
> can not communicate in it at all. I am a stranger in a strange land in
> Lisp.
>
> Bye
--
Kaz Kylheku
wrote:
> things can be fixed in an entirely backward compatible way, for
> example
> allowing arrays to be assigned and returned from functions, or
> allowing
Ewww. That's what you get for trying out Google news posting. The preview
looks normal, then the lines break when you actually post.
Let me guess, Perl? ;)
Kaz Kylheku
> On 25 Aug 2002 17:50:31 -0700, larry...@hotmail.com (larry) wrote:
>
>>"Mr. Neutron" <nickts...@charter.net> wrote in message news:<pan.2002.08.25.07....@charter.net>...
>>>> It uses strange named operators (car...) and lots of (() ).
>>
>>Why do people coming to lisp complain about all the parenthesis?
>>Take c code, change { } to parenthesis and move the position a little and
>>you get something like
>>
>>(for (i=0;i<10;i++)
>> (for (j=0;j<10;j++)
>> (if i == j
>> (printf "i =j\n");
>> (printf "i not j\n");
>> )
>> )
>>)
>>
>>That looks just like lisp, but nobody notices it because they're used to seeing
>>it. What about all the damn semi-colons in c-- weird.
>
> It's not weird at all. In C (and many similar languages), there are a
> lot of different "syntax embellishments" to actually help reading.
I have 13 years of C under my belt. 1.5 years of Lisp. I find Lisp code easier
to read. And of course not to mention that reading 100 lines of Lisp can mean
absorbing the semantic equivalent of 10,000 lines of C.
> LISP uses only parentheses. This makes it very easy to parse by a
> computer, but not by (mant? most?) humans.
>
> In your example above you didn't go all the way. You should also have
> removed all semicolons and replace them with parentheses, etc.
Cruft like semicolons and commas is largely replaced by whitespace. C needs the
extra punctuation because of the infix syntax with unary operators. If you had
a function call like
printf("%d %d\n" i ++ j)
what would that mean? Does the ++ go with the i or j? Okay in Lisp we would
have parentheses, (incf j). But in C you need the damn commas among the
argument expressions whether or not the ambiguity exists in the particular
expression you are writing.
> Making
> everything look the same has lots of advantages, but some
> disadvantages. The equivalent C code would look like:
>
> for ( i=0; i<10; i++ )
> for ( j=0; i<10; j++ )
> if (i==j)
> printf( "i=j\n" );
> else
> printf( "i not j\n" );
In Lisp I can make a do-nested-times macro that will express the nested looping
idiom concisely:
(do-nested-times ((i 10) (j 10))
...)
This would certainly be worth it if I had lots of such nested
loops in the code.
The macro would be smart enough to generate a loop with any number
of levels of nesting:
(do-nested-times ((i-1 10) (i-2 10) (i-3 20) ... (i-n 9))
...)
You can do a few simple things with C macros, but they quickly run out of
steam. First you give up hygiene, then you just give up.
> This is a very mild example, BTW. In C++ and C99, for example,
> variable definitions (although properly nested) don't have to be
> defined at the beginning of scope.
Whoa, sheer progress! From 1969 all the way to, oh, 1975.
> The following C++ program would
> look like parentheses soup in LISP:
>
> {
> File reader( ... parameters... );
> ...do something with reader...
> File writer( ... parameters... );
> ...do something with both reader and writer...
> }
Now try this:
File reader (...)
goto label;
File writer (...)
label:
...
Oops, can't skip declarations, better make it:
File reader (...);
goto label;
{
File writer (...);
}
label:
> In LISP, you either have to group all these declarations in a single
> let-like expression (assuming the semantics of your algorithm allow
In Lisp, you don't ``have to'' anything. You can compile C++
notation, if you are sufficiently disturbed to actually want it.
It's languages like C++ that force you into ``have to'' situations,
so you have learned that programming languages are operated
by submission.
> it), or open more and more explicit scopes, which make reading more
> and more difficult.
(with-open-file (in-stream pathname :direction :input)
.. do something with stream ..
(with-open-file (out-stream pathname :direction :output)
... do something with both streams
...))
These scopes make reading easier, because you know exactly what is subordinate
to what.
Anyway, you can make a binding construct which does this kind of flattening:
(special-let ((var1 init-form-1 ... forms working with var1)
(var2 init-form-2 ... forms working with var1 and var 2)
...))
Perhaps the third parameter of each binding could specify
some finalization form that is evaluated no matter how the
whole block terminates, in reverse order of the definitions:
(special-let ((in-stream (open ...) (close in-stream) ...)
(out-stream (open ...) (close out-stream) ...))
...)
In this way you could work with any number of streams without
increasing the level of nesting.
Actually a better design would be to get rid of the final forms
body, since you don't need it. Then you can get rid of one
level of parenthesizing:
(special-bind
(in-stream (open ...) (close in-stream) ...)
(out-stream (open ...) (close out-stream) ...))
I might put back some nesting to reduce errors, and make
the initialization and finalization expressions optional:
(special-bind
((in-stream (open ...) (close in-stream)) ...)
((out-stream (open ...) (close out-stream)) ...))
Note how this vaguely resembles the syntax of the COND form.
Ziv Caspi
<gil...@snapdragon.csl.sri.com> wrote:
>> It's not weird at all. In C (and many similar languages), there are
>> a lot of different "syntax embellishments" to actually help reading.
>> LISP uses only parentheses. This makes it very easy to parse by a
>> computer, but not by (mant? most?) humans.
>
>Well, the argument is that in Lisp, eventually you don't `see' the
>parentheses --- the mind filters them out as irrelevant to
>understanding what's going on. Then you just start reading code in a
>literal sense. The syntax embellishments aren't necessary.
I don't buy that argument. I both wrote LISP apps and read LISP apps
for quite some time. In many cases, having just written a function,
I'd read it back (always a good practice for catching bugs early),
only to find out that reading was more difficult then writing. I have
experience in other languages as well (Fortran, C/C++, x86 assembler,
and Pascal). The only other language I had a similar experience is RPL
(what you find in some HP calculators, such as their 28 series).
Your experience (and everybody else's on this newsgroup, apparently)
might certainly be different. But for me, LISP was not the "last
language" (to quote someone on this newsgroup) -- I switched to C++
and later to C#. For me, LISP always had almost everything I wanted in
a programming language (real macros, CG, edit-and-continue-debugging,
natural reflection and serialization, multi-dispatch). What it doesn't
have, unfortunately, is a syntax I can live with.
Ziv
Alain Picard
> As I understand it symbols have a number of properties associated with
> them. It would be nice if one of those properties was information about
> the original case of the symbol
Such information _is_ kept; it is in the symbol's name.
e.g.
Starting /usr/bin/lisp ...
CMU Common Lisp release x86-linux 3.0.8 18c+ 31 December 2001 build 3030, running on gondolin
* (symbol-name '|Foo|)
"Foo"
*
Erik Naggum
| But for me, LISP was not the "last language" (to quote someone on this
| newsgroup) -- I switched to C++ and later to C#.
Why is it important to you to argue against this? Did I somehow fail to make
it clear that it applied to /many/ people, as opposed to /all/ that would
make it legitimate to object? Do you have any new information other than
what we already know? What do you wish to accomplish with your posts?
| What it doesn't have, unfortunately, is a syntax I can live with.
So write your own parser that produces s-expressions. But you have not even
tried to adapt to the language or adapt it to yourself, have you? Why is it
so important to you write about your unhappiness with both languages and
other people's opinions and statements? Perhaps you should try to find
something you /can/ live with if you are so unhappy with Lisp and this forum?
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Andreas Hinze
>
> I personaly think ANSI is a large, too-slow, not-very-useful entity to
> be accomodating all but the most low-level basic standards. It was
> probably appropriate to standardize CL itself this way, but even then
> it's quite clear that the long time-line caused by ANSI resulted in
> some companies going bankrupt in the meanwhile. Was ANSI the cause?
> Probably not. But did producing an ANSI standard cost a serious lot of
> money on the part of all Lisp vendors? Yes.
>
> Users love to point to things like this because they want everything on a
> silver platter if they can get it, but the cost of getting this silver platter
> is high enough that the rough edges present will buy you more in terms of
> other things vendors could provide.
Right. I was only looking for the advantages of further standardisation
without thinking about the costs.
Your explaination give me a new sight to the hole topic. I didn't realize the
problems behind that hole process. Thanks for your patient explanations.
Sincerly
AHz
Tim Bradshaw
> Such information _is_ kept; it is in the symbol's name.
No, it isn't. What he wants is something like:
(symbol-original-name 'Foo) -> "Foo"
--tim
Hannah Schroeter
>(symbol-original-name 'Foo) -> "Foo"
(setf (readtable-case *readtable*) :preserve)
or
(setf (readtable-case *readtable*) :invert)
The latter is useful if you don't want to CRY OUT THE STANDARD
SYMBOL NAMES:
* (symbol-name 'foo)
"FOO"
* (symbol-name 'FOO)
"foo"
* (symbol-name 'Foo)
"Foo"
What would you refer to as original name in the case:
(mapcar #'symbol-original-name (list 'foo 'Foo 'FOO))
in your example, if you wanted to map 'foo, 'Foo and 'FOO to the
same symbol objects?
Kind regards,
Hannah.
Ziv Caspi
<k...@ashi.footprints.net> wrote:
[...]
>Cruft like semicolons and commas is largely replaced by whitespace.
Yes, that's the point. Commas, semicolons, parens, braces in C provide
a larger diversity than parens and whitespace alone. This makes it
more difficult to parse, much more difficult (if not impossible) to do
the type of things people use LISP macros for, etc. But it also makes
it easier on the human eye to read.
>> for ( i=0; i<10; i++ )
>> for ( j=0; i<10; j++ )
>> if (i==j)
>> printf( "i=j\n" );
>> else
>> printf( "i not j\n" );
>
>In Lisp I can make a do-nested-times macro that will express the nested looping
>idiom concisely:
>
> (do-nested-times ((i 10) (j 10))
> ...)
>
>This would certainly be worth it if I had lots of such nested
>loops in the code.
I completely agree (here and elsewhere) that many C constructs can be
written much more concisely and cleanly in LISP. This is not the point
of the argument I'm making.
[...]
>Now try this:
>
> File reader (...)
> goto label;
> File writer (...)
>label:
> ...
>
>Oops, can't skip declarations, better make it:
>
> File reader (...);
> goto label;
> {
> File writer (...);
> }
>label:
I don't understand your point. My example was meant to show that the
scope introduced when a variable is declared can be "hidden" in C/C++,
which makes it easier to read. The fact that sometimes you want to
terminate that scope early -- and so you must make it explicit --
doesn't go against my point.
>> In LISP, you either have to group all these declarations in a single
>> let-like expression (assuming the semantics of your algorithm allow
>
>In Lisp, you don't ``have to'' anything.
Of course. I made a bad choice of words. Your examples on the type of
syntax transformations one can do in LISP, however, don't contradict
my point, as far as I can see.
[...]
Adam Warner
> Hello!
>
> Tim Bradshaw <t...@cley.com> wrote:
>>* Alain Picard wrote:
>>> Such information _is_ kept; it is in the symbol's name.
>
>>No, it isn't. What he wants is something like:
>
>>(symbol-original-name 'Foo) -> "Foo"
>
> (setf (readtable-case *readtable*) :preserve)
>
> or
>
> (setf (readtable-case *readtable*) :invert)
>
> The latter is useful if you don't want to CRY OUT THE STANDARD SYMBOL
> NAMES:
>
> * (symbol-name 'foo)
>
> "FOO"
> * (symbol-name 'FOO)
>
> "foo"
> * (symbol-name 'Foo)
>
> "Foo"
I can assure you Hannah that Tim and I understand this. The :invert mode
still breaks code that contains non lowercase characters (you "shout" or
capitalise a function name anywhere and the code is broken). Moreover it
does exactly what I was proposing to avoid (the breaking of a lot of
legacy code).
I have no idea whether Tim thought the idea had any merit. I'm just glad
he and you got the point.
> What would you refer to as original name in the case:
>
> (mapcar #'symbol-original-name (list 'foo 'Foo 'FOO))
>
> in your example, if you wanted to map 'foo, 'Foo and 'FOO to the same
> symbol objects?
Ah. Thank you for exposing this nice mapping problem. You're a good
teacher. Perhaps the idea is already broken beyond repair. I would define
the original name as the last case information read by the reader for any
particular symbol at the time the expression is evaluated (but how would
this work for compiled code?)
The answer to your example would be ("FOO" "FOO" "FOO"). (list 'foo 'Foo
'FOO) is first evaluated. "foo" is first associated with the symbol FOO.
Then this is replaced with "Foo". Finally "FOO" is associated with the
symbol FOO. Mapping symbol-original-name onto a list of the same symbols
would lead to the same string being returned each time.
This would break all kinds of identity as (list (symbol-original-name
'foo) (symbol-original-name 'Foo) (symbol-original-name 'FOO)) would
return ("foo" "Foo" "FOO") compared to the mapcar example.
Another problem is that since case sensitive modes generate different
symbols then your example would generate ("foo" "Foo" "FOO") whenever a
case sensitive mode was in use.
Regards,
Adam
Adam Warner
>> What would you refer to as original name in the case:
>>
>> (mapcar #'symbol-original-name (list 'foo 'Foo 'FOO))
>>
>> in your example, if you wanted to map 'foo, 'Foo and 'FOO to the same
>> symbol objects?
>
> Ah. Thank you for exposing this nice mapping problem. You're a good
> teacher. Perhaps the idea is already broken beyond repair. I would
> define the original name as the last case information read by the reader
> for any particular symbol at the time the expression is evaluated (but
> how would this work for compiled code?)
>
> The answer to your example would be ("FOO" "FOO" "FOO"). (list 'foo 'Foo
> 'FOO) is first evaluated. "foo" is first associated with the symbol FOO.
> Then this is replaced with "Foo". Finally "FOO" is associated with the
> symbol FOO. Mapping symbol-original-name onto a list of the same symbols
> would lead to the same string being returned each time.
>
> This would break all kinds of identity as (list (symbol-original-name
> 'foo) (symbol-original-name 'Foo) (symbol-original-name 'FOO)) would
> return ("foo" "Foo" "FOO") compared to the mapcar example.
>
> Another problem is that since case sensitive modes generate different
> symbols then your example would generate ("foo" "Foo" "FOO") whenever a
> case sensitive mode was in use.
Scratch that. A large and more satisfying simplification would be the
original text being associated with any individual symbol name the first
time it is met by the reader (perhaps until the associated text is
explicitly destroyed).
So (mapcar #'symbol-original-name (list 'foo 'Foo 'FOO)) would generate
("foo" "foo" "foo") because "foo" was first associated with the symbol
name FOO.
(list (symbol-original-name 'foo) (symbol-original-name 'Foo)
(symbol-original-name 'FOO)) would also generate ("foo" "foo" "foo")
because "foo" was associated with the symbol FOO the first time it was
read by the Lisp Reader.
There would still be a difference with case senstive reader modes--but
there is always a difference when symbols have a different case in case
sensitive reader modes.
The idea would seem to require the string information for each unique
symbol to be retained forever (unless explicitly destroyed).
Regards,
Adam
Adam Warner
>> What would you refer to as original name in the case:
>>
>> (mapcar #'symbol-original-name (list 'foo 'Foo 'FOO))
>>
>> in your example, if you wanted to map 'foo, 'Foo and 'FOO to the same
>> symbol objects?
>
> Ah. Thank you for exposing this nice mapping problem. You're a good
> teacher. Perhaps the idea is already broken beyond repair. I would
> define the original name as the last case information read by the reader
> for any particular symbol at the time the expression is evaluated (but
> how would this work for compiled code?)
>
> The answer to your example would be ("FOO" "FOO" "FOO"). (list 'foo 'Foo
> 'FOO) is first evaluated. "foo" is first associated with the symbol FOO.
> Then this is replaced with "Foo". Finally "FOO" is associated with the
> symbol FOO. Mapping symbol-original-name onto a list of the same symbols
> would lead to the same string being returned each time.
>
> This would break all kinds of identity as (list (symbol-original-name
> 'foo) (symbol-original-name 'Foo) (symbol-original-name 'FOO)) would
> return ("foo" "Foo" "FOO") compared to the mapcar example.
>
> Another problem is that since case sensitive modes generate different
> symbols then your example would generate ("foo" "Foo" "FOO") whenever a
> case sensitive mode was in use.
Scratch that. A large and more satisfying simplification would be the
original text being associated with any individual symbol name the first
time it is met by the reader (perhaps until the associated text is
explicitly destroyed).
So (mapcar #'symbol-original-name (list 'foo 'Foo 'FOO)) would generate
("foo" "foo" "foo") because "foo" was first associated with the symbol
name FOO.
(list (symbol-original-name 'foo) (symbol-original-name 'Foo)
(symbol-original-name 'FOO)) would also generate ("foo" "foo" "foo")
because "foo" was associated with the symbol FOO the first time it was
read by the Lisp Reader.
There would still be a difference with case sensitive reader modes--but
there is always a difference in such modes when symbols differ by case.
Plus the functionality would be pointless.
Paolo Amoroso
wrote:
> I've been thinking recently that Mike McDonald deserves kudos, and
> perhaps apotheosis, for his work on Free CLIM (aka McCLIM). I know
> it's not finished yet, but IMHO it is usable by the adventurous.
>
> (This is not to minimize the contributions of others who worked on
> Free CLIM. The whole thing is amazing to me.)
I second that. The flow of CVS commit logs is a refreshing breeze. Kudos to
the McCLIM team.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Kaz Kylheku
> I both wrote LISP apps and read LISP apps
> for quite some time.
Was it Common Lisp? When was this? It must have been back in the
dark ages when the name of the language was still spelled in all
capitals.
> Your experience (and everybody else's on this newsgroup, apparently)
> might certainly be different. But for me, LISP was not the "last
> language" (to quote someone on this newsgroup) -- I switched to C++
> and later to C#.
You are on a path which will soon encounter Visual BASIC, COBOL and
Intercal, probably in that order. ;)
Anyway, it's clear that you didn't grok Lisp, if you still think
that Lisp sticks you with one way of expressing yourself that
you ``have to'' follow.
In the end, everyone deserves the tool they end up with.
> For me, LISP always had almost everything I wanted in
> a programming language (real macros, CG, edit-and-continue-debugging,
If you know what real macros are, why do you make stupid claims
about Lisp having a fixed syntax which forces you do to things one
way, such as to keep nesting deeper and deeper if you want to
introduce a series of lexical variables which refer to earlier
lexical variables, and have code interspersed in between?
It looks like you are cutting and pasting Lisp trivia from some
document to make it seem as if you actually know the language,
so that you could write more subtle trolls.
I can do the same; I know next to nothing about, say, Eiffel, but I
can cut and paste trivia from FAQ's, web pages other sources. Then
go to comp.lang.eiffel and claim that I spent years using
Eiffel, and have always wanted a language with these features.
Oh, but I couldn't stand some little detail, so I switched
to Perl and life was perfect after that! :)
> natural reflection and serialization, multi-dispatch). What it doesn't
> have, unfortunately, is a syntax I can live with.
It can support any syntax you want. For example one well-known,
portable Common Lisp module you can find on the net lets you
write expressions like
f(a[++i], b + c/d)
which might translate to
(f (aref a (incf i)) b (/ c d))
Maybe the Lisp that you used didn't have reader macros, or you
didn't know about them?
Thomas F. Burdick
> Scratch that. A large and more satisfying simplification would be the
> original text being associated with any individual symbol name the first
> time it is met by the reader (perhaps until the associated text is
> explicitly destroyed).
>
> So (mapcar #'symbol-original-name (list 'foo 'Foo 'FOO)) would generate
> ("foo" "foo" "foo") because "foo" was first associated with the symbol
> name FOO.
So basically you want a case-insensitive but case-preserving reader.
FWIW, that does sound like a nice thing. I've had a new-to-me Mac for
a couple weeks now, and that's one thing I'm loving about its
filesystem. If I "touch Foo", the file's called "Foo", and if I
"cat foO", "cat FOO", and "cat foo", I get the contents of the file
"Foo". I think that's about as close as the machine can get to doing
what I mean in this situation.
> The idea would seem to require the string information for each unique
> symbol to be retained forever (unless explicitly destroyed).
Well, it already is. The only way the Lisp system is allowed to
forget a symbol's name is if you unintern it and lose all references
to it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Erik Naggum
| Scratch that. A large and more satisfying simplification would be the
| original text being associated with any individual symbol name the first
| time it is met by the reader (perhaps until the associated text is
| explicitly destroyed).
What would happen to (defstruct foo ...)? Would you have MAKE-foo or
make-foo?
I have spent many hours working on various ways to make a case-preserving,
lower-case Common Lisp work according to the standard, but I find myself
stumped by macros that generate symbols by "concatenating" input symbols
with symbols of its own making. I have come to believe that this should be
avoided at all cost, including writing out the symbols created by defstruct
in full. You see, what I want is for `intern´ and `symbol-name´ to use
lower-case symbol names when I throw a switch, but if I also want a case-
preserving reader, what comes out of defstruct is probably MAKE-foo. To
make this work, macros that call intern need to capture the state of the
flag that modifies how `intern´ and friends work so that they would do the
right thing as the macro writer intended when it was compiled. This is
pretty messy, so I have not taken then idea any further.
| The idea would seem to require the string information for each unique
| symbol to be retained forever (unless explicitly destroyed).
Why do you think this is not how things work today?
Marco Antoniotti
Paolo Amoroso <amo...@mclink.it> writes:
> On 26 Aug 2002 17:02:34 -0700, Fred Gilham <gil...@snapdragon.csl.sri.com>
> wrote:
>
> > I've been thinking recently that Mike McDonald deserves kudos, and
> > perhaps apotheosis, for his work on Free CLIM (aka McCLIM). I know
> > it's not finished yet, but IMHO it is usable by the adventurous.
> >
> > (This is not to minimize the contributions of others who worked on
> > Free CLIM. The whole thing is amazing to me.)
>
> I second that. The flow of CVS commit logs is a refreshing breeze. Kudos to
> the McCLIM team.
Have not followed that recently. What is the status of presentation
types under McCLIM?
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Kaz Kylheku
> On Tue, 27 Aug 2002 07:02:32 +0000 (UTC), Kaz Kylheku
> <k...@ashi.footprints.net> wrote:
> [...]
> >Cruft like semicolons and commas is largely replaced by whitespace.
>
> Yes, that's the point. Commas, semicolons, parens, braces in C provide
> a larger diversity than parens and whitespace alone. This makes it
> more difficult to parse, much more difficult (if not impossible) to do
> the type of things people use LISP macros for, etc. But it also makes
> it easier on the human eye to read.
Can you cite any studies which confirm this? When I was a C newbie,
the code resembled modem line noise to me. Maybe you have forgotten
your first encounters with C.
What is harder to parse for the computer is harder for the human.
There are no algorithmic shortcuts for parsing that are available
to the human brain. Sorting out associativity and precedence in
a an expression takes work, whether you are man or machine.
Note that neither Lisp nor C is easy to read for a human without
indentation. We actually read indentation as the major clue to the
program's structure. Formatting is a big deal. There is no consistent
way to format all of the constructs of C.
I cringe every time I have to split a long for(;;) across multiple
lines. Or a long expression.
In Lisp we can write nice things like:
(or (and (and (condition1 ...)
(or (condition2 ...)
(not (condition3 ...))))
(not (or condition4 condition5)))
(and condition6 condition7 condition8))
Now what do we do in C to format it sanely? Okay, the major
constituent
is or, but in infix, that will land in the middle of the long
expression
somewhere. Instead the expression begins with the leftmost node.
((condition1(...) && (condition2(...) || !condition3(...))
&& !(condition4 || condition5)) || condition6 && condition7 &&
condition8
How can we break that in a sane way? In the formatted Lisp version,
I can visually check the balance of the parentheses thanks to the
canonical formatting. I'd like it to be obvious that the expression
has two major constituents coupled by ||.
In Lisp, the frustration is gone. You just follow a simple algorithm
that an idiot can learn in five minutes, and your expression is
formatted sanely.
I don't follow your claim that a wider diversity (C has a 90 member
character set which uses nearly all of the symbols in the ASCII
character set for some kind of punctuation, with the exception of
@ and $) leads to improved readability. More symbols just means more
memorizing. There has to be some optimal alphabet size for human
readability; 90 characters is probably too much, whereas two symbols
(binary code) is too little.
I fail to see how flattening everything and hiding information
makes it easy to read. The reader now has to compute the scope from
semantic information, with no visual clues. If you had a lot of these
objects, it would become quite hard to sort out where the scopes
begin.
The writer might be tempted to use indentation to cache the scope
information in a simple visual clue:
File reader (...)
File writer (...)
> terminate that scope early -- and so you must make it explicit --
> doesn't go against my point.
The point is that the C++ paradigm breaks with an innocuous little
change.
> >> In LISP, you either have to group all these declarations in a single
> >> let-like expression (assuming the semantics of your algorithm allow
> >
> >In Lisp, you don't ``have to'' anything.
>
> Of course. I made a bad choice of words. Your examples on the type of
So correct it; what would have been the *right* choice of words?
> syntax transformations one can do in LISP, however, don't contradict
> my point, as far as I can see.
Sure they do, because even if you don't like the syntax, the point is
that you can reduce it to fit your abstractions. And that's what
ultimately
makes the code readable and maintainable.
What is the C equivalent of, say, (score c d e f g a b (high c)) to
render a musical staff containing the ascending major scale? What
would it look like, if you could design the nicest possible C library
interface for it? Let me guess, an ad-hoc interpreter that parses
notation embedded in a string.
Tim Moore
>
>Paolo Amoroso <amo...@mclink.it> writes:
>
>> On 26 Aug 2002 17:02:34 -0700, Fred Gilham <gil...@snapdragon.csl.sri.com>
>> wrote:
>>
>> > I've been thinking recently that Mike McDonald deserves kudos, and
>> > perhaps apotheosis, for his work on Free CLIM (aka McCLIM). I know
>> > it's not finished yet, but IMHO it is usable by the adventurous.
>> >
>> > (This is not to minimize the contributions of others who worked on
>> > Free CLIM. The whole thing is amazing to me.)
>>
>> I second that. The flow of CVS commit logs is a refreshing breeze. Kudos to
>> the McCLIM team.
>
>Have not followed that recently. What is the status of presentation
>types under McCLIM?
The implementation of presentation types is pretty complete. We
haven't written some accept methods yet, don't have presentation
histories (really as much an input editor issue as a presentation type
issue) and don't implement the non-rectangle sensitivity testing and
highlighting described in the spec, but otherwise not much is
missing.
Tim
Erik Naggum
| Yes, that's the point. Commas, semicolons, parens, braces in C provide
| a larger diversity than parens and whitespace alone. This makes it
| more difficult to parse, much more difficult (if not impossible) to do
| the type of things people use LISP macros for, etc. But it also makes
| it easier on the human eye to read.
This, is, a, (curious), position, to, hold. The, amount, of, [punctuation],
in, (normal, writing), is, pretty, low, and, { ensures; }, that, punctuation,
has, meaning; [distinct] from the normal { flow; } of the language. In, C,
the, [punctuation], is, so, { heavy }, that, the, reader, [must], pay, acute,
{ attention; }, to, it, even, though, it, is, (largely), meaningless. This,
is, not, [easier], to, read, as, this, paragraph, should, be, have, [shown],
you. When, an, { assortment; }, of, punctuation, is, made, into, background,
{ noise; }, the, result: is, that; people, become, [hypersensitized], to();
changes, in, the, punctuation, they, have, to, (read && would), reject, any,
languages, with, a, simpler, syntax && other, punctuation, to, ignore.
If you have become used to C, the empirical evidence is that you have a very
hard time reading languages with other syntaxes. This is prima facie
evidence that the C syntax family requires an expensive learning process and
constant refreshes. I found myself frustrated when I tried to write a
couple hundred lines of C recently to exercise some Linux features and make
them available to Common Lisp (particularly the dnotify facility) and all
the keyboarding was just /painful/ compared to the swift typing that I
usually achieve with Common Lisp and English.
| My example was meant to show that the scope introduced when a variable is
| declared can be "hidden" in C/C++, which makes it easier to read.
Where /did/ you get the notion that "easier to read" is universalizable and
one-dimensional to boot? Sheesh, you prove that you have no clue what you
talk about when you treat "easier to read" as a metric that is unrelated to
experience.
| Your examples on the type of syntax transformations one can do in LISP,
| however, don't contradict my point, as far as I can see.
What /would/ contradict your point? It seems to be remarkably resilient,
but mainly in your own view.
Adam Warner
> So basically you want a case-insensitive but case-preserving reader.
> FWIW, that does sound like a nice thing. I've had a new-to-me Mac for a
> couple weeks now, and that's one thing I'm loving about its filesystem.
> If I "touch Foo", the file's called "Foo", and if I "cat foO", "cat
> FOO", and "cat foo", I get the contents of the file "Foo". I think
> that's about as close as the machine can get to doing what I mean in
> this situation.
You'd like Windows filesystems as well Thomas. They also have
case-preserving but case-insensitive filesystems.
>> The idea would seem to require the string information for each unique
>> symbol to be retained forever (unless explicitly destroyed).
>
> Well, it already is. The only way the Lisp system is allowed to forget
> a symbol's name is if you unintern it and lose all references to it.
Well storing a few extra bytes equal to the length of the symbol name
wouldn't seem to be a problem then.
Regards,
Adam
Thomas Stegen CES2000
[snip]
I would just like to say that I find neither C nor Lisp
hard to read when properly formatted. I didn't find
Pascal hard to read when I first started to learn programming.
I find Lisp code harder to read though, but the reason for that
is not that I find it hard to see the structure of the program,
but rather that the idioms and solutions used are different from
what I am used to. One "problem" is that recursion is often
used and I do not have that much training in reading recursive
functions. But my guess is that this is a trivial problem which
will disappear with time :)
So, I speculate that this might be Zivs problem. Not that the
structure of the program is hard to read, but the use of
unfamiliar constructs requires some extra brainpower. I might
be totally wrong and I apologize if that is the case.
--
Thomas.
Approaching singularity.
Adam Warner
> * Adam Warner
> | Scratch that. A large and more satisfying simplification would be the
> | original text being associated with any individual symbol name the
> first | time it is met by the reader (perhaps until the associated text
> is | explicitly destroyed).
>
> What would happen to (defstruct foo ...)? Would you have MAKE-foo or
> make-foo?
Nothing different because the information would only be available to
someone who requested it by calling the new function designed to retrieve
the original string info. That's why it shouldn't affect any existing
code.
> I have spent many hours working on various ways to make a
> case-preserving, lower-case Common Lisp work according to the
> standard, but I find myself stumped by macros that generate symbols by
> "concatenating" input symbols with symbols of its own making. I have
> come to believe that this should be avoided at all cost, including
> writing out the symbols created by defstruct in full. You see, what I
> want is for `intern´ and `symbol-name´ to use lower-case symbol names
> when I throw a switch, but if I also want a case- preserving reader,
> what comes out of defstruct is probably MAKE-foo. To make this work,
> macros that call intern need to capture the state of the flag that
> modifies how `intern´ and friends work so that they would do the right
> thing as the macro writer intended when it was compiled. This is
> pretty messy, so I have not taken then idea any further.
This is a much more ambitious idea Erik. I hope it pays off.
Regards,
Adam
Adam Warner
>> What would happen to (defstruct foo ...)? Would you have MAKE-foo or
>> make-foo?
>
> Nothing different because the information would only be available to
> someone who requested it by calling the new function designed to
> retrieve the original string info. That's why it shouldn't affect any
> existing code.
I think I now see your point. While the symbol name would still be
MAKE-FOO it seems logical that the separate strings name would become
MAKE-foo.
Regards,
Adam
Erik Naggum
| One "problem" is that recursion is often used and I do not have that much
| training in reading recursive functions. But my guess is that this is a
| trivial problem which will disappear with time :)
Heh. Probably not. Recursion can be extremely hard to understand if you
look too closely at it. E.g., the simple factorial function is hard to read
if you try to think about what actually happens to 10! and you try to work
out the recursive calls in your head. What you need to do with recursive
functions is figure out the problem as composed of sub-problems that are
just like itself. For instance, an iterative tree traversal function will
do a lot of work to remember past nodes, while a recursive version can work
on a single node at a time and completely hide the fact that the call stack
holds all the information that the iterative version would have to allocate
explicit memory to hold. So-called tail-recursive problems are only simple
decompositions into itself without any new information in each step and it
makes little sense to use this idiom even when you want to train yourself to
think recursively, because the whole point with recursive functions is that
the call stack contains useful information and tail-recursive functions only
use the function call paradigm to express iteration.
Craig Brozefsky
> On Tue, 27 Aug 2002 07:02:32 +0000 (UTC), Kaz Kylheku
> <k...@ashi.footprints.net> wrote:
> [...]
> >Cruft like semicolons and commas is largely replaced by whitespace.
>
> Yes, that's the point. Commas, semicolons, parens, braces in C provide
> a larger diversity than parens and whitespace alone. This makes it
> more difficult to parse, much more difficult (if not impossible) to do
> the type of things people use LISP macros for, etc. But it also makes
> it easier on the human eye to read.
What is the source for your assertion that it is easier for the human
eye to read more diverse syntax?
I don't really have a hard time with any of the syntaxes, although ML
and Haskell can give me a headache at times.
--
Sincerely,
Craig Brozefsky <cr...@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
Dorai Sitaram
Craig Brozefsky <cr...@red-bean.com> wrote:
>zi...@netvision.net.il (Ziv Caspi) writes:
>
>> On Tue, 27 Aug 2002 07:02:32 +0000 (UTC), Kaz Kylheku
>> <k...@ashi.footprints.net> wrote:
>> [...]
>> >Cruft like semicolons and commas is largely replaced by whitespace.
>>
>> Yes, that's the point. Commas, semicolons, parens, braces in C provide
>> a larger diversity than parens and whitespace alone. This makes it
>> more difficult to parse, much more difficult (if not impossible) to do
>> the type of things people use LISP macros for, etc. But it also makes
>> it easier on the human eye to read.
>
>What is the source for your assertion that it is easier for the human
>eye to read more diverse syntax?
I think he means that more syntax offers concise
visual hints not possible when you are forced to
spelling things out with less syntax. Eg,
"Lisp syntax is *truly* hard," don't you think?
is certainly easier to read than
quote capitalize lisp syntax is emphasize truly
unemphasize hard comma unquote don apostrophe t you
think query
I think the Lisp syntax is plenty readable myself, but
I also don't think its syntax is really as terribly
minimal as it could be. It uses parens very
effectively to identify groups and subgroups, and it
uses keywords at the "car" position where other
languages wantonly use up dedicated characters --
making for less diversity in user-chosen symbols!
Once you start getting a feel for the specialness of
keywords, you get back the diversity of syntax that you
may have initially felt was missing.
If Lisp keywords were not written as words fashioned
from an alphabet but as dedicated symbols (say as
Japanese kanji), with all other words being
alphabet-based, then the wrench of going from C
to Lisp may not be felt as much.
Ng Pheng Siong
> If you know what real macros are, why do you make stupid claims
> about Lisp having a fixed syntax which forces you do to things one
> way, such as to keep nesting deeper and deeper if you want to
> introduce a series of lexical variables which refer to earlier
> lexical variables, and have code interspersed in between?
I'm a Lisp newbie, and I am producing code that looks like this.
What are the better alternatives? Enquiring minds want to know! ;-)
TIA. Cheers.
--
Ng Pheng Siong <ng...@netmemetic.com> * http://www.netmemetic.com
Kent M Pitman
> Kent M Pitman wrote:
> >
> > I personaly think ANSI is a large, too-slow, not-very-useful entity to
> > be accomodating all but the most low-level basic standards. It was
> > probably appropriate to standardize CL itself this way, but even then
> > it's quite clear that the long time-line caused by ANSI resulted in
> > some companies going bankrupt in the meanwhile. Was ANSI the cause?
> > Probably not. But did producing an ANSI standard cost a serious lot of
> > money on the part of all Lisp vendors? Yes.
> >
> I didn't know that it is so slow and expensive. That explains a lot.
Not in terms of its people in their offices nor in terms of its fees.
In terms of the hidden costs of travel to
meetings, of offline work, of the lead time required for notices of
meetings (stretching out timetable), the publishing and review
requirements (resources and temporal duration), the loss of control of
intellectual property they are increasingly pushing for (we just scraped
by before)... everything adds up.
The easily enumerable part is loaded salary costs (salary + overhead
for offices, machines, etc). Producing ANSI CL [1986 to 1995] took a
bit over $400K, if I recall right.
The costs of a zillion people traveling, of the timeline being years
long, of people sitting at desks answering email and reviewing
hardcopy, etc., are hard to measure. I'd say probably that comes
close to doubling it...
None of this counts the cost of the community "accepting" the changes,
meaning of each user reading new documentation, of vendors making and
testing new implementations, of deployed products looking for and perhaps
even debugging incompatibilities (this cost may be present even if the
incompatibilities won't be there, since one has to at least check).
An analyst report I saw at Symbolics once for a fairly modest set of
incompatible changes (that is, small in number but pervasive in nature)
showed that target customers often pay upwards (sometimes way upwards)
of $10K per customer to accept such releases... This aggregates to ENORMOUS
community cost before any new benefit is realized.
Before making changes, one wants to believe they are going to overcome
these costs.
Layered standards are another matter, but require no change to the existing
core.
> > Users love to point to things like this because they want
> > everything on a silver platter if they can get it, but the cost of
> > getting this silver platter is high enough that the rough edges
> > present will buy you more in terms of other things vendors could
> > provide.
> Right. I was only looking for the advantages of further standardisation
> without thinking about the costs.
>
> Your explaination give me a new sight to the hole topic. I didn't realize the
> problems behind that hole process. Thanks for your patient explanations.
Not a problem.
Erik Naggum
| I think the Lisp syntax is plenty readable myself, but I also don't think
| its syntax is really as terribly minimal as it could be.
Some years ago, I spent considerable time playing with the reader in order
to learn how it worked and how much I could change it without removing the
Lisp feel. I modified the list reader to post-process them such that, e.g.,
`(x <- y)´ and `(y -> x)´ would transform to `(setf x y)´, reintroduced the
`=>´ from Scheme's `cond´ to pass the value of the conditional to the body,
got rid of `aref´ with `[array index ...]´ and sundry other minor changes.
Most of these were dead ends, but I still kind of like the infix -> and <-.
(It looks even better with an assortment of Unicode arrows.)
| If Lisp keywords were not written as words fashioned from an alphabet but as
| dedicated symbols (say as Japanese kanji), with all other words being
| alphabet-based, then the wrench of going from C to Lisp may not be felt as
| much.
You can do an amazing amount of syntactic harm with Unicode. I have all
sorts of cute symbols available on my keyboard, now. Real less-than-or-equal
signs, open and filled triangles for brackets and bullets and open and filled
circles and squares for bullets, and a little greek and, um. Syntactic harm.
Thomas F. Burdick
> Thomas F. Burdick wrote:
>
> > So basically you want a case-insensitive but case-preserving reader.
> > FWIW, that does sound like a nice thing. I've had a new-to-me Mac for a
> > couple weeks now, and that's one thing I'm loving about its filesystem.
> > If I "touch Foo", the file's called "Foo", and if I "cat foO", "cat
> > FOO", and "cat foo", I get the contents of the file "Foo". I think
> > that's about as close as the machine can get to doing what I mean in
> > this situation.
>
> You'd like Windows filesystems as well Thomas. They also have
> case-preserving but case-insensitive filesystems.
One important thing I left implicit in that paragraph was that this
was a Unix with the above semantics ... I know I dislike VFAT,
although possibly whatever filesystem NT uses would be okay. The OS
is another question...
> >> The idea would seem to require the string information for each unique
> >> symbol to be retained forever (unless explicitly destroyed).
> >
> > Well, it already is. The only way the Lisp system is allowed to forget
> > a symbol's name is if you unintern it and lose all references to it.
>
> Well storing a few extra bytes equal to the length of the symbol name
> wouldn't seem to be a problem then.
Why would it need to do this? If I understand you correctly, you're
proposing that the reader preserve case, but that it uses a
case-insensitive INTERN.
Thomas F. Burdick
> * Adam Warner
> | Scratch that. A large and more satisfying simplification would be the
> | original text being associated with any individual symbol name the first
> | time it is met by the reader (perhaps until the associated text is
> | explicitly destroyed).
>
> What would happen to (defstruct foo ...)? Would you have MAKE-foo or
> make-foo?
Well, if the reader was case-insensitive but case-preserving, you'd
get the following behavior:
* (defstruct foo)
foo
* (make-foo)
#S(foo)
* (symbol-name 'make-foo)
"MAKE-foo"
* (eql 'make-foo '|make-foo|)
NIL
This wouldn't be backwards-compatible, but it would only break for
ugly code like defstruct. Which is probably too high of a price to
pay, but that's too bad because that looks like very nice case semantics.
> I have spent many hours working on various ways to make a case-preserving,
> lower-case Common Lisp work according to the standard, but I find myself
> stumped by macros that generate symbols by "concatenating" input symbols
> with symbols of its own making. I have come to believe that this should be
> avoided at all cost, including writing out the symbols created by defstruct
> in full. You see, what I want is for `intern´ and `symbol-name´ to use
> lower-case symbol names when I throw a switch, but if I also want a case-
> preserving reader, what comes out of defstruct is probably MAKE-foo. To
> make this work, macros that call intern need to capture the state of the
> flag that modifies how `intern´ and friends work so that they would do the
> right thing as the macro writer intended when it was compiled. This is
> pretty messy, so I have not taken then idea any further.
Yech. I can think of some messy partial-solutions, but I don't know
if they could be made to work because I really don't like thinking
about this problem.