I have try to find out myself and checked some Scheme and Lisp pages.
But althought I'm sure this question was asked a hundred times before, I
wasn't able to figure it out.
It's about Scheme and Common Lisp. Does it make sense to learn one or
the other, or both, or just one of it?
My background: I'm an Eiffel-Programmer, and I think I know quite a bit
about C/C++ and I refuse to do programming a line of C++. So Common Lisp
seems to me a bit like C++. Is that a correct impression? Someone
compared Scheme Standard to CL standard and this was quite frightning.
Scheme comes along with around 50 pages CL with 1100 pages. So does that
means Scheme (lean and mean) CL (big and complex) but more powerful?
On other pages I read the CL is very good for prototyping and it seems
possible to add some type-checking to CL Functions. But I don't have to.
So maybe I could use CL for scritping as for larger scale programming.
I have downloaded diverse Common Lisp systems and I have the Scheme
Shell. And of course I would like to to scripting in one of the two
languages. Does it make sense to use CL for such an area or is Scheme a
better choice here?
I have started with doing some scsh-programming. And even thought I had
a hard time, the elegance of Scheme begins to shine IMO. And I have
three books around which uses Scheme so I have to admit I'm starting to
like it more and more. But a look onto CL gave let me start thinking
again. CL seems to have far more support for OO-programming and Eiffel
is an OO-languae so I migth like CL more.
It would be nice if some of you gave me your thoughts about that.
Regards
Friedrich
* Friedrich Dominicus <···················@inka.de>
| It's about Scheme and Common Lisp. Does it make sense to learn one or
| the other, or both, or just one of it?
if you learn Scheme, you need to learn both. if you learn Common Lisp,
you don't need to learn Scheme.
| My background: I'm an Eiffel-Programmer, and I think I know quite a bit
| about C/C++ and I refuse to do programming a line of C++. So Common Lisp
| seems to me a bit like C++. Is that a correct impression?
no. Common Lisp is not a bit like C++.
| Someone compared Scheme Standard to CL standard and this was quite
| frightning.
this "fear" might mean that Merriam-Webster's Third New International
Dictionary of the English Language are frightening to a kid and that a
1000-phrase book for tourists is the best solution to teaching kids to
write? I have personally looked at huge reference tomes with a sort of
"wow! somebody did all that work and organized it for me!" attitude. I
also consider it frightening that anyone would sit down and actually
attempt to design a language and yet leave so much work to its users as
Scheme does. the consequence is that Scheme is a much bigger language
than Common Lisp in practice: Scheme is not a language you can use out of
the box, so you have to know at least a few implementations and each has
a million functions, all non-standard and slightly different in most
ways. in Scheme, purity rules, so every time someone sees what he
considers to be impure, he goes off to write his own, creating yet more
incompatible Scheme implementations and yet more unreadable Scheme code.
irony has never been quite so strong as in the "lean and mean design" of
Scheme. Common Lisp has a "just do it" quality to it that I like a lot,
especially since it's much, much harder to get a large language beautiful
than to make a small language beautiful, and Common Lisp is beautiful.
| Scheme comes along with around 50 pages CL with 1100 pages. So does that
| means Scheme (lean and mean) CL (big and complex) but more powerful?
it means Scheme was designed to prove something and Common Lisp was
designed to build something.
scripting has to fit into a much large scheme of things (pun intended),
and Scheme is easier to force into other schemes of things because it
doesn't carry enough weight of its own to be a burden to anyone: in other
words, if used for scripting, Scheme is a thin veneer of syntax on top of
a different system's semantics. for some, this seems to be sufficient.
| CL seems to have far more support for OO-programming and Eiffel is an
| OO-languae so I might like CL more.
I think you should approach new languages as "a programmer", not "an
Eiffel programmer".
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <379ECE44.91A8ECB@iname.com>
Erik Naggum wrote:
[stuff]
I forgot that if you do CL, you'll have to take a speed reading course and buy
some asbestos underwear ;-) [Erik is cool]
Erik Naggum wrote:
>
> * Friedrich Dominicus <···················@inka.de>
> | It's about Scheme and Common Lisp. Does it make sense to learn one or
> | the other, or both, or just one of it?
>
> if you learn Scheme, you need to learn both. if you learn Common Lisp,
> you don't need to learn Scheme.
That't a clear opinion, thanks.
>
> | My background: I'm an Eiffel-Programmer, and I think I know quite a bit
> | about C/C++ and I refuse to do programming a line of C++. So Common Lisp
> | seems to me a bit like C++. Is that a correct impression?
>
> no. Common Lisp is not a bit like C++.
Maybe stated to lazy. I should know better. Let's state it another way.
I thinkI can like C but I can't like the OO-stuff above it in C++. So
is Scheme more like C and CL in this sense more than C++?
>
> | Someone compared Scheme Standard to CL standard and this was quite
> | frightning.
>
> this "fear" might mean that Merriam-Webster's Third New International
> Dictionary of the English Language are frightening to a kid and that a
> 1000-phrase book for tourists is the best solution to teaching kids to
> write?
you mean possibly not ;-)
> I have personally looked at huge reference tomes with a sort of
> "wow! somebody did all that work and organized it for me!" attitude.
Oh I guess that's a good way.
>I
> also consider it frightening that anyone would sit down and actually
> attempt to design a language and yet leave so much work to its users as
> Scheme does. the consequence is that Scheme is a much bigger language
> than Common Lisp in practice: Scheme is not a language you can use out of
> the box, so you have to know at least a few implementations and each has
> a million functions, all non-standard and slightly different in most
> ways. in Scheme, purity rules, so every time someone sees what he
> considers to be impure, he goes off to write his own, creating yet more
> incompatible Scheme implementations and yet more unreadable Scheme code.
> irony has never been quite so strong as in the "lean and mean design" of
> Scheme. Common Lisp has a "just do it" quality to it that I like a lot,
> especially since it's much, much harder to get a large language beautiful
> than to make a small language beautiful, and Common Lisp is beautiful.
In short Scheme conform to their standard but extend far beyond for
doing real progamming but CL is good enough to have it all standardized?
I bet this is harsh simpliefied but that's what I read out of the above.
>
> | Scheme comes along with around 50 pages CL with 1100 pages. So does that
> | means Scheme (lean and mean) CL (big and complex) but more powerful?
>
> it means Scheme was designed to prove something and Common Lisp was
> designed to build something.
Oh I think I want to build some things ;-)
>
> | CL seems to have far more support for OO-programming and Eiffel is an
> | OO-languae so I might like CL more.
>
> I think you should approach new languages as "a programmer", not "an
> Eiffel programmer".
Sorry I can't be just a programmer. I come form a context and this
context means that I'm very used to do Eiffel programming but I started
with some imperative languages. So I'm completly biased but possibly I'm
able to see advantages of FP even if I don't know much about it. I guess
if you have to learn a new language which is Lisp-like you will have
your bias too.
But nevertheless thanks for taking the time to answer.
Regards
Friedrich
In article <·················@inka.de>, ···················@inka.de
says...
> So is Scheme more like C and CL in this sense more than C++?
No. It's more like this: Common Lisp is to Scheme as C is to Pascal.
They're different languages with different histories & cultures.
Another perspective looks like this: CL is to Smalltalk as Smalltalk
is to C. Now substitute C++ for C (or Pascal for C) and Scheme for CL.
That's how I'd begin to explain it to someone totally unfamiliar with
CL and Scheme. As we zoom in closer, some details emerge. At some
point you have a clear enough picture for you to make a choice.
I would put it another way for someone familiar with other tools.
As you know Eiffel, I might substitute Eiffel for C. The problem with
all of this is that it's like saying an elephant is a bit like a
hippo. While it helps give a vague feeling for what these animals are
like, it doesn't help you choose an animal for a zoo.
So, unless you're satisfied with some simple advise ("learn Common
Lisp") you're probably going to have to do a lot of reading. I learned
CL long before I even heard of Scheme, so I may be heavily biased.
OTOH, that might be a significant point. You decide.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <379F0CBF.1097480B@iname.com>
Friedrich Dominicus wrote:
> Maybe stated to lazy. I should know better. Let's state it another way.
> I thinkI can like C but I can't like the OO-stuff above it in C++. So
> is Scheme more like C and CL in this sense more than C++?
Then you are OK. C is a portable assembler, which makes sense; while C++ is an
extension of that with even more emphasis as a solution for the development of
applications.
No matter the base differences between Scheme and CL, nothing comes into play
when you go into the OO arena. You might not like
the `lack' of encapsulation in CLOS, but there's a different mechanism for that
in CL (packages). If you want classic OO encapsulation,
you might find that in some classic OO system for scheme, but then, classic OO is
wrong. That's the main conclusion you should come to, if you take Dylan, Cecil,
or CLOS. That's one of the main interests of your journey:
1. Syntax
2. Reflection
3. Sentence Oriented Programming
Friedrich Dominicus <···················@inka.de> writes:
> I have try to find out myself and checked some Scheme and Lisp pages.
> But althought I'm sure this question was asked a hundred times before, I
> wasn't able to figure it out.
>
> It's about Scheme and Common Lisp. Does it make sense to learn one or
> the other, or both, or just one of it?
I'd go with CL. Scheme is nice, but it lack a "wide" standard.
>
> My background: I'm an Eiffel-Programmer, and I think I know quite a bit
> about C/C++ and I refuse to do programming a line of C++. So Common Lisp
> seems to me a bit like C++. Is that a correct impression?
Get away from here! :)
> Someone
> compared Scheme Standard to CL standard and this was quite
> frightning.
If you refer to the 903 pages of the latest Stroustroup's book on C++
you are right. Anyway, the "standards" for CL and Scheme are rather
different in content. Let's consider multi-dimensional arrays. They
account for a big chunk of the CL standard. The account for 0 pages of
the Scheme standard R5RS. That is because multi-dimensional arrays
are not in the standard. Let's talk about records (structures). They
account for another big chunk of the CL standard and they account for
0 pages of the R5RS of Scheme: once again they are not in the
standard. I can go on and on and on... I feel like the pink rabbit. :)
So, comparing the CL standard to R5RS (the Scheme standard) is unfair
to both. They do not cover the same material.
> Scheme comes along with around 50 pages CL with 1100 pages. So does that
> means Scheme (lean and mean) CL (big and complex) but more powerful?
Not it does not. It means that your CL program will be more easily
portable across different implementations. E.g. suppose you use CL
and write
(defstruct point
(x 0 :type (mod 1024))
(y 0 :type (mod 1024)))
and then go ahead and write your program using this definition. Now
you are sure that this program will run in other CL implementations as
well.
Suppose, thet, by chance you write the same (non standard) program in
the Scheme implementation X which does support DEFSTRUCT and then try
to run it in another Scheme implementation Y, which does not. You
have - at the very least - make sure that you can have the correct
DEFSTRUCT library installed in implementation Y. Which of course
means that, since implementation Y already supports DEFINE-RECORD,
that your footprint starts to blow up. You get the idea.
> On other pages I read the CL is very good for prototyping and it seems
> possible to add some type-checking to CL Functions. But I don't have to.
> So maybe I could use CL for scritping as for larger scale
> programming.
The term "scripting" has always eluded me :)
> I have downloaded diverse Common Lisp systems and I have the Scheme
> Shell. And of course I would like to to scripting in one of the two
> languages. Does it make sense to use CL for such an area or is Scheme a
> better choice here?
>
> I have started with doing some scsh-programming. And even thought I had
> a hard time, the elegance of Scheme begins to shine IMO. And I have
> three books around which uses Scheme so I have to admit I'm starting to
> like it more and more. But a look onto CL gave let me start thinking
> again. CL seems to have far more support for OO-programming and Eiffel
> is an OO-languae so I migth like CL more.
AFAIK CL has the same support for OO as Eiffel and then some. If some
feature is missing, you can build it in CL (alright, let's not talk
too much about type-checking - we can always invite the ML crowd for
this). If some CL feature is missing in Eiffel you cannot (that is as
much as I know of Eiffel). :)
Some CL compilers also do a decent job at "non lethal" :) type
checking.
Hope it helps
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti wrote:
>
> Friedrich Dominicus <···················@inka.de> writes:
>
> > I have try to find out myself and checked some Scheme and Lisp pages.
> > But althought I'm sure this question was asked a hundred times before, I
> > wasn't able to figure it out.
> >
> > It's about Scheme and Common Lisp. Does it make sense to learn one or
> > the other, or both, or just one of it?
>
> I'd go with CL. Scheme is nice, but it lack a "wide" standard.
>
> >
> > My background: I'm an Eiffel-Programmer, and I think I know quite a bit
> > about C/C++ and I refuse to do programming a line of C++. So Common Lisp
> > seems to me a bit like C++. Is that a correct impression?
>
> Get away from here! :)
Oh now I like this group very much, don't though me out please;-) Sorry
it was lazy formulated. It was in the sense C (small and relative
consequent) and C++ a nighmare because of complexity added by all the
virtual stuff ;-)
>
> > Someone
> > compared Scheme Standard to CL standard and this was quite
> > frightning.
>
> If you refer to the 903 pages of the latest Stroustroup's book on C++
> you are right. Anyway, the "standards" for CL and Scheme are rather
> different in content. Let's consider multi-dimensional arrays. They
> account for a big chunk of the CL standard. The account for 0 pages of
> the Scheme standard R5RS. That is because multi-dimensional arrays
> are not in the standard. Let's talk about records (structures). They
> account for another big chunk of the CL standard and they account for
> 0 pages of the R5RS of Scheme: once again they are not in the
> standard. I can go on and on and on... I feel like the pink rabbit. :)
just curious what is a this pink rabbit? But thanks for pointing out why
things are like they are. I dared to download the CL Hyperspec stuff and
I bet some looks into it may show if it's organized that it's really
helpful. I bet it is, others have stated that they found it the one of
the best documents around.
>
> So, comparing the CL standard to R5RS (the Scheme standard) is unfair
> to both. They do not cover the same material.
>
> > Scheme comes along with around 50 pages CL with 1100 pages. So does that
> > means Scheme (lean and mean) CL (big and complex) but more powerful?
>
> Not it does not. It means that your CL program will be more easily
> portable across different implementations. E.g. suppose you use CL
> and write
>
> (defstruct point
> (x 0 :type (mod 1024))
> (y 0 :type (mod 1024)))
>
> and then go ahead and write your program using this definition. Now
> you are sure that this program will run in other CL implementations as
> well.
>
> Suppose, thet, by chance you write the same (non standard) program in
> the Scheme implementation X which does support DEFSTRUCT and then try
> to run it in another Scheme implementation Y, which does not. You
> have - at the very least - make sure that you can have the correct
> DEFSTRUCT library installed in implementation Y. Which of course
> means that, since implementation Y already supports DEFINE-RECORD,
> that your footprint starts to blow up. You get the idea.
Thanks I didn't know that. I've downloaded the Scheme Schell and
DrScheme both seem to be quite good for learning.
>
> > On other pages I read the CL is very good for prototyping and it seems
> > possible to add some type-checking to CL Functions. But I don't have to.
> > So maybe I could use CL for scritping as for larger scale
> > programming.
>
> The term "scripting" has always eluded me :)
Why that what is negative with it. IMO it's quite positive to have a
language which scales nicely. I can't tell this from Eiffel.
> Hope it helps
Yes thanks for taking the time to answer. It seems the tendency in this
group is in learning CL what is not a suprise because we are in c.l.l
;-)
Regards
Friedrich
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <379F0339.AD7C7A46@iname.com>
Friedrich Dominicus wrote:
> Thanks I didn't know that. I've downloaded the Scheme Schell and
> DrScheme both seem to be quite good for learning.
DrScheme is probably the best environment to learn Lisp. After all, that's its
purpose!
> > The term "scripting" has always eluded me :)
> Why that what is negative with it. IMO it's quite positive to have a
> language which scales nicely. I can't tell this from Eiffel.
Because Unix-minded people need `scripts' and `real programs'. Lisp `scripts'
are just real programs.
Friedrich Dominicus wrote:
> .... It seems the tendency in this group is in learning CL what is not a
> suprise because we are in c.l.l ...
What do they say in comp.lang.scheme?
;-) will
William Deakin wrote:
>
> Friedrich Dominicus wrote:
>
> > .... It seems the tendency in this group is in learning CL what is not a
> > suprise because we are in c.l.l ...
>
> What do they say in comp.lang.scheme?
first answer: Learn both. Scheme will let you more easily graps the
"spirit" of Lisp-Programming;-)
Regards
Friedrich
* Friedrich Dominicus <···················@inka.de>
| first answer: Learn both. Scheme will let you more easily graps the
| "spirit" of Lisp-Programming;-)
this reminds me of something. Scheme people will go out of their way to
claim that Scheme is a Lisp. this is like communist dictatorships which
refer to themselves as "democracies" and people who kill doctors and bomb
medical clinics and call themselves "pro-life", as if hijacking a nice
word can make up for the facts. I just wish Scheme people could be proud
of what they have instead of being so childish and immature that they can
only enjoy their little scheming games if they can usurp somebody else's
terminology.
but, hey, my first objection to GUILE was that it was a name I'd expect
from politicians too self-loathing to be proud of what they did, and
Schemer and Conniver have similar connotations with me�, strengthened
after looking at what Scheme people do when you say that Scheme should be
good enough on its own not to need the Lisp label so it can blame Common
Lisp for everything when it fails. you see, "Scheme" is what they call
their language when they succeed. when they fail, they call it "Lisp".
for as long as I have been watching Scheme people, they have contributed
much more to the bad name that "Lisp" has than to the good name that they
think "Scheme" has by unloading all their misery on the "Lisp" name. so
look out for people who object to Common Lisp because they once got
burned on a Scheme project, or learned Scheme from a bad teacher who
insisted that Scheme is the only true Lisp. scheming bastards, indeed.
(this article contains 240% of the RDA of cynicism. please limit your
intake if you feel irritated. prolonged exposure may also cause anger.)
#:Erik
-------
� like FORTH was called just that because the IBM system on which the
author worked had only five letters available in compiler names, not the
six he needed to name his fourth language, SCHEME comes from a similar
limit of six characters unable to hold the name "SCHEMER", which was the
sequel to "CONNIVER", which followed the normal, boring name "PLANNER" --
all projects within the AI community.
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
On Wed, 28 Jul 1999 19:06:34 +0200, Friedrich Dominicus
<···················@inka.de> wrote:
>William Deakin wrote:
>> Friedrich Dominicus wrote:
>> > .... It seems the tendency in this group is in learning CL what
>> > is not a surprise because we are in c.l.l ...
>>
>> What do they say in comp.lang.scheme?
>
>first answer: Learn both. Scheme will let you more easily grasp the
>"spirit" of Lisp-Programming;-)
If part of your desire is to be able to quickly implement your own
version, Scheme is not unlike FORTH in being a language that is almost
trivial to reimplement.
In that process, you will learn some things about abstraction that
will be valuable.
CL aficionados will, unsurprisingly, encourage you to then move on as
quickly as possible to a more full-featured dialect. Which is not an
unreasonable suggestion. The unfortunate thing about Scheme is that
it doesn't include all the rich functionality Common Lisp has. Folks
that try to cobble additional functionality onto Scheme tend to
recreate in non-interoperable ways things that CL already has...
--
debugging, v:
Removing the needles from the haystack.
········@ntlug.org- <http://www.hex.net/~cbbrowne/langlisp.html>
On Wed, 28 Jul 1999 14:14:17 +0200, Friedrich Dominicus
<···················@inka.de> wrote:
> Marco Antoniotti wrote:
> > standard. I can go on and on and on... I feel like the pink rabbit. :)
>
> just curious what is a this pink rabbit? But thanks for pointing out why
^^^^^^^^^^^
Maybe something like a guinea pig ("cavia", "animale da laboratorio" in
Italian)?
Paolo
--
Paolo Amoroso <·······@mclink.it>
In article <················@news.mclink.it>, ·······@mclink.it (Paolo
Amoroso) wrote:
>> Marco Antoniotti wrote:
>> > standard. I can go on and on and on... I feel like the pink rabbit. :)
>>
>> just curious what is a this pink rabbit? But thanks for pointing out why
> ^^^^^^^^^^^
>Maybe something like a guinea pig ("cavia", "animale da laboratorio" in
>Italian)?
I think what the original poster meant was something like:
"I can go on and on and on.... I fell like the Enegizer Bunny. :)"
However, he called the Enegizer Bunny the "pink rabbit," and this was lost
on some of us who don't watch as many TV commercials as I do.
Raf
--
Raffael Cavallaro, Ph.D.
·······@mediaone.net
Friedrich Dominicus <···················@inka.de> writes:
> It's about Scheme and Common Lisp. Does it make sense to learn one or
> the other, or both, or just one of it?
>
> My background: I'm an Eiffel-Programmer, and I think I know quite a bit
> about C/C++ and I refuse to do programming a line of C++. So Common Lisp
> seems to me a bit like C++. Is that a correct impression? Someone
As others have pointed out, C++ and CL aren't similar at all, neither
in complexity (C++ is much more complex than CL!) nor in the reasons
for the sizes of their standards. C++ is a very complex language in
itself, even without any library. CL OTOH is quite a simple language
at it's core (similar in simplicity to Scheme), but it includes a large
library (which isn't complex in itself either). And the CL standard is
rather more readable and helpful (even to non-language-lawyers) than
the C++ standard.
> compared Scheme Standard to CL standard and this was quite frightning.
> Scheme comes along with around 50 pages CL with 1100 pages. So does that
> means Scheme (lean and mean) CL (big and complex) but more powerful?
Since you are an Eiffel programmer, I'd ask you whether you found
Eiffel's "one way to loop has to be enough for everyone" approach
lean, mean _and_ _practical_? If you did, I'd say you might be happy
with Scheme, which isn't quite as restricted as the "RISC" language
called Eiffel, and since R5RS has macros, you can at least built
yourself new loops if you so desire. Of course all those loops will
be non-standard, so they will be difficult to read for others.
I OTOH found the "one loop fits all" attitude extremely non-practical
(in effect, Eiffel was the first ever language I used, where I really
needed it's ability to automatically check variants and invariants in
loops, since I regularly made mistakes in writing those loops. I
normally make mistakes of that sort in other languages about once in
every 5 years or so).
In effect I'd be careful to distinguish between unnecessary complexity
(which should be elided, but which makes up large part of C++, where
the complexity seems necessary, but only because of underlying design
decisions which are ill matched to it's current uses), and necessary
complexity or size, which should be welcomed, since they make your
life as a programmer easier, IMHO.
> three books around which uses Scheme so I have to admit I'm starting to
> like it more and more. But a look onto CL gave let me start thinking
> again. CL seems to have far more support for OO-programming and Eiffel
> is an OO-languae so I migth like CL more.
Well, there are 100 OO subsystems for Scheme (no, wait a minute, now
there are 101, no 102 ;), so you can certainly do OO programming in
Scheme. Not portably though.
Also, CL doesn't make so much of it's object-orientedness than
mainstream languages like Eiffel, C++, etc. do. The pure OO part of
CL (i.e. CLOS) isn't fundamental to CL. The basic idea of OO (which
most often get's lost in mainstream languages, i.e. that OO isn't
about classes or methods, anymore than astronomy is about optical
telescopes) OTOH is central to Lisp (in both CL and Scheme's guises).
Try to stop thinking in mainstream terms, it will help you avoid
confusion...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre R. Mai wrote:
>
> Friedrich Dominicus <···················@inka.de> writes:
>
> > It's about Scheme and Common Lisp. Does it make sense to learn one or
> > the other, or both, or just one of it?
> >
> > My background: I'm an Eiffel-Programmer, and I think I know quite a bit
> > about C/C++ and I refuse to do programming a line of C++. So Common Lisp
> > seems to me a bit like C++. Is that a correct impression? Someone
>
> As others have pointed out, C++ and CL aren't similar at all, neither
> in complexity (C++ is much more complex than CL!) nor in the reasons
> for the sizes of their standards. C++ is a very complex language in
> itself, even without any library. CL OTOH is quite a simple language
> at it's core (similar in simplicity to Scheme), but it includes a large
> library (which isn't complex in itself either). And the CL standard is
> rather more readable and helpful (even to non-language-lawyers) than
> the C++ standard.
This was pointed out in other replies. So I guess this fear is not all
so worse.
>
> Since you are an Eiffel programmer, I'd ask you whether you found
> Eiffel's "one way to loop has to be enough for everyone" approach
> lean, mean _and_ _practical_? If you did, I'd say you might be happy
> with Scheme, which isn't quite as restricted as the "RISC" language
> called Eiffel, and since R5RS has macros, you can at least built
> yourself new loops if you so desire. Of course all those loops will
> be non-standard, so they will be difficult to read for others.
I'm quite a fan of Eiffel especiall it's idea of Design-by-Contract but
I like to the static type-checking and yes I don't have any problems
with the one loop. But because I think I've done quite a bit
OO-programming I may be better of with CL.
>
> In effect I'd be careful to distinguish between unnecessary complexity
> (which should be elided, but which makes up large part of C++, where
> the complexity seems necessary, but only because of underlying design
> decisions which are ill matched to it's current uses), and necessary
> complexity or size, which should be welcomed, since they make your
> life as a programmer easier, IMHO.
>
> > three books around which uses Scheme so I have to admit I'm starting to
> > like it more and more. But a look onto CL gave let me start thinking
> > again. CL seems to have far more support for OO-programming and Eiffel
> > is an OO-languae so I migth like CL more.
>
> Well, there are 100 OO subsystems for Scheme (no, wait a minute, now
> there are 101, no 102 ;), so you can certainly do OO programming in
> Scheme. Not portably though.
How often do you change you Common Lisp programming environment?
>
> Try to stop thinking in mainstream terms, it will help you avoid
> confusion...
I do think that I'm not thinking in mainstream terms. I like the if
things are done consequently and in this aspect I like Eiffel very much.
But I like too C and Python and as told before Scheme-solutions look
quite interesting.
But what I like most about Eiffel is it's idear of Design-by-Contract.
Wouldn't that s.th. what would be nice vor CL too?
Regards
Friedrich
Friedrich Dominicus wrote:
> But what I like most about Eiffel is it's idear of Design-by-Contract.
> Wouldn't that s.th. what would be nice vor CL too?
Yes, see <http://www.gauss.muc.de/tools/dbc/dbc-intro.html>
Regards
Matthias
Matthias H�lzl wrote:
>
> Friedrich Dominicus wrote:
>
> > But what I like most about Eiffel is it's idear of Design-by-Contract.
> > Wouldn't that s.th. what would be nice vor CL too?
>
> Yes, see <http://www.gauss.muc.de/tools/dbc/dbc-intro.html>
I'm thinking that I like Lisp-like syntax more and more. It's a pitty
that braces can keep someone from learning new things. But this was true
for me. Ash on my head ;-)
Regards
Friedrich
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <379F6C36.B86FD52@iname.com>
Friedrich Dominicus wrote:
> I'm thinking that I like Lisp-like syntax more and more. It's a pitty
> that braces can keep someone from learning new things. But this was true
> for me. Ash on my head ;-)
Tastes GOOD!!
Who wants a mirror? I don't need it.. ;-)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 28 Jul 1999 19:08:51 +0200, Matthias H�lzl
<······@informatik.uni-muenchen.de> wrote:
>Yes, see <http://www.gauss.muc.de/tools/dbc/dbc-intro.html>
BTW,
I tried to use it with ACL 5.0, but it didn't work.
/L/e/k/t/u
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i
iQA/AwUBN58yz/4C0a0jUw5YEQIHtwCeOMGKEXXmHQjDiRtxbQpR8Rn+eckAn2Ys
9fEoyHVpuWUgZ3z5qQ76o2Pu
=EExD
-----END PGP SIGNATURE-----
Juanma Barranquero wrote:
> On Wed, 28 Jul 1999 19:08:51 +0200, Matthias H�lzl
> <······@informatik.uni-muenchen.de> wrote:
[About the Design by Contract package]
> >Yes, see <http://www.gauss.muc.de/tools/dbc/dbc-intro.html>
>
> I tried to use it with ACL 5.0, but it didn't work.
I removed the pre- and postcondition documentation strings which caused
ACL 5.0
to fail. The new version of the DBC package is available from the above
location.
Thanks for the error report,
Matthias
Friedrich Dominicus <···················@inka.de> writes:
> But what I like most about Eiffel is it's idear of Design-by-Contract.
> Wouldn't that s.th. what would be nice vor CL too?
>
You can just do it yourself in CLOS. If you check dejanews for the
previous Design-by-Contract discussion in c.l.l., you'll find a post
by someone who implemented DbC as a method combination for CLOS.
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
Friedrich Dominicus wrote:
> How often do you change you Common Lisp programming environment?
I guess far less often than Schemers change theirs?
(Nothing beats CLOS and MOP by the way.)
Robert
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <379F060C.CA6A3FCC@iname.com>
Friedrich Dominicus wrote:
> How often do you change you Common Lisp programming environment?
Some people never, some people often. Typical reasons for switching:
1. Thread-safe implementation.
2. Native thread support.
3. Real-time garbage collection
4. Overall efficiency
5. floating-point efficiency
6. CLOS efficiency
7. Facilitated C++ interfacing
8. Footprint
9. Royalties
10. No redundant GC (when combining with Java)
11. Platform (including JVM).
12. Support
13. Vendor-specific add-ons
> > How often do you change you Common Lisp programming environment?
>
> Some people never, some people often. Typical reasons for switching:
>
> 1. Thread-safe implementation.
> 2. Native thread support.
> 3. Real-time garbage collection
> 4. Overall efficiency
> 5. floating-point efficiency
> 6. CLOS efficiency
> 7. Facilitated C++ interfacing
> 8. Footprint
> 9. Royalties
> 10. No redundant GC (when combining with Java)
> 11. Platform (including JVM).
> 12. Support
> 13. Vendor-specific add-ons
You forget the most important one:
14. The vendor going out of business or ceasing to market the product or the
university losing the grant to continue development.
The list is long:
1. Symbolics
2. TI
3. LMI
4. Xerox
5. Gold Hill
6. Lucid
7. Harlequin
8. ExperCommonLisp
9. Procyon
10. Star Sapphire
11. WCL
12. Chestnut
13. GCL
14. CMUCL
15. Poplog
16. MCL
I may have missed a few.
Jeff (http://www.neci.nj.nec.com/homepages/qobi)
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <379F6B58.E86C69A5@iname.com>
Jeffrey Mark Siskind wrote:
> You forget the most important one:
>
> 14. The vendor going out of business or ceasing to market the product or the
> university losing the grant to continue development.
I hid that under 12 ;->
But you reminded me of a very important one:
15. Verification
In article <···············@qobi.nj.nec.com>, Jeffrey Mark Siskind <····@research.nj.nec.com> wrote:
14. The vendor going out of business or ceasing to market the product or the
> university losing the grant to continue development.
>
> The list is long:
>
> 1. Symbolics
> 2. TI
> 3. LMI
> 4. Xerox
> 5. Gold Hill
> 6. Lucid
> 7. Harlequin
> 8. ExperCommonLisp
> 9. Procyon
> 10. Star Sapphire
> 11. WCL
> 12. Chestnut
> 13. GCL
> 14. CMUCL
> 15. Poplog
> 16. MCL
>
I think this list dangerously mixes different things. I'm
not really happy with it, sorry. So that nobody gets a wrong
*impression* about it, MCL for example is still with us and it
is supported and ...
Friedrich Dominicus <···················@inka.de> writes:
> > Well, there are 100 OO subsystems for Scheme (no, wait a minute, now
> > there are 101, no 102 ;), so you can certainly do OO programming in
> > Scheme. Not portably though.
>
> How often do you change you Common Lisp programming environment?
The point is that if you change from CMUCL to Harlequin LW (or
whatever), you know that your system will work with a far greater
probability than when switching from one Scheme environment to the other.
> > Try to stop thinking in mainstream terms, it will help you avoid
> > confusion...
>
> I do think that I'm not thinking in mainstream terms. I like the if
> things are done consequently and in this aspect I like Eiffel very much.
> But I like too C and Python and as told before Scheme-solutions look
> quite interesting.
>
> But what I like most about Eiffel is it's idear of Design-by-Contract.
> Wouldn't that s.th. what would be nice vor CL too?
What exactly is "Design by Contract"?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
>
> What exactly is "Design by Contract"?
Let me give an example. The all so well known factorial. Written in an
imperative style to show some extra assertions
factorial(n: INTEGER): INTEGER is
require
n_positiv: n >= 0
local
i : INTEGER
do
Result :=1
-- holds for n = 0
from
i:= n
invariant
i_positive_and_less_than_n: i >=0 and then i <= n;
variant
i_decreases: i
until
i <=1
loop
Result := Result * i;
i := i-1
end; -- from
end; -- faculty
The interesting points are require. In which I state clearly what I
expect n to be a positive number. And because loops will be problematic
you have the invariant part. Which must hold fo every iteration and the
variant part which must be a decreasing number but always positive. Now
you may say that isn't a big thing. But if you have an ancestor and some
descendants the assertions are inherited too.
This assertions can be extracted from the source and give a nice
specification. And indeed you can use Eiffel for specifyin your problem.
I guess the conditions look familar to LISPERS because you are used to
do declarative programming. That is what they are, they don't state how
s.th is done but what has to hold. But this is quite what FP-programming
is about I guess.
If that assertions does not hold an exception is risen, which you can
handle in a rescue part.
Does that example answer your question?
Regards
Friedrich
Friedrich Dominicus wrote:
>
> >
> > What exactly is "Design by Contract"?
>
> Let me give an example...
Search the newsgroup or the ALU pages, there is a DBC implementation out
there for Common Lisp.
Robert
Friedrich Dominicus <···················@inka.de> writes:
> >
> > What exactly is "Design by Contract"?
>
> Let me give an example. The all so well known factorial. Written in an
> imperative style to show some extra assertions
> factorial(n: INTEGER): INTEGER is
> require
> n_positiv: n >= 0
> local
> i : INTEGER
> do
> Result :=1
> -- holds for n = 0
> from
> i:= n
> invariant
> i_positive_and_less_than_n: i >=0 and then i <= n;
> variant
> i_decreases: i
> until
> i <=1
> loop
> Result := Result * i;
> i := i-1
> end; -- from
>
> end; -- faculty
(defmethod factorial ((n integer) &optional (acc 1))
(if (zerop n)
acc
(factorial (1- n) (* n acc))))
(defmethod factorial :before ((n integer) &optional (acc 1))
(when (minusp n)
(error 'arithmetic-error
:operation 'factorial
:operands (list n))))
Not quite the same, but similar. Now that I remember I have
downloaded some macrology to have DBC in Common Lisp.
> The interesting points are require. In which I state clearly what I
> expect n to be a positive number. And because loops will be problematic
> you have the invariant part. Which must hold fo every iteration and the
> variant part which must be a decreasing number but always positive. Now
> you may say that isn't a big thing. But if you have an ancestor and some
> descendants the assertions are inherited too.
>
> This assertions can be extracted from the source and give a nice
> specification. And indeed you can use Eiffel for specifyin your problem.
>
> I guess the conditions look familar to LISPERS because you are used to
> do declarative programming. That is what they are, they don't state how
> s.th is done but what has to hold. But this is quite what FP-programming
> is about I guess.
>
> If that assertions does not hold an exception is risen, which you can
> handle in a rescue part.
>
> Does that example answer your question?
Yes it does. It is a nice feature. Not too difficult to implement in
CL, apart from the LOOP invariants. I suppose Exceptions are
objectified in Eiffel (as in CL and Java) aren't they?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti wrote:
> >
> > Does that example answer your question?
>
> Yes it does. It is a nice feature. Not too difficult to implement in
> CL, apart from the LOOP invariants. I suppose Exceptions are
> objectified in Eiffel (as in CL and Java) aren't they?
No unfortunatly not.
Ok if it's not too difficult. But please remember assertions are
inherited too. And you can turn them on or of as you like. So I bet a
bit work to do ;-)
Regards
Friedrich
In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> Friedrich Dominicus <···················@inka.de> writes:
>
> > >
> > > What exactly is "Design by Contract"?
> >
> > Let me give an example. The all so well known factorial. Written in an
> > imperative style to show some extra assertions
> > factorial(n: INTEGER): INTEGER is
> > require
> > n_positiv: n >= 0
> > local
> > i : INTEGER
> > do
> > Result :=1
> > -- holds for n = 0
> > from
> > i:= n
> > invariant
> > i_positive_and_less_than_n: i >=0 and then i <= n;
> > variant
> > i_decreases: i
> > until
> > i <=1
> > loop
> > Result := Result * i;
> > i := i-1
> > end; -- from
> >
> > end; -- faculty
I find this example particular ugly.
- trivialities are expanded
- the compiler does not care a thing about the assertions at
compile time.
would the compiler help you to find the error of calling (factorial -3) ?
You **could** use the subrange (integer 0) as a type for n,
but then it is already required.
- it fails to capture the pattern of iteration or recursion in any,
instead you are writing invariants for the
same recursive/iterative patterns in different algorithms
over and over
- if you run it with assertions on, the code will be dead slow,
so you turn off assertions
- it fails to integrate with the error system, the
hints that are providable to a user/developer in case of
an error are little above zero.
How can I continue?
- the loop syntax is as bloated as Common Lisp's
> > This assertions can be extracted from the source and give a nice
> > specification. And indeed you can use Eiffel for specifyin your problem.
But then I'd rather use a logic language or a theorem prover.
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>
> > Friedrich Dominicus <···················@inka.de> writes:
> >
> > > >
> > > > What exactly is "Design by Contract"?
> > >
> > > Let me give an example. The all so well known factorial. Written in an
> > > imperative style to show some extra assertions
> > > factorial(n: INTEGER): INTEGER is
...
> - it fails to integrate with the error system, the
> hints that are providable to a user/developer in case of
> an error are little above zero.
> How can I continue?
This is pretty ugly indeed. Non objectified exceptions 'a la` CL
(which was the first language to have this feature? Maybe CLU?)
> - the loop syntax is as bloated as Common Lisp's
Impossible! No language construct can be as bloated as CL LOOP. :)
>
> > > This assertions can be extracted from the source and give a nice
> > > specification. And indeed you can use Eiffel for specifyin your problem.
>
> But then I'd rather use a logic language or a theorem prover.
This is a very good point indeed. Algorithm and Implementation
verification are things that are done better with some tools of the
Theorem Prover (Model Checker) class. This is particularly true when
you want to set up assertions regarding very complex interactions
among subsystems (distributed algorithms and real-time scheduling
problems come to mind).
The problem then becomes. Wehn do I stop having a compiler to play
with and start having a Theorem Prover?
Certainly, things like type inference are very close to this grey area.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>
> > Friedrich Dominicus <···················@inka.de> writes:
> >
> > > >
> > > > What exactly is "Design by Contract"?
> > >
> > > Let me give an example. The all so well known factorial. Written in an
> > > imperative style to show some extra assertions
> > > factorial(n: INTEGER): INTEGER is
...
> - it fails to integrate with the error system, the
> hints that are providable to a user/developer in case of
> an error are little above zero.
> How can I continue?
This is pretty ugly indeed. Non objectified exceptions 'a la` CL
(which was the first language to have this feature? Maybe CLU?)
> - the loop syntax is as bloated as Common Lisp's
Impossible! No language construct can be as bloated as CL LOOP. :)
>
> > > This assertions can be extracted from the source and give a nice
> > > specification. And indeed you can use Eiffel for specifyin your problem.
>
> But then I'd rather use a logic language or a theorem prover.
This is a very good point indeed. Algorithm and Implementation
verification are things that are done better with some tools of the
Theorem Prover (Model Checker) class. This is particularly true when
you want to set up assertions regarding very complex interactions
among subsystems (distributed algorithms and real-time scheduling
problems come to mind).
The problem then becomes. Wehn do I stop having a compiler to play
with and start having a Theorem Prover?
Certainly, things like type inference are very close to this grey area.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Rainer Joswig wrote:
>
> In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>
> > Friedrich Dominicus <···················@inka.de> writes:
> >
> > > >
> > > > What exactly is "Design by Contract"?
> > >
> > > Let me give an example. The all so well known factorial. Written in an
> > > imperative style to show some extra assertions
> > > factorial(n: INTEGER): INTEGER is
> > > require
> > > n_positiv: n >= 0
> > > local
> > > i : INTEGER
> > > do
> > > Result :=1
> > > -- holds for n = 0
> > > from
> > > i:= n
> > > invariant
> > > i_positive_and_less_than_n: i >=0 and then i <= n;
> > > variant
> > > i_decreases: i
> > > until
> > > i <=1
> > > loop
> > > Result := Result * i;
> > > i := i-1
> > > end; -- from
> > >
> > > end; -- faculty
>
> I find this example particular ugly.
>
> - trivialities are expanded
It's an example. You may not find it usefule in this context but let the
package grow and you'l be very happy.
>
> - the compiler does not care a thing about the assertions at
> compile time.
> would the compiler help you to find the error of calling (factorial -3) ?
> You **could** use the subrange (integer 0) as a type for n,
> but then it is already required.
Yes you're right.
>
> - it fails to capture the pattern of iteration or recursion in any,
> instead you are writing invariants for the
> same recursive/iterative patterns in different algorithms
> over and over
That's true.
>
> - if you run it with assertions on, the code will be dead slow,
> so you turn off assertions
No not necessarily.
>
> - it fails to integrate with the error system, the
> hints that are providable to a user/developer in case of
> an error are little above zero.
> How can I continue?
It integrates very nicely with the EXCEPTION handling. You can easily
check if some piece are violated. But you insist that trivialities are
expanded so I won't do that.
>
> - the loop syntax is as bloated as Common Lisp's
Why is it bloated? It's as good or bad as others.
>
> > > This assertions can be extracted from the source and give a nice
> > > specification. And indeed you can use Eiffel for specifyin your problem.
>
> But then I'd rather use a logic language or a theorem prover.
That's up to you.
Regards
Friedrich
Friedrich Dominicus <···················@inka.de> writes:
> > - it fails to integrate with the error system, the
> > hints that are providable to a user/developer in case of
> > an error are little above zero.
> > How can I continue?
> It integrates very nicely with the EXCEPTION handling. You can easily
> check if some piece are violated. But you insist that trivialities are
> expanded so I won't do that.
The problem I found with Eiffel is it's extremely limited notion of
EXCEPTION handling. In effect, I can find out that "some piece" was
violated somewhere, but I will find it extremely difficult to find
out what exactly went wrong, where things turned sour, and what
possibilities of handling this exist. Although most other languages
suffer from weaknesses in their exception handling facilities, I
found Eiffel's capabilities in this regard among the weakest. Given
Eiffel's exception handling, the most you can do most of the time is
to try to shutdown safely (and even this can get complicated, if you
don't really know what happened). That is IMHO not enough in todays
complex environments.
To be fair to Eiffel though, I've heard that work is underway to
improve Eiffel's exception handling capabilities. And most other
languages don't get this stuff quite right either. I'd hope that more
would read Kent M. Pitman's paper on "Exceptional Situations in Lisp",
(http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html).
In effect, CL's condition system is the first exception handling
mechanism I've come across, that really gives me confidence in
handling exceptional situations in a way that allows me to be
confident of successful operation in the face of errors. With most
other languages and error handling mechanisms, I've ended up dumping
core on many ocassions.
> > - the loop syntax is as bloated as Common Lisp's
> Why is it bloated? It's as good or bad as others.
I don't find Eiffel's loop bloated, either. I do find Eiffel's
insistence on only one looping construct a bloody nuissance,
though ;)
But enough of Eiffel in c.l.l, I say, let's hear more about Lisp...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Christopher R. Barry
Subject: Re: cautios question (about languages)
Date:
Message-ID: <87wvvj1dtl.fsf@2xtreme.net>
····@acm.org (Pierre R. Mai) writes:
> In effect, CL's condition system is the first exception handling
> mechanism I've come across, that really gives me confidence in
> handling exceptional situations in a way that allows me to be
> confident of successful operation in the face of errors. With most
> other languages and error handling mechanisms, I've ended up dumping
> core on many ocassions.
In my opinion, Java also has really good, robust exception
handling. It's hard for me to say whether CL's or Java's is better
since I haven't yet been in a situation where I've really felt the
limitations of either. (Both have been very satisfactory, in other
words.)
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
...
> In my opinion, Java also has really good, robust exception
> handling. It's hard for me to say whether CL's or Java's is better
> since I haven't yet been in a situation where I've really felt the
> limitations of either. (Both have been very satisfactory, in other
> words.)
The important thing is to remember which came first.
Which begs the question: which language did sport "objectified"
exceptions first?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <·················@inka.de>, ···················@inka.de wrote:
> > - if you run it with assertions on, the code will be dead slow,
> > so you turn off assertions
>
> No not necessarily.
But "probably"?
> > - it fails to integrate with the error system, the
> > hints that are providable to a user/developer in case of
> > an error are little above zero.
> > How can I continue?
> It integrates very nicely with the EXCEPTION handling. You can easily
> check if some piece are violated. But you insist that trivialities are
> expanded so I won't do that.
The thing is, that in Common Lisp I declare the places
of restart (not everything is a useful restart),
I declare the handlers and when the error happens
an error object will be generated. This error
object than should contain the necessary information
that is needed to describe the situation.
Forms like ASSERT and CHECK-TYPE give you an
indication what went wrong and what you
can do about it to get out of that problem.
> > - the loop syntax is as bloated as Common Lisp's
> Why is it bloated? It's as good or bad as others.
It fails to support orthogonal functionality in different
syntactic constructs. Instead eveything is one big
syntactic construct - something that is difficult to analyze
(in Common Lisp, LOOP will be expanded to smaller
parts, but it may be really difficult to reconstruct what
those parts purpose was when you looking at them
in a debugger) and understand.
> > > > This assertions can be extracted from the source and give a nice
> > > > specification. And indeed you can use Eiffel for specifyin your problem.
> >
> > But then I'd rather use a logic language or a theorem prover.
> That's up to you.
See for example:
Applicative Common Lisp:
http://www.cs.utexas.edu/users/moore/acl2/v2-3/acl2-doc.html
ACL2 is both a programming language in which you can model computer
systems and a tool to help you prove properties of those models.
On Thu, 29 Jul 1999 22:13:50 +0200, Rainer Joswig wrote:
>In article <·················@inka.de>, ···················@inka.de wrote:
>> > - if you run it with assertions on, the code will be dead slow,
>> > so you turn off assertions
>> No not necessarily.
>But "probably"?
Not after they've caught even a single bug for you. Running with
assertions is WAY faster than singlestepping through code.
>It fails to support orthogonal functionality in different
>syntactic constructs. Instead eveything is one big
>syntactic construct - something that is difficult to analyze
>(in Common Lisp, LOOP will be expanded to smaller
>parts, but it may be really difficult to reconstruct what
>those parts purpose was when you looking at them
>in a debugger) and understand.
Eiffel's loop is worse -- it's very bulky, and it really only supports one
type of loop. It does, however, support loop invariants, which fits with
the purpose of the language. You can't have everything :).
>> > > > This assertions can be extracted from the source and give a nice
>> > > > specification. And indeed you can use Eiffel for specifyin your problem.
>> > But then I'd rather use a logic language or a theorem prover.
>> That's up to you.
You're right there -- a logic language would be a FAR better way to
express invariants, postconditions, and preconditions. Eiffel was merely
using a convenient form; Meyer himself said as much.
--
-William "Billy" Tanksley
Sorry I won't talk to much about Eiffel in a lisp group.
Rainer Joswig wrote:
>
> In article <·················@inka.de>, ···················@inka.de wrote:
>
> > > - if you run it with assertions on, the code will be dead slow,
> > > so you turn off assertions
> >
> > No not necessarily.
>
> But "probably"?
Not during development.
>
> The thing is, that in Common Lisp I declare the places
> of restart (not everything is a useful restart),
> I declare the handlers and when the error happens
> an error object will be generated. This error
> object than should contain the necessary information
> that is needed to describe the situation.
> Forms like ASSERT and CHECK-TYPE give you an
> indication what went wrong and what you
> can do about it to get out of that problem.
I never have claimed that there isn't room for improvment and possibly
this approach you suggested here would be a better solution for Eiffel
too. Nevertheless assertions turned out to be a very usefule development
tool.
>
> > > - the loop syntax is as bloated as Common Lisp's
> > Why is it bloated? It's as good or bad as others.
>
> It fails to support orthogonal functionality in different
> syntactic constructs. Instead eveything is one big
> syntactic construct - something that is difficult to analyze
> (in Common Lisp, LOOP will be expanded to smaller
> parts, but it may be really difficult to reconstruct what
> those parts purpose was when you looking at them
> in a debugger) and understand.
Because it's difficult there are ITERATOR classes they are not perfect
but they exist. And if you don't want to use them Loop variants and
invariants will help you to get the loop "right".
>
> See for example:
>
> Applicative Common Lisp:
> http://www.cs.utexas.edu/users/moore/acl2/v2-3/acl2-doc.html
> ACL2 is both a programming language in which you can model computer
> systems and a tool to help you prove properties of those models.
I will have a look
Regards
Friedrich
······@lavielle.com (Rainer Joswig) writes:
> In article <·················@inka.de>, ···················@inka.de wrote:
>
> > > - if you run it with assertions on, the code will be dead slow,
> > > so you turn off assertions
> >
> > No not necessarily.
>
> But "probably"?
>
I don't know that that follows. CMUCL claims that by using a slightly
smart compiler, it can have code which is both safe and fast. It does
this (it says) by pulling declarations (which it treats as assertions
general) up out of inner loops and then doing the checks only once and
relying on things it's worked out about the loop to not have to check
all the time. I presume that these dbc systems could do somewhat
similar things?
--tim
> It does
> this (it says) by pulling declarations (which it treats as assertions
> general) up out of inner loops and then doing the checks only once and
> relying on things it's worked out about the loop to not have to check
> all the time. I presume that these dbc systems could do somewhat
> similar things?
It very depend (in Eiffel) I you use loop variants and/or loop
invariants it have to be checked any time that the conditions hold. But
probably I got you wrong?
I don't know how any language could change that without checking.
BTW the original question was learning Scheme, CL (either of one, both,
just one (which?)
The DBC was put into discussion as a question from my side if that
wouldn't make sense in CL too.
Regards
Friedrich
>
> --tim
In article <·················@inka.de>, ···················@inka.de wrote:
> BTW the original question was learning Scheme, CL (either of one, both,
> just one (which?)
Learn atleast one. ;-) Scheme and CL are both a good choice.
It is advisable to get some real programming experience, though.
What is your decision?
Rainer Joswig wrote:
>
> In article <·················@inka.de>, ···················@inka.de wrote:
>
> > BTW the original question was learning Scheme, CL (either of one, both,
> > just one (which?)
>
> Learn atleast one. ;-) Scheme and CL are both a good choice.
> It is advisable to get some real programming experience, though.
>
> What is your decision?
Haskell ;), just kidding. I thought about doing some scripting with scsh
but some answers on my question on that were answered in CL so I think
probably one can use CL for scripting too.
I have downloaded me now some Common Lisps and the Hyperspec. So I'll
try to find my way throught that document and after that I may decide to
switch do CL or trying to learn both.
I just wonder if I get used in one that switching is easily. Not that
the knowledge I get interfers with what is necessary on the other side.
At the moment I do know way to less to make a somewhat sound decision.
So to be on the safe side it may be a good idea to have a look at Scheme
and CLOS. Solve simular problems with them and try to read some code
from fluent CL-Speakers of Schemers.
Regards
Friedrich
In article <·················@inka.de>, ···················@inka.de wrote:
> > I find this example particular ugly.
> >
> > - trivialities are expanded
>
> It's an example. You may not find it usefule in this context but let the
> package grow and you'l be very happy.
To give you a version in Common Lisp (using the SERIES package):
I'd be happy with code like this:
(defun fak (n)
(check-type n (integer 0))
(series:collect-fn 'integer
(lambda () 1)
#'*
(series:scan-range :from 1 :upto n)))
It checks it's entry args and otherwise
you build the iteration out of basic iteration building blocks.
More readable code than this you will not get, I mean
it really says what your iteration should do (not how).
The resulting code actually is something
with a GOTO (!).
The series form expanded looks like this:
(COMMON-LISP:LET ((#:C-2083 0) (#:NUMBERS-2089 0) #:OUT-2085 #:OUT-2091)
(DECLARE (TYPE NUMBER #:NUMBERS-2089) (TYPE INTEGER #:C-2083))
(SETQ #:OUT-2085 (LAMBDA NIL 1))
(SETQ #:OUT-2091 N)
(SETQ #:NUMBERS-2089 (- 1 1))
(SETQ #:C-2083 (COMMON-LISP:FUNCALL #:OUT-2085))
(TAGBODY
#:LL-2093 (SETQ #:NUMBERS-2089 (+ #:NUMBERS-2089 1))
(IF (> #:NUMBERS-2089 #:OUT-2091) (GO SERIES::END))
(SETQ #:C-2083 (* #:C-2083 #:NUMBERS-2089))
(GO #:LL-2093)
SERIES::END)
#:C-2083)
If you call (fak -1) you get:
? (fak -1)
> Error: value -1 is not of the expected type (INTEGER 0).
> While executing: CCL::ENSURE-VALUE-OF-TYPE
> Type Command-. to abort.
See the Restarts... menu item for further choices.
1 > (compute-restarts)
(#<RESTART ABORT #x6BB2A06> #<RESTART ABORT-BREAK #x6BB2A2E>
#<RESTART STORE-VALUE #x6BB2C06> #<RESTART ABORT #x6BB2DCE>
#<RESTART ABORT-BREAK #x6BB2DF6> #<RESTART ABORT #x6BB2F66>
#<RESTART ABORT-BREAK #x6BB2F8E>)
1 > (invoke-restart-interactively (third (compute-restarts)))
Invoking restart: Assign a new value of type (INTEGER 0) to N
New value for N :4
24
Writing a similar style in Eiffel is atleast difficult:
- you got no macros
- you got no higher-order functions
- no tail recursion removal (?), so no efficient recursive
version
Btw., you can learn more about the series package
in CLtL2, Appendix A. For similar stuff see
SICP under "Streams".
Rainer Joswig wrote...
>(defun fak (n)
> (check-type n (integer 0))
> (series:collect-fn 'integer
> (lambda () 1)
> #'*
> (series:scan-range :from 1 :upto n)))
>More readable code than this you will not get, I mean
>it really says what your iteration should do (not how).
how about:
fact n = product [1..n]
In article <············@news6.svr.pol.co.uk>, "CsO" <···@mindless.com> wrote:
> Rainer Joswig wrote...
> >(defun fak (n)
> > (check-type n (integer 0))
> > (series:collect-fn 'integer
> > (lambda () 1)
> > #'*
> > (series:scan-range :from 1 :upto n)))
> >More readable code than this you will not get, I mean
> >it really says what your iteration should do (not how).
>
>
> how about:
> fact n = product [1..n]
It might be doing something similar.
Let guess:
= is a function definition operator
"product " is something where * is being used to reduce the list
it might even return 1 for (zerop n)
Well, if you want to have a funny *syntax* in Lisp you can have
that, too:
? (let ((xs '(1 2 3 4 5 6 7 8)))
[x (x <- xs) (oddp x)])
(1 3 5 7)
or
(define fak (n)
0 => 1
_ => (* n (fak (1- n))))
or ...
"CsO" <···@mindless.com> writes:
> Rainer Joswig wrote...
> >(defun fak (n)
> > (check-type n (integer 0))
> > (series:collect-fn 'integer
> > (lambda () 1)
> > #'*
> > (series:scan-range :from 1 :upto n)))
> >More readable code than this you will not get, I mean
> >it really says what your iteration should do (not how).
>
>
> how about:
> fact n = product [1..n]
(defun fact (n)
(reduce #'* (rest (iota n)) :initial-value 1))
REDUCE is part of CL. IOTA is below
(defun iota (n)
(loop for i from 0 upto n collect i))
You can argue about how to write IOTA and what arguments it should
take. E.g. If I started from collecting from 1 I would have not needed
the REST in FACT.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <37A17E29.47FF9478@iname.com>
Marco Antoniotti wrote:
> (defun fact (n)
> (reduce #'* (rest (iota n)) :initial-value 1))
>
> REDUCE is part of CL. IOTA is below
>
> (defun iota (n)
> (loop for i from 0 upto n collect i))
VADE RETRO!
**ALARM** LIST-FOR-SERIES ANTIPATTERN!
Fernando Mato Mira <········@iname.com> writes:
> Marco Antoniotti wrote:
>
> > (defun fact (n)
> > (reduce #'* (rest (iota n)) :initial-value 1))
> >
> > REDUCE is part of CL. IOTA is below
> >
> > (defun iota (n)
> > (loop for i from 0 upto n collect i))
>
> VADE RETRO!
>
> **ALARM** LIST-FOR-SERIES ANTIPATTERN!
int* iota(int n)
{
int* r = malloc(n + 1);
int i;
for (i = 0; i <= n; i++)
r[i] = i;
return i;
}
I could also write this with the style advocated in NRC (removing
spaces) . Shall I do that? :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <37A1A99D.C3351E2A@iname.com>
Marco Antoniotti wrote:
> Fernando Mato Mira <········@iname.com> writes:
>
> > Marco Antoniotti wrote:
> >
> > > (defun fact (n)
> > > (reduce #'* (rest (iota n)) :initial-value 1))
> > >
> > > REDUCE is part of CL. IOTA is below
> > >
> > > (defun iota (n)
> > > (loop for i from 0 upto n collect i))
> >
> > VADE RETRO!
> >
> > **ALARM** LIST-FOR-SERIES ANTIPATTERN!
>
> int* iota(int n)
> {
> int* r = malloc(n + 1);
> int i;
>
> for (i = 0; i <= n; i++)
> r[i] = i;
>
> return i;
> }
>
> I could also write this with the style advocated in NRC (removing
> spaces) . Shall I do that? :)
You forgot free(r) ;->>>>>>>
In article <·················@iname.com>, Fernando Mato Mira <········@iname.com> wrote:
> Marco Antoniotti wrote:
>
> > (defun fact (n)
> > (reduce #'* (rest (iota n)) :initial-value 1))
> >
> > REDUCE is part of CL. IOTA is below
> >
> > (defun iota (n)
> > (loop for i from 0 upto n collect i))
>
> VADE RETRO!
>
> **ALARM** LIST-FOR-SERIES ANTIPATTERN!
Is there any compiler or partial evaluator that could
optimize this consing away? Would "Stalin" (Scheme)
find such a thing?
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <37A1B643.BCAC1FAD@iname.com>
Rainer Joswig wrote:
> In article <·················@iname.com>, Fernando Mato Mira <········@iname.com> wrote:
>
> > Marco Antoniotti wrote:
> >
> > > (defun fact (n)
> > > (reduce #'* (rest (iota n)) :initial-value 1))
> > >
> > > REDUCE is part of CL. IOTA is below
> > >
> > > (defun iota (n)
> > > (loop for i from 0 upto n collect i))
> >
> > VADE RETRO!
> >
> > **ALARM** LIST-FOR-SERIES ANTIPATTERN!
>
> Is there any compiler or partial evaluator that could
> optimize this consing away? Would "Stalin" (Scheme)
> find such a thing?
I don't know. One thing's for sure: I wouldn't write code that requires unusual compiler
smarts to avoid sloppy performance.
I should take a look at that #Z. There's no reason why one could not write (a la Haskell):
#Z(1 step .. n)
so that then
(defun fact (n)
(series:collect-fn 'integer (lambda () 1) #'* #Z(1 .. n)))
or even use
(defun series-reduce (typ f z &key :initial-value)
(series:collect-fn typ (lambda () initial-value) f z))
and then
(defun fact (n)
(series:reduce 'integer #'* #Z(1 .. n) :initial-value 1))
And what about the counterpart to COLLECT-SUM ?
(defS collect-product (numbers &optional (type 'number))
"Computes the product of the elements in NUMBERS."
(fragL ((numbers T) (type)) ((res)) ((res T)) ()
((setq res (coerce 1 type)))
((setq res (* res numbers))) () ())
:optimizer
(funcall-literal-frag
`((((numbers T)) ((res)) ((res ,(must-be-quoted type))) ()
((setq res ,(coerce 1 (must-be-quoted type))))
((setq res (* res numbers))) () ())
,numbers))
:trigger T)
WHOA!! OK. Try this:
(defun collect-product (items &optional (typ 'number))
(declare (optimizable-series-function))
(collect-fn typ (lambda () 1) #'* items))
then
(defun fact (n)
(collect-product #Z(1 .. n)))
didn't someone say
fact n = product [1 .. n]
?
> > > > (defun fact (n)
> > > > (reduce #'* (rest (iota n)) :initial-value 1))
> > > >
> > > > (defun iota (n)
> > > > (loop for i from 0 upto n collect i))
> > Is there any compiler or partial evaluator that could
> > optimize this consing away? Would "Stalin" (Scheme)
> > find such a thing?
No, not yet at least. This requires an unfold-fold transformation which Stalin
doesn't yet do.
Jeff (http://www.neci.nj.nec.com/homepages/qobi)
Marco Antoniotti wrote:
> (defun fact (n)
> (reduce #'* (rest (iota n)) :initial-value 1))
>
> (defun iota (n)
> (loop for i from 0 upto n collect i))
Fernando Mato Mira wrote:
> **ALARM** LIST-FOR-SERIES ANTIPATTERN!
Surely it's no big deal in this case? The consing involved in computing
n! is similar to the consing in building the list, so there's no
complexity improvement by rewriting the reduce as a loop.
--
Gareth Rees
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <37A1B739.9B1229D4@iname.com>
Gareth Rees wrote:
> Marco Antoniotti wrote:
> > (defun fact (n)
> > (reduce #'* (rest (iota n)) :initial-value 1))
> >
> > (defun iota (n)
> > (loop for i from 0 upto n collect i))
>
> Fernando Mato Mira wrote:
> > **ALARM** LIST-FOR-SERIES ANTIPATTERN!
>
> Surely it's no big deal in this case? The consing involved in computing
> n! is similar to the consing in building the list, so there's no
> complexity improvement by rewriting the reduce as a loop.
Consing in looping? Why?
Marco Antoniotti wrote:
> (defun fact (n)
> (reduce #'* (rest (iota n)) :initial-value 1))
>
> (defun iota (n)
> (loop for i from 0 upto n collect i))
Fernando Mato Mira wrote:
> **ALARM** LIST-FOR-SERIES ANTIPATTERN!
Gareth Rees wrote:
> Surely it's no big deal in this case? The consing involved in computing
> n! is similar to the consing in building the list, so there's no
> complexity improvement by rewriting the reduce as a loop.
Fernando Mato Mira wrote:
> Consing in looping? Why?
No, consing in multiplying. Representing n! takes about n log n storage
(since n! is about n^n, which takes about (n log n / log b) digits to
represent in base b).
--
Gareth Rees
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <37A1CC12.193B3769@iname.com>
Gareth Rees wrote:
> No, consing in multiplying. Representing n! takes about n log n storage
> (since n! is about n^n, which takes about (n log n / log b) digits to
> represent in base b).
But that's an O trick! This is The Real World (TM).
So reducing takes 8n + 4n + n log n space. The n log n can be in "no pointers
space".
Assuming n is fixnum, a (vector fixnum) would be better. One 4n goes. But if
those fixnums
are not actually inside the vector, it's quite different for GC.
But let's concede this case. The point is that you don't want to do that
everywhere (see how Marco is happy reducing in comp.lang.tcl ;-) Of course,
the objective there is different).
Use the same technique everywhere, and the constants add up.
This is a newbie thread, so it's important to point out this kind of things.
You came up with an important point: "Don't waste time optimizing what will
turn out to be irrelevant later".
Unfortunately this case falls under the "If two approaches of equivalent
conceptual complexity exist, and one is safer, go for that one" (if both are
`safer' in different ways, you'll have to choose.
[Of course, some people will say using SERIES is not `safe'. Well, if people
keep avoiding using it, how is it going to improve?
It's the same kind of paranoia as not using Lisp because `it is dying', `it
is slow', or `it is strange'].
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>
> > "CsO" <···@mindless.com> writes:
> >
> > > Rainer Joswig wrote...
> > > >(defun fak (n)
> > > > (check-type n (integer 0))
> > > > (series:collect-fn 'integer
> > > > (lambda () 1)
> > > > #'*
> > > > (series:scan-range :from 1 :upto n)))
> > > >More readable code than this you will not get, I mean
> > > >it really says what your iteration should do (not how).
> > >
> > >
> > > how about:
> > > fact n = product [1..n]
> >
> > (defun fact (n)
> > (reduce #'* (rest (iota n)) :initial-value 1))
> >
> > REDUCE is part of CL. IOTA is below
> >
> > (defun iota (n)
> > (loop for i from 0 upto n collect i))
>
> looks good, slight drawback: It conses.
How would you write a IOTA (of APL vintage) that does not cons? The
spec of IOTA is "given a number N returns a <sequence> of integer from
0 to N". Somowhere sometime you must allocate this sequence.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> How would you write a IOTA (of APL vintage) that does not cons? The
> spec of IOTA is "given a number N returns a <sequence> of integer from
> 0 to N". Somowhere sometime you must allocate this sequence.
>
> Cheers
Sorry, my remark was about FACT using REDUCE+IOTA.
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> > looks good, slight drawback: It conses.
>
> How would you write a IOTA (of APL vintage) that does not cons? The
> spec of IOTA is "given a number N returns a <sequence> of integer from
> 0 to N". Somowhere sometime you must allocate this sequence.
To do it without consing, you would need either a language that
supports lazy evaluation (but this has non-trivial costs in itself,
so you probably wouldn't gain much in speed overall), or you would
need a compiler that would recognize the producer/consumer
relationship between iota and e.g. reduce, and would transform it into
an interleaved iteration. Since this is non-trivial in the general
case, something like Aspect-Oriented Programming would probably be
helpful (see "RG: A Case-Study for Aspect-Oriented Programming",
Mendhekar, Kiczales, Lamping, Xerox PARC Technical Report SPL97-009
P9710044, February 1997. Available on-line somewhere on the AOP
homepage at http://www.parc.xerox.com/spl/projects/aop/).
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
* Pierre R Mai wrote:
> To do it without consing, you would need either a language that
> supports lazy evaluation (but this has non-trivial costs in itself,
> so you probably wouldn't gain much in speed overall), or you would
> need a compiler that would recognize the producer/consumer
> relationship between iota and e.g. reduce, and would transform it into
> an interleaved iteration.
Note that this is more-or-less what the SERIES package for CL does.
--tim
····@acm.org (Pierre R. Mai) writes:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > > looks good, slight drawback: It conses.
> >
> > How would you write a IOTA (of APL vintage) that does not cons? The
> > spec of IOTA is "given a number N returns a <sequence> of integer from
> > 0 to N". Somowhere sometime you must allocate this sequence.
>
> To do it without consing, you would need either a language that
> supports lazy evaluation (but this has non-trivial costs in itself,
> so you probably wouldn't gain much in speed overall), or you would
> need a compiler that would recognize the producer/consumer
> relationship between iota and e.g. reduce, and would transform it into
> an interleaved iteration. Since this is non-trivial in the general
> case, something like Aspect-Oriented Programming would probably be
> helpful (see "RG: A Case-Study for Aspect-Oriented Programming",
> Mendhekar, Kiczales, Lamping, Xerox PARC Technical Report SPL97-009
> P9710044, February 1997. Available on-line somewhere on the AOP
> homepage at http://www.parc.xerox.com/spl/projects/aop/).
>
Al right, if you pull in all of these tricks I believe that you can
get away with it. However, even the RG example is somewhat misleading
(at least to me). You basically assume that your compiler can di
certain things and then you write your code in a specific way. That
is to say, even with an AOP system in place, you still need to think
about how to do things in the right way (first) and the optimize them
(afterward). If you can optimize things to start with (e.g. using a
O(n lg n) algorithm over a O(n^2)), that's extra fat off the goose. :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> Al right, if you pull in all of these tricks I believe that you can
> get away with it. However, even the RG example is somewhat misleading
> (at least to me). You basically assume that your compiler can di
> certain things and then you write your code in a specific way. That
> is to say, even with an AOP system in place, you still need to think
> about how to do things in the right way (first) and the optimize them
> (afterward). If you can optimize things to start with (e.g. using a
> O(n lg n) algorithm over a O(n^2)), that's extra fat off the goose. :)
AOP addresses only the part of optimization and programming, that cuts
across different layers and components of your (OO) design. I.e. if
you can just as well use an algorithm with O(n lg n) instead of O(n^2)
_without_ violating the abstraction barriers of your components, then
go ahead and do it. As the RG example illustrates however, when the
only way to be really efficient involves cutting across those barriers
(thereby scattering optimizations and knowledge about them across all
of your code, making your code and maintenance thereof really ugly),
you are better off doing AOP.
With iota, you are in a similar situation: It can be argued, that
most numerical computation are done "right" through the use of
(possibly infinite) sets, and manipulations thereof. The definition
of fac is only a small example where the "naive" implementation with
iota and reduce is the most natural way of expressing things. But
once you get to larger problems, this way of doing things really pays
of. OTOH, this is difficult to impossible to get efficient the normal
way. So you have to have compiler support to make it more efficient,
either in the form of lazy evaluation support, or probably better,
some specialized AOP system and transformation code.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
····@acm.org (Pierre R. Mai) writes:
> AOP addresses only the part of optimization and programming, that cuts
> across different layers and components of your (OO) design. I.e. if
> you can just as well use an algorithm with O(n lg n) instead of O(n^2)
> _without_ violating the abstraction barriers of your components, then
> go ahead and do it. As the RG example illustrates however, when the
> only way to be really efficient involves cutting across those barriers
> (thereby scattering optimizations and knowledge about them across all
> of your code, making your code and maintenance thereof really ugly),
> you are better off doing AOP.
>
> With iota, you are in a similar situation: It can be argued, that
> most numerical computation are done "right" through the use of
> (possibly infinite) sets, and manipulations thereof. The definition
> of fac is only a small example where the "naive" implementation with
> iota and reduce is the most natural way of expressing things. But
> once you get to larger problems, this way of doing things really pays
> of. OTOH, this is difficult to impossible to get efficient the normal
> way. So you have to have compiler support to make it more efficient,
> either in the form of lazy evaluation support, or probably better,
> some specialized AOP system and transformation code.
I agree with all of the above. And I like the idea of AOP. My point
is that - at least in the RG example - the key idea is the
intrioduction of things like PIXEL-WISE. This is not something that
comes for free. It is something that AOP allows you to express in a
nice way, pretty much like the SERIES package allows you to express a
IOTA-based computation without consing.
If you like AOP is a generalization of SERIES.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> I agree with all of the above. And I like the idea of AOP. My point
> is that - at least in the RG example - the key idea is the
> intrioduction of things like PIXEL-WISE. This is not something that
> comes for free. It is something that AOP allows you to express in a
> nice way, pretty much like the SERIES package allows you to express a
> IOTA-based computation without consing.
Yes, in a way we have often been blinded to "natural" solutions,
because we know the costs, and prematurely optimize out those natural,
but clearly impractical solutions. With AOP, maybe we have to relearn
to use the natural, naive and impractical solutions. Something
similar has been experienced by people moving from strict to lazy
functional languages.
> If you like AOP is a generalization of SERIES.
I'd put it the other way round (though historically, series precedes
AOP): The SERIES package is an instance of AOP at work. I'd say that
AOP is a generalization of (via OI) of MOPs, which are a generalization
(and globalization, in effect), of advanced Lisp-like macrology.
> Cheers
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
CsO wrote:
> how about:
> fact n = product [1..n]
I'm trying now to put together a little library of functions for
set theory and combinatorics in Lisp and I find it amazing how
easy this is. Being able to write abstract concepts, as the cartesian
product, in four lines, is very impressive.
There are so many mathematical functions predefined, but a very
fundamental one lacks. This is a function which generates a list
of numbers, especially 0 1 ... n.
A mathematician creates everything around this function. I wrote
one in Lisp and using macro characters I can now write [4 10].
I use this all day.
Probably the speed of this function is not so decisive, but it
could unify style. Often it is a good substitute for loop.
Comparing
(defun old-factorial (n)
(do ((f 1 (* f k)) (k 1 (+ k 1)))
((> k n) f)))
and
(defun new-factorial (n)
(if (= 0 n) 1 (reduce #'* [1 n])))
I obtain (not compiled)
Real time: 4.952857 sec.
Run time: 4.96 sec.
Space: 15876312 Bytes
GC: 30, GC time: 2.17 sec.
with (time (old-factorial 5000)) and
Real time: 3.186444 sec.
Run time: 3.14 sec.
Space: 15916312 Bytes
GC: 31, GC time: 0.69 sec.
with (time (new-factorial 5000)), being
Real time: 0.307474 sec.
Run time: 0.31 sec.
Space: 40264 Bytes
for (time [0 5000]).
After -C on CLisp all become around 10 times faster, with the
old factorial now being a little quicker than the new one.
Another newbie question: Why do these functions, for example the first
one, which is a simple iteration, consume so much space? I can only
imagine that all those 5000 values of f remain in memory, but I find
this very strange.
What means GC?
je
Josef Eschgfaeller wrote: [1999-07-30 12:01 +0000]
[...]
> Comparing
>
> (defun old-factorial (n)
> (do ((f 1 (* f k)) (k 1 (+ k 1)))
> ((> k n) f)))
>
> and
>
> (defun new-factorial (n)
> (if (= 0 n) 1 (reduce #'* [1 n])))
>
> I obtain (not compiled)
>
> Real time: 4.952857 sec.
> Run time: 4.96 sec.
> Space: 15876312 Bytes
> GC: 30, GC time: 2.17 sec.
>
> with (time (old-factorial 5000)) and
>
> Real time: 3.186444 sec.
> Run time: 3.14 sec.
> Space: 15916312 Bytes
> GC: 31, GC time: 0.69 sec.
>
> with (time (new-factorial 5000)), being
>
> Real time: 0.307474 sec.
> Run time: 0.31 sec.
> Space: 40264 Bytes
>
> for (time [0 5000]).
> After -C on CLisp all become around 10 times faster, with the
> old factorial now being a little quicker than the new one.
>
> Another newbie question: Why do these functions, for example the first
> one, which is a simple iteration, consume so much space? I can only
> imagine that all those 5000 values of f remain in memory, but I find
> this very strange.
Nothing strange at all. All those value of N! for N up to 5000 do require
memory space (most of them are bignums, i.e. integers too large to fit
within a machine word, but nevertheless representable in Lisp; please
note that arithmetic operations on integers in Lisp do *not* overflow
as the system goes from small integers (a.k.a. fixnums, which fit
within a machine word) to bignums and back automatically and
transparently).
> What means GC?
Garbage Collection, i.e. automatic reclamation of memory that has been
allocated but is no longer in actual use. A Very Good Thing.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
> I'd be happy with code like this:
>
> (defun fak (n)
> (check-type n (integer 0))
> (series:collect-fn 'integer
> (lambda () 1)
> #'*
> (series:scan-range :from 1 :upto n)))
I agree, this example is quite nice.
>
> 1 > (invoke-restart-interactively (third (compute-restarts)))
> Invoking restart: Assign a new value of type (INTEGER 0) to N
> New value for N :4
> 24
>
> Writing a similar style in Eiffel is atleast difficult:
It isn't at all difficult here. You can catch the exception raise your
own and ask for valid input and then you just type retry.
>
> - you got no macros
Correct.
>
> - you got no higher-order functions
Unfortunatly not, I see this as on big disadvantage or Eiffel.
>
> - no tail recursion removal (?), so no efficient recursive
> version
Correct, but most Eiffel programmers won't use recursion here.
Regards
Friedrich
[Eiffel]
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> What exactly is "Design by Contract"?
The DbC school of system design makes heavy use of pre-conditions,
post-conditions, invariants and so on.
When using a DbC system, all these are given to the system in a way
that it can understand and check. Check on compile-time if possible,
on run-time if not.
An Eiffel person might give more detail but these are the essentials.
Stig Hemmer,
Jack of a Few Trades.
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <379F2305.B9CED065@iname.com>
Stig Hemmer wrote:
> [Eiffel]
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> > What exactly is "Design by Contract"?
>
> The DbC school of system design makes heavy use of pre-conditions,
> post-conditions, invariants and so on.
>
> When using a DbC system, all these are given to the system in a way
> that it can understand and check. Check on compile-time if possible,
> on run-time if not.
>
> An Eiffel person might give more detail but these are the essentials.
Then she would have to learn the MOP and implement a new method
combination (a macro layer :before, :after, :around methods should work,
but if you're also using those..)
Friedrich Dominicus <···················@inka.de> writes:
> I have try to find out myself and checked some Scheme and Lisp pages.
> But althought I'm sure this question was asked a hundred times before, I
> wasn't able to figure it out.
>
> It's about Scheme and Common Lisp. Does it make sense to learn one or
> the other, or both, or just one of it?
The two languages are quite different in terms of how they are used,
what programming styles they promote, what community of users they
attract, the capabilities they offer, and the overall language focus.
You ask an extraordinarily subjective question, but you offer enough
about yourself to answer in a way that is probably best for you. Please
do not repeat this answer to anyone else; send them instead back to this
group and let them get their own answer based on their own needs.
> ... the elegance of Scheme begins to shine ...
If elegance is what you seek in a language, my take is that you're
likely better off with Scheme. That's not because Scheme is a better
(or worse) language. It's because it was mostly designed by and for
people who, when faced with a decision between a choice of doing
something "a practical way" or "an elegant way", chose the elegant
way. CL is more concerned with practicality than elegance in the case
where the two compete. Often CL is elegant anyway, but sometimes it
is not. Often Scheme is practical anyway, but sometimes it is not.
free of any commercial constraint as a programming language can be.
We all want elegant, and we all want practical. But sometimes push
comes to shove and we have to decide between them. The difference
between the two languages shows itself ways that stem from the
resolution of conflicts. Languages are like political parties; you
should choose the one that is maintained by people who think like
you do and care about the things you care about. It sounds, based on
your brief summary like that would be the Scheme crowd.
Of course, my opinion is just that of one person. Others might view
the situation differently. Good luck making your choice.
If in the end you're note sure, I'm sure you won't be harmed by learning
both. But please don't hold them to the same standards. Languages
should be judged by what they seek to do, not by their sameness to
each other.
In article <···············@world.std.com>, Kent M Pitman <······@world.std.com> wrote:
> The two languages are quite different in terms of how they are used,
> what programming styles they promote, what community of users they
> attract, the capabilities they offer, and the overall language focus.
Scheme tries to grow up. People are using Scheme for
systems programming. MIT Scheme is quite a large environment.
Some Scheme systems are now running on bare machines.
Scheme libs now give similar power like Common Lisp.
Scheme often has for experiments the advantage that
it is easier to move around (-> you need fewer people).
What the Common Lisp community needs (IMHO, -> see the "MIT List"),
is a small Common Lisp core (incl. threads and networking).
The small core then could be moved around (different platforms,
distributed computing, web stuff, new compilers, ...) much faster.
It also could be the kernel for a new operating system.
······@lavielle.com (Rainer Joswig) writes:
> Scheme tries to grow up. People are using Scheme for
> systems programming. MIT Scheme is quite a large environment.
I have a lot of respect for the scheme vendors generally, who have
worked hard to be more than what the Scheme standard is. The
language designers, I think, often hold them back. As a language,
Scheme stagnated long ago, barely able to change because everyone's
differing notion of what's elegant or necessary or important drags
the language in a different direction such that "consensus" isn't
very easy on any kind of change. Any individual vendor, through
extensions they just decide for themselves, does better.
CL has done slightly better, IMO, because the members come to the
table with an understanding that concessions to practicality will be
in the language proper. And so the language is able to evolve, even
if slowly. The slowness less reflects a willingness of the
participants to change as it does the slowness of the bodies which
bless the change as "official"; that is, slowness is more dictated by
ANSI and NCITS than by CL people per se. A bit of it is dictated by
budget, too. But some of the reasons budget is an issue is that
ANSI and NCITS also make the process hugely expensive in ways that
some might argue are not needed. Then again, the absence of the
procedural mechanisms ANSI and NCITS provide might leave the committee
deadlocked like the Scheme committee, with no way to force motion forward.
The world is complicated.
In article <···············@world.std.com>, Kent M Pitman <······@world.std.com> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > Scheme tries to grow up. People are using Scheme for
> > systems programming. MIT Scheme is quite a large environment.
>
> I have a lot of respect for the scheme vendors generally, who have
> worked hard to be more than what the Scheme standard is.
Scheme users are currently discussing various extensions
to Scheme. See:
http://srfi.schemers.org/
Scheme Requests for Implementation
The "Scheme Requests for Implementation" (SRFI) process is a new
approach to helping Scheme users to write portable and yet
useful code. It is a forum for people interested in coordinating
libraries and other additions to the Scheme language
between implementations.
> CL has done slightly better, IMO, because the members come to the
> table with an understanding that concessions to practicality will be
> in the language proper.
Yes, and we owe that to persons like you who had put
a lot of work into that - we are standing on your shoulders. :-)
Now we have to add some weight.
> some might argue are not needed. Then again, the absence of the
> procedural mechanisms ANSI and NCITS provide might leave the committee
> deadlocked like the Scheme committee, with no way to force motion forward.
As I understand Scheme currently has IEEE, ANSI and ISO standards.
······@lavielle.com (Rainer Joswig) writes:
> In article <···············@world.std.com>, Kent M Pitman <······@world.std.com> wrote:
>
> > ······@lavielle.com (Rainer Joswig) writes:
> >
> > > Scheme tries to grow up. People are using Scheme for
> > > systems programming. MIT Scheme is quite a large environment.
> >
> > I have a lot of respect for the scheme vendors generally, who have
> > worked hard to be more than what the Scheme standard is.
>
> Scheme users are currently discussing various extensions
> to Scheme. See:
>
> http://srfi.schemers.org/
>
> Scheme Requests for Implementation
>
> The "Scheme Requests for Implementation" (SRFI) process is a new
> approach to helping Scheme users to write portable and yet
> useful code. It is a forum for people interested in coordinating
> libraries and other additions to the Scheme language
> between implementations.
As a matter of fact I believe that the SRFI is a rather good mechanism
for adding things to the language in a "regular" way. Of course, ther
is so much more to add to Scheme that a lot of work needs to be done
there. Re-inventing the wheel takes time :)
I would favor something like a CLAN ("Common Lisp Added Newness" :) -
for lack of a better acronym). With clear coding and documentation
standards that would invite people to provide implementations for
relatively small features/packages given an appropriate specification
first. An integrated REGEX (I know there are many such packages
around) would be an example of the size of the projects to be part of
this effort. I.e. an implementation of CLIM would not be within the
scope of this enterprise. Have a look at the SRFIs to have an idea.
>
> > CL has done slightly better, IMO, because the members come to the
> > table with an understanding that concessions to practicality will be
> > in the language proper.
>
> Yes, and we owe that to persons like you who had put
> a lot of work into that - we are standing on your shoulders. :-)
> Now we have to add some weight.
>
> > some might argue are not needed. Then again, the absence of the
> > procedural mechanisms ANSI and NCITS provide might leave the committee
> > deadlocked like the Scheme committee, with no way to force motion forward.
>
> As I understand Scheme currently has IEEE, ANSI and ISO standards.
Yes. Maybe. They all lack multidimensional arrays and
records/structures. It is easy to get standards down to 50 pages if
you leave out useful things.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Rainer Joswig wrote:
> Yes, and we owe that to persons like you who had put
> a lot of work into that - we are standing on your shoulders. :-)
> Now we have to add some weight.
Ouch!
--
Gareth McCaughan ················@pobox.com
sig under construction
>>>>> On Wed, 28 Jul 1999 21:32:43 +0200,
······@lavielle.com (Rainer Joswig) said:
Rainer> As I understand Scheme currently has IEEE, ANSI and ISO
Rainer> standards.
According to http://www.schemers.org/, the IEEE standard is due to
expire this year and it appears that no one has picked up the ball to
revise it (which is required to prevent expiration).
Will Clinger has offered to advise anyone interested in the job, and I
have given thought to stepping up to the plate. Presently, I'm
inclined not to volunteer for the job, as I am very good at starting
things but not so good at finishing them...
--
Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <37A4C06B.2BDE96BD@iname.com>
Matt Curtin wrote:
> According to http://www.schemers.org/, the IEEE standard is due to
> expire this year and it appears that no one has picked up the ball to
> revise it (which is required to prevent expiration).
Yeah!! ;->
Matt Curtin <········@interhack.net> writes:
> According to http://www.schemers.org/, the IEEE standard is due to
> expire this year and it appears that no one has picked up the ball to
> revise it (which is required to prevent expiration).
What would the practical consequences be of the standard expiring?
Stig Hemmer,
Jack of a Few Trades.
Stig Hemmer <····@pvv.ntnu.no> writes:
> Matt Curtin <········@interhack.net> writes:
> > According to http://www.schemers.org/, the IEEE standard is due to
> > expire this year and it appears that no one has picked up the ball to
> > revise it (which is required to prevent expiration).
>
> What would the practical consequences be of the standard expiring?
Yeah, this is kinda like having your "membership" in the American
Express Card run out.... Gives the telemarketers an excuse to churn
the customer base.
From: Christopher R. Barry
Subject: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <87wvvkfpti.fsf_-_@2xtreme.net>
······@lavielle.com (Rainer Joswig) writes:
> What the Common Lisp community needs (IMHO, -> see the "MIT List"),
> is a small Common Lisp core (incl. threads and networking).
> The small core then could be moved around (different platforms,
> distributed computing, web stuff, new compilers, ...) much faster.
> It also could be the kernel for a new operating system.
Richard Gabriel in the Worse Is Better paper as well as John Mallery
in a semi-recent post to the X3J13 list both call for a core Lisp.
(Mallery seemed to want everything under the sun in Lisp in that
post--numerous rediculously difficult and unrealistic things.) In my
view, there's less rationale for a core Lisp than against and I don't
see how one would really help the community and vendors.
You already can write a Common Lisp in Common Lisp and only have to
bootstrap a small subset of Common Lisp to define and compile the
rest.[1] What good does standardizing what this core should be really
do? It takes away flexibility and optimization oportunities from the
vendors.
Christopher
1. Though black magic and weird circular dependencies like things like
functions that only implement enough functionality to compile exactly
what they need to before being redefined and recompiled by the
functions they helped compile like you see so much of in CMU CL make
testing out changes and experimenting _impossible_. I'd like to help
out with the CMU CL effort but the damn thing is so frustratingly
impossible to rebuild if you change or modify anything interesting and
I just don't have time right now to learn every last in and out of how
it compiles itself so I can get it to rebuild after
interesting/important modifications.
In article <·················@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> Richard Gabriel in the Worse Is Better paper as well as John Mallery
> in a semi-recent post to the X3J13 list both call for a core Lisp.
> (Mallery seemed to want everything under the sun in Lisp in that
> post--numerous rediculously difficult and unrealistic things.)
(with-irony
Yeah, I thought you had a qualified comment on that.)
> In my
> view, there's less rationale for a core Lisp than against and I don't
> see how one would really help the community and vendors.
This doesn't mean that others see it.
A few possible applications:
- you could run it on bare PCs
- you could run it in switches
- you could run it as networking nodes running web servers, ...
- you could use it on board of a space ship
- you could put it on robots
- you could put it in a game console
- ...
> You already can write a Common Lisp in Common Lisp and only have to
> bootstrap a small subset of Common Lisp to define and compile the
> rest.[1] What good does standardizing what this core should be really
> do? It takes away flexibility and optimization oportunities from the
> vendors.
>
> Christopher
>
> 1. Though black magic and weird circular dependencies like things like
> functions that only implement enough functionality to compile exactly
> what they need to before being redefined and recompiled by the
> functions they helped compile like you see so much of in CMU CL make
> testing out changes and experimenting _impossible_. I'd like to help
> out with the CMU CL effort but the damn thing is so frustratingly
> impossible to rebuild
(with-iteration
How about a smaller core Lisp, that would be easier
to build and move around?)
> if you change or modify anything interesting and
> I just don't have time right now to learn every last in and out of how
> it compiles itself so I can get it to rebuild after
> interesting/important modifications.
Just what I said.
From: Fernando Mato Mira
Subject: Re: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <37A02428.E21A144D@iname.com>
Rainer Joswig wrote:
> In article <·················@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
>
> (with-iteration
> How about a smaller core Lisp, that would be easier
> to build and move around?)
In order for Marco to be able to continue flagging the FTPL, one would have to look at those Old
World things (shocking! ;-)).
But then, he is an Euro, so that shouldn't be a problem. Or did he get "assimilated"? ;-)
Fernando Mato Mira <········@iname.com> writes:
> Rainer Joswig wrote:
>
> > In article <·················@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> >
> > (with-iteration
> > How about a smaller core Lisp, that would be easier
> > to build and move around?)
>
> In order for Marco to be able to continue flagging the FTPL, one would have to look at those Old
> World things (shocking! ;-)).
> But then, he is an Euro, so that shouldn't be a problem. Or did he
> get "assimilated"? ;-)
>
Of course I got assimilated. I'd like a date with 7! :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote in message
···················@copernico.parades.rm.cnr.it...
> Of course I got assimilated. I'd like a date with 7! :)
You mean "38 of D"?
From: Fernando Mato Mira
Subject: Re: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <37A1760D.4B284E3E@iname.com>
"Frank A. Adrian" wrote:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote in message
> ···················@copernico.parades.rm.cnr.it...
> > Of course I got assimilated. I'd like a date with 7! :)
>
> You mean "38 of D"?
I think it's more like "7 of C" and not "1 of S" or "1 of E" ("1 of I" ?)
[_Of course_ means "7 of X"! Can't you see his top-level domain? ;-)]
Fernando Mato Mira <········@iname.com> writes:
> "Frank A. Adrian" wrote:
>
> > Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote in message
> > ···················@copernico.parades.rm.cnr.it...
> > > Of course I got assimilated. I'd like a date with 7! :)
> >
> > You mean "38 of D"?
>
> I think it's more like "7 of C" and not "1 of S" or "1 of E" ("1 of I" ?)
> [_Of course_ means "7 of X"! Can't you see his top-level domain? ;-)]
You know what I mean! :)
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
······@lavielle.com (Rainer Joswig) writes:
> A few possible applications:
>
> - you could run it on bare PCs
> - you could run it in switches
> - you could run it as networking nodes running web servers, ...
> - you could use it on board of a space ship
> - you could put it on robots
> - you could put it in a game console
> - ...
>
I realised another thing about this. CL, as it stands, is probably
marginal on small devices -- a palm pilot for instance will probably
only just run something like a small CL system. So, superficially, it
looks like a sensible thing to produce a shrunken CL with less
functionality. But in the year or so it takes to design that, the
memory available on all these tiny devices has doubled, so the old,
bloated, CL would have fit. So, really, I don't see an argument for a
core CL based around a requirement for small devices.
There may be other reasons -- ease of porting perhaps? However I
think even this turns out not to be that good an argument, since there
are at least 2 pretty portable public CLs -- gcl and clisp -- and one
apparently very portable commercial offering -- Franz Allegro.
--tim
* Tim Bradshaw <···@tfeb.org>
| I realised another thing about this. CL, as it stands, is probably
| marginal on small devices -- a palm pilot for instance will probably only
| just run something like a small CL system. So, superficially, it looks
| like a sensible thing to produce a shrunken CL with less functionality.
| But in the year or so it takes to design that, the memory available on
| all these tiny devices has doubled, so the old, bloated, CL would have
| fit. So, really, I don't see an argument for a core CL based around a
| requirement for small devices.
a handheld computer with Common Lisp would need an editor that would be a
little different from what we're used to. perhaps it doesn't make much
sense to deal with textual input and then reading it the normal way? the
discussion about context-sensitive structure editors may be more useful
when dealing with handhelds than with keyboard-based computers. in other
words, the complexity of reading input may be significantly reduced in
one end, while we pay for the interface on the other end. I don't see
the point in a quick compiler -- leave those to the development tools to
be used on other computers.
something like CLISP would probably be more beneficial on a handheld than
a full-blown native compiler. on a handheld computer, there would be a
definitite need for fully dynamic CLOS support, as the "program" would be
started once and the objects would essentially live forever.
| There may be other reasons -- ease of porting perhaps? However I think
| even this turns out not to be that good an argument, since there are at
| least 2 pretty portable public CLs -- gcl and clisp -- and one apparently
| very portable commercial offering -- Franz Allegro.
I don't see any purpose in a Core Lisp at all. whether you should allow
the tree shaking before rather than after application development doesn't
seem like a question worth answering at this time.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Tim Bradshaw <···@tfeb.org> writes:
> So, superficially, it looks like a sensible thing to produce a
> shrunken CL with less functionality. But in the year or so it
> takes to design that, the memory available on all these tiny
> devices has doubled, so the old, bloated, CL would have fit.
True, no doubt, for the small devices of the moment. However in
the next few years there will probably be a new generation of small
devices, wrist pilots perhaps, that will start out with little memory
again.
* Erik Winkels <·······@xs4all.nl>
| True, no doubt, for the small devices of the moment. However in the next
| few years there will probably be a new generation of small devices, wrist
| pilots perhaps, that will start out with little memory again.
isn't it odd how designers keep making that mistake? I have this mental
picture of C programmers who do char input_line[128] and thinking nobody
could ever want longer lines than that, whenever I see some new gizmo
that comes out with a ridiculous amount of memory. my Nokia GSM (EU)
cell phone, for instance, can hold 5 messages in memory, while my Sanyo
PCS (US) cell phone can hold a whopping 30. like, wow. the messages are
160 character long with GSM SMS, and 100 characters with PCS messaging.
they both can hold 100 phone numbers with names. whee! I'm so excited.
"640K should be enough for everyone" is probably the most brilliant thing
the man has said (at least if we judge by his book "The Road Ahead"), but
there's something in the engineering culture that just doesn't quite get
this idea that people want to be relieved of remembering accurately, and
there's no limit to what people don't want to remember. whenever I call
directory assistance, for instance, chances are that I will call again
the next time I need the same number unless I write it down, but all of
this stuff is already in electronic form, so why can't the stupid
telephone just record it? sigh. some technologies are so lame.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
> * Erik Winkels <·······@xs4all.nl>
> isn't it odd how designers keep making that mistake?
Well, to give them their due it is not always a mistake. For very
small devices, things like power consumption and physical size can
often result in fairly draconian limits on things like memory.
For instance, my HP calculator came with 128k of memory, which really
wasn't enough. I bought another 1.x Mb for it, which *is* enough (at
least, the limit is now the addressability of the processor), but it's
had bad effects on battery life -- it now requires batteries every
month or so, which is a pain compared to the 6 months or so before.
Fortunately the new HP calculators come with loads of (presumably
lower-power) internal memory and flashable ROM.
--tim
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* Erik Winkels <·······@xs4all.nl>
>| True, no doubt, for the small devices of the moment. However in the next
>| few years there will probably be a new generation of small devices, wrist
>| pilots perhaps, that will start out with little memory again.
>
> isn't it odd how designers keep making that mistake?
As Tim Bradshaw pointed out, this is rarely a mistake. There may be
very valid price, power, and size constraints that restrict the memory
size of a portable device.
In space flight applications, for instance, memory that can withstand
the environmental radiation is relatively expensive, slow, power-hungry,
and not very dense, and requires expensive and power-hungry error
correction hardware. And the more mass you fly, the bigger the rocket
needed to push it into space. Given these constraints, it was a miracle
we got 128 MB on the New Millenium Deep Space One (recently renamed
Space Technologies One). I don't think we can count on that kind of
memory being available on future flights.
> "640K should be enough for everyone" is probably the most brilliant thing
> the man has said (at least if we judge by his book "The Road Ahead"), but
> there's something in the engineering culture that just doesn't quite get
> this idea that people want to be relieved of remembering accurately, and
> there's no limit to what people don't want to remember.
Aside from the constraints mentioned above, there is the problem of
keying that memory so that facts stored in it can be recalled quickly
and easily, how you deal with records that share the same key, etc.
It's more than just a resource issue, it's a user interface issue.
(This is most true in the context of small portable devices with minimal
input hardware, e.g. phones and palmtop assistants, less so in desktop
computer software.)
> whenever I call
> directory assistance, for instance, chances are that I will call again
> the next time I need the same number unless I write it down, but all of
> this stuff is already in electronic form, so why can't the stupid
> telephone just record it? sigh. some technologies are so lame.
So why don't you go design such an intelligent telephone? No one is
stopping you.
-- Chuck, again speaking for himself
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
From: Raymond Toy
Subject: Re: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <4n7lnjv4es.fsf@rtp.ericsson.se>
>>>>> "Chuck" == Chuck Fry <······@best.com> writes:
Chuck> In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>> whenever I call
>> directory assistance, for instance, chances are that I will call again
>> the next time I need the same number unless I write it down, but all of
>> this stuff is already in electronic form, so why can't the stupid
>> telephone just record it? sigh. some technologies are so lame.
Chuck> So why don't you go design such an intelligent telephone? No one is
Chuck> stopping you.
My Sony CDMA phone keeps a list of the last few numbers dialed. I'm
sure there's a way to add one of those numbers to your personal phone
list.
Ray
······@best.com (Chuck Fry) writes:
> In space flight applications, for instance, memory that can withstand
> the environmental radiation is relatively expensive, slow, power-hungry,
> and not very dense, and requires expensive and power-hungry error
> correction hardware. And the more mass you fly, the bigger the rocket
> needed to push it into space. Given these constraints, it was a miracle
> we got 128 MB on the New Millenium Deep Space One (recently renamed
> Space Technologies One). I don't think we can count on that kind of
> memory being available on future flights.
I'd be interested in knowing if these constraints apply to ROM -- or
was most of that 128Mb ROM anyway? I kind of assume that the same
things that make it hard (impossible...) for programs to write to ROM
also make it hard for radiation to write to it, so it should be a good
bet for bad environments. OTOH it is perhaps not a good bet because
you don't always have the opportunity to upgrade the thing when you
find a bug in the ROM and it's on Mars or something.
Presumably you could do some clever thing of having a whole load of
(hardened) ROM in there and shadowing bits of it (possibly at language
level) with patches in the much scarcer RAM. Lisp would be a really
cool language for experimenting with that as it's all about
redefinability in some sense.
Do people play with having lots of cheapo errory memory and then
really, really good error correction, or is that too expensive in some
way?
--tim (Whose most recent experience of anything like this was
observing people react in horror when it became apparent that
the 1k ROM for an 1802-based system was just going to have to
change to 2k with resultant nightmare of finding a 2k
suitably-hardened part.)
Tim Bradshaw wrote:
...
> Presumably you could do some clever thing of having a whole load of
> (hardened) ROM in there and shadowing bits of it (possibly at language
> level) with patches in the much scarcer RAM. Lisp would be a really
> cool language for experimenting with that as it's all about
> redefinability in some sense.
Yes, this mechanism was implemented in Apple Newton - the system is in
the ROM, and if a slot of a pre-delivered object changes, the object in
the ROM is referred and only the amended slot is stored in the RAM. This
is hugely supported by the fact that the OO system of NewtonScript is
prototype-based, but this should also be straightforward using MOP. It
is amazing how much functionality could fit in so little RAM.
-Robert
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>······@best.com (Chuck Fry) writes:
>> In space flight applications, for instance, memory that can withstand
>> the environmental radiation is relatively expensive, slow, power-hungry,
>> and not very dense, and requires expensive and power-hungry error
>> correction hardware. And the more mass you fly, the bigger the rocket
>> needed to push it into space. Given these constraints, it was a miracle
>> we got 128 MB on the New Millenium Deep Space One (recently renamed
>> Space Technologies One). I don't think we can count on that kind of
>> memory being available on future flights.
>
>I'd be interested in knowing if these constraints apply to ROM -- or
>was most of that 128Mb ROM anyway? I kind of assume that the same
>things that make it hard (impossible...) for programs to write to ROM
>also make it hard for radiation to write to it, so it should be a good
>bet for bad environments. OTOH it is perhaps not a good bet because
>you don't always have the opportunity to upgrade the thing when you
>find a bug in the ROM and it's on Mars or something.
Programs were stored in EEROM ("flash" memory), in a "solid state disk"
configuration. It's not economically viable to use mask ROM for a
one-of-a-kind application, and the team wanted to be able to update the
software in flight. I'm not clear on how radiation-resistant flash
memory is; I think it's better than dynamic RAM, but I don't know by how
much.
There used to be a ROM technology that used fuses, which clearly would
have been more robust against radiation, but it was not reprogrammable,
and extremely power-hungry.
You can't use real disk in flight, because it tends to spin the
spacecraft.
>Do people play with having lots of cheapo errory memory and then
>really, really good error correction, or is that too expensive in some
>way?
It adds complexity and cost, and slows access time. Few terrestrial PCs
even have *parity* on memory any more.
-- Chuck, again speaking only for himself
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
······@best.com (Chuck Fry) wrote:
>In space flight applications, for instance, memory that can withstand
>the environmental radiation is relatively expensive, slow, power-hungry,
>and not very dense, and requires expensive and power-hungry error
>correction hardware. And the more mass you fly, the bigger the rocket
>needed to push it into space. Given these constraints, it was a miracle
>we got 128 MB on the New Millenium Deep Space One (recently renamed
>Space Technologies One). I don't think we can count on that kind of
>memory being available on future flights.
esp. when I think of tiplers advise to use with 14 milligram space
explorers for colonization :)
--
Reini
* ······@best.com (Chuck Fry)
| So why don't you go design such an intelligent telephone? No one is
| stopping you.
really? have you ever tried to do something like that? I have. I have
been running my own business since 1984, and I can tell you a few things
about who is stopping new ideas. as can any businessman. we have a
bunch of people who have originally had the money, but who have actively
stopped a few companies that have really hurt the Lisp community. we
have seen how politicians (Margaret Thatcher) have all but obliterated
the market for Artificial Intelligence in a whole country. such people
must be overcome, but they are actually stopping a lot of good ideas out
there which can't overcome their resistance.
I really hope the above line is an attempt at something like "if you are
so good, how come you aren't rich?" and other reversals of causality that
completely ignore reality in order to ridicule people, and not something
you actually believe in. otherwise, you'll get _seriously_ hurt if you
get an idea of your own.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> wrote:
+---------------
| there's something in the engineering culture that just doesn't quite get
| this idea that people want to be relieved of remembering accurately, and
| there's no limit to what people don't want to remember. whenever I call
| directory assistance, for instance, chances are that I will call again
| the next time I need the same number unless I write it down, but all of
| this stuff is already in electronic form, so why can't the stupid
| telephone just record it? sigh. some technologies are so lame.
+---------------
This month's Scientific American has three articles about some very
interesting work being done at the MIT Media Lab's "Project Oxygen" for
imbuing such characteristics into hand-held devices, especially speaker-
independent voice-response systems with enough knowledge of English that
you could say "Call the last number I asked directory assistance for",
and it would.
They have a working prototype weather information system that handles
qeuries like these [paraphrased from memory, but see the sidebar on the
second "Oxygen" article]:
Q: What's the weather in Boston?
A: The current weather in Boston is 54 degrees with clear skies.
Q: How about Washington?
A: The current weather in Washington is 49 degrees and raining.
Q: And tomorrow?
A: The forcast weather for Washington tomorrow is 51 degrees and
occasional light rain showers.
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Erik Naggum <····@naggum.no> wrote:
+---------------
| there's something in the engineering culture that just doesn't quite get
| this idea that people want to be relieved of remembering accurately, and
| there's no limit to what people don't want to remember. whenever I call
| directory assistance, for instance, chances are that I will call again
| the next time I need the same number unless I write it down, but all of
| this stuff is already in electronic form, so why can't the stupid
| telephone just record it? sigh. some technologies are so lame.
+---------------
This month's Scientific American has three articles about some very
interesting work being done at the MIT Media Lab's "Project Oxygen" for
imbuing such characteristics into hand-held devices, especially speaker-
independent voice-response systems with enough knowledge of English that
you could say "Call the last number I asked directory assistance for",
and it would.
They have a working prototype weather information system that handles
queries like these [paraphrased from memory, but see the sidebar on the
second "Oxygen" article]:
Q: What's the weather in Boston?
A: The current weather in Boston is 54 degrees with clear skies.
Q: How about Washington?
A: The current weather in Washington is 49 degrees and raining.
Q: And tomorrow?
A: The forecast weather for Washington tomorrow is 51 degrees and
occasional light rain showers.
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
In article <···········@fido.engr.sgi.com>, ····@rigden.engr.sgi.com (Rob Warnock) wrote:
> This month's Scientific American has three articles about some very
> interesting work being done at the MIT Media Lab's "Project Oxygen"
Isn't it the MIT *LCS* together with the AI Lab?
······@lavielle.com (Rainer Joswig) writes:
> In article <···········@fido.engr.sgi.com>, ····@rigden.engr.sgi.com (Rob Warnock) wrote:
>
> > This month's Scientific American has three articles about some very
> > interesting work being done at the MIT Media Lab's "Project Oxygen"
>
> Isn't it the MIT *LCS* together with the AI Lab?
The media lab is a (mostly) different set of people from the LCS and the AI
lab. The AI lab is located in the building housing the LCS, I'm not certain
if it is part of the LCS though. (If I were pushed to guess, I'd say it
wasn't.) Not that the three don't collaborate on various projects...
Sunil
Rainer Joswig <······@lavielle.com> wrote:
+---------------
| ····@rigden.engr.sgi.com (Rob Warnock) wrote:
| > This month's Scientific American has three articles about some very
| > interesting work being done at the MIT Media Lab's "Project Oxygen"
|
| Isn't it the MIT *LCS* together with the AI Lab?
+---------------
I stand corrected. It is indeed LCS, together with the EE&CS department.
(The AI Lab wasn't mentioned, as far as I can see.) My apologies for the
misattribution. [Oh, and it was four articles (pp.52-63), not three.]
Anyway, it's worth a read...
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
In article <···········@fido.engr.sgi.com>, ····@rigden.engr.sgi.com (Rob Warnock) wrote:
> Rainer Joswig <······@lavielle.com> wrote:
> +---------------
> | ····@rigden.engr.sgi.com (Rob Warnock) wrote:
> | > This month's Scientific American has three articles about some very
> | > interesting work being done at the MIT Media Lab's "Project Oxygen"
> |
> | Isn't it the MIT *LCS* together with the AI Lab?
> +---------------
>
> I stand corrected. It is indeed LCS, together with the EE&CS department.
> (The AI Lab wasn't mentioned, as far as I can see.)
See: http://www.sciam.com/1999/0899issue/0899dertouzos.html
Given the goal of doing more by doing less and the model of
the Information Marketplace, how do we get there in practice?
To that end, at the Laboratory for Computer Science, we have
just launched a major research project. We expect it to
result in a radically new hardware and software system called
Oxygen, which will be tailored to people and their
applications and will become as pervasive--we hope--as the
air we breathe. This multimillion-dollar, five-year project
involves some 30 faculty members from the Laboratory for
Computer Science, working in collaboration with the M.I.T.
Artificial Intelligence Lab.
Rainer Joswig <······@lavielle.com> wrote:
+---------------
| ····@rigden.engr.sgi.com (Rob Warnock) wrote:
| > | Isn't it the MIT *LCS* together with the AI Lab?
| >
| > I stand corrected. It is indeed LCS, together with the EE&CS department.
| > (The AI Lab wasn't mentioned, as far as I can see.)
|
| See: http://www.sciam.com/1999/0899issue/0899dertouzos.html
...
| involves some 30 faculty members from the Laboratory for
| Computer Science, working in collaboration with the M.I.T.
| Artificial Intelligence Lab.
+---------------
I guess that's what I get from reading the paper copy -- an unreliable
"grep"!! Yes, it was mentioned in the paper version, at the end of the
14th paragraph of the article (on the 3rd page), but not in any of the
end-of-article credits where I looked before posting the referenced reply.
(*blush*)
So we have LCS, EE&CS, and AI Lab. Anybody else? ;-}
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Erik Winkels <·······@xs4all.nl> writes:
> True, no doubt, for the small devices of the moment. However in
> the next few years there will probably be a new generation of small
> devices, wrist pilots perhaps, that will start out with little memory
> again.
Well, I'll happily admit to not knowing too much about the
technologies, but it seems to me that, although these devices may have
only tiny RAM, they will probably be able to have plenty of ROM (or
flashable ROM preferably). So, so long as most of your system can sit
in ROM (and I can't see a reason why most of a CL system should not be
in ROM), you're probably OK. I think that ROM is very low power and
pretty physically tiny. A more likely limit is perhaps address space
in the CPU if they have less-than-32 bit cpus, but I think most things
are now 32?
Anyway, I don't really see the tiny-device argument being a good
reason for a CL subset. There may be other good reasons.
--tim
From: Fernando Mato Mira
Subject: Re: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <37A07328.5CA3CF6D@iname.com>
Tim Bradshaw wrote:
> Erik Winkels <·······@xs4all.nl> writes:
>
> > True, no doubt, for the small devices of the moment. However in
> > the next few years there will probably be a new generation of small
> > devices, wrist pilots perhaps, that will start out with little memory
> > again.
>
> Well, I'll happily admit to not knowing too much about the
> technologies, but it seems to me that, although these devices may have
> only tiny RAM, they will probably be able to have plenty of ROM (or
> flashable ROM preferably). So, so long as most of your system can sit
> in ROM (and I can't see a reason why most of a CL system should not be
> in ROM), you're probably OK. I think that ROM is very low power and
> pretty physically tiny. A more likely limit is perhaps address space
> in the CPU if they have less-than-32 bit cpus, but I think most things
> are now 32?
Reducing chip count is a big issue. How many years still until you can have
DSP, analog wireless and audio frontend, display controller, and say,
4Mwords of PROM and 4Mwords of RAM in a single chip?
What's the minimum you need for a full CL?
From: Fernando Mato Mira
Subject: Re: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <37A079BC.F78F2933@iname.com>
Fernando Mato Mira wrote:
> Reducing chip count is a big issue. How many years still until you can have
> DSP, analog wireless and audio frontend, display controller, and say,
> 4Mwords of PROM and 4Mwords of RAM in a single chip?
Here's a more interesting question: would you need full CL to program
microrobots?
(Low-level motion control might be hardware-based).
Or maybe having a dual-purpose CL-1/CL-7 spec is a better idea, instead of a
Core Lisp? (you know what I mean).
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>Well, I'll happily admit to not knowing too much about the
>technologies, but it seems to me that, although these devices may have
>only tiny RAM, they will probably be able to have plenty of ROM (or
>flashable ROM preferably).
See my other article in this thread. Mask ROM (*really* read-only
memory) is cheapest in large quantity applications, always has been, and
always will be. Flash ROM adds cost in several ways: first, it is
inherently more expensive; second, a programming interface (meaning more
components) must be provided, increasing component count and space
consumption; third, the flash ROM and its programming interface draw
more power.
>Anyway, I don't really see the tiny-device argument being a good
>reason for a CL subset. There may be other good reasons.
Engineering is the art of doing for a dime what any damned fool can do
for a dollar. IMHO there will *always* be good reasons for a reduced CL
subset.
I don't know why, but the comment seen in some Lisp Machine source
files:
;;; This file is in the cold load.
always gives me a warm and fuzzy feeling. :-)
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
······@best.com (Chuck Fry) writes:
> I don't know why, but the comment seen in some Lisp Machine source
> files:
> ;;; This file is in the cold load.
> always gives me a warm and fuzzy feeling. :-)
Could you explain what this means for those who haven't seen a Lisp
Machine?
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
In article <··············@localhost.localdomain>,
Lieven Marchand <···@bewoner.dma.be> wrote:
>······@best.com (Chuck Fry) writes:
>
>> I don't know why, but the comment seen in some Lisp Machine source
>> files:
>> ;;; This file is in the cold load.
>> always gives me a warm and fuzzy feeling. :-)
>
>Could you explain what this means for those who haven't seen a Lisp
>Machine?
At Symbolics, at least, the "cold load" was the core Lisp system, the
kernel if you will. The cold load was the first part of the Lisp system
to be loaded at startup, and lacked much of the sophistication of the
full running system (e.g. virtual memory, window system, most
object-oriented facilities, etc.). Yet the cold load had a debugger,
and could type to the screen through a basic character-at-a-time
interface.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> I realised another thing about this. CL, as it stands, is probably
> marginal on small devices -- a palm pilot for instance will probably
> only just run something like a small CL system.
Apple's Newton was a system which was very close to a Common Lisp
environment. Some features of the Newton OS:
- Garbage Collection
- tagged data
- byte code interpreter and compiler builtin (in ROM)
- code and data is tiny, you have your prototype
objects in ROM and at runtime only the differences
are in RAM.
Applications were only a fraction in size of what you have on other
platforms - still they were fully object-oriented and dynamic.
- optional native code compilation
- dynamic objects
- dynamic typing
> There may be other reasons -- ease of porting perhaps? However I
> think even this turns out not to be that good an argument, since there
> are at least 2 pretty portable public CLs -- gcl and clisp
GCL and Clisp (as nice as they are) fail to support crucial
things like an advanced GC, threads and performance.
> -- and one
> apparently very portable commercial offering -- Franz Allegro.
"Portable" is relative - portable across Unix systems perhaps?
How big is a working Franz Allegro lisp image? Last time I looked,
ACL generated really large code on RISC machines
(has this changed?).
Reasons for a Core Lisps are:
- small footprint is still an advantage on various devices
(imaging placing a Lisp system in any arm of a robot)
- it's much easier to understand
- it's much easier to port
- it's much easier to experiment with extensions and changes
- faster startup time
- small means also that the kernel fits into current cache sizes
(I guess the boost MCL has got from the PowerPC G3 processor
is especially because it has a small footprint and the G3 has a
nice second level cache architecture)
- you might be able to experiment with different GC strategies
(remember that for example G2 which is popular
in process control and simulation is written
in a non-consing version of Common Lisp).
- it might be a good teaching vehicle
- it could be the base for an OS kernel
- you should be able to run thousands of Lisp threads on a single machine
(-> a web server, file server, ...)
There were projects in this direction already.
Minima was a mininal Lisp system from Symbolics
(the opposite of Genera, so to speak). You could have
embedded systems running Minima. Symbolics
even once built special hardware for a customer:
http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/zora/zora.html
See L, etc.
or to quote "Modernizing Common Lisp: Recommended Extensions", John Mallery, ...:
"The most important recommendation with the most leverage is the
recommendation to develop a PORTABLE BASE LANGUAGE FOR COMMON LISP.
This strategic move provides:
* An opportunity to reengineer the core language;
* A minimal base to port to new platforms;
* Opportunities for new hardware and compiler efforts
(base-to-platform & portable-to-base);
* Increased sharing of higher-level code."
...
"* CL Portable Base Language: Develop a base language to which
all extant Common Lisp implementations can be targeted. This
language should include locatives and basic OS operations like
processes, file I/O, networking. This base layer will
increase portability of lisp applications and enable work to
improve performance with specialized hardware or compilers.
This layer should make efforts to support real-time and
parallel dialects. Experimental, Very High Impact, Examples,
Implementations, Hard. KR, RL, JM"
* Rainer Joswig
| How big is a working Franz Allegro lisp image?
on my system, the free system memory decreases by 740K when I start up
the second Allegro CL 5.0.1. the similar process with CLISP requires
1108K of fresh memory. it is very hard on my system to measure the exact
memory consumption of a process except for the fresh memory it grabs.
| Last time I looked, ACL generated really large code on RISC machines (has
| this changed?).
it's impossible to tell since you don't give any clue when that last time
was, what "really large code" means, or which RISC processor you're
talking about. I _could_ say "yes, it's much, much better now" and you
wouldn't know what I had answered, but anyone careless enough to believe
your question was meaningful would probably believe my answer, too. that
is to say, I don't believe people are actually interested in performance
information from others in a free forum -- even if people are honest,
they are way too sloppy to produce meaningful data to base business
decisions on, and anyone with an agenda will "win" by being selectively
dishonest, as much comparative "marketing" and campaigning is already.
| Reasons for a Core Lisps are:
|
| - small footprint is still an advantage on various devices
| (imaging placing a Lisp system in any arm of a robot)
as others have indicated, ROM is cheaper than RAM.
| - it's much easier to understand
this is actually not so. a Core Lisp would need more macrology and more
higher-leve code to support good programming styles, and would suffer
like Scheme when small communities of people develop incompatible
"libraries" of extensions. agreeing on a large base serves a larger
community. we cannot afford to let a thousand flowers bloom when the
soil only supports a hundred -- we'll all vanish and the weed will take
over completely.
| - it's much easier to port
you don't port the Lisp code, you port the compiler and run-time system.
if you're even moderately smart, the run-time system is written largely
in Lisp and what you really need is a proto-Lisp, not a Core Lisp, but
you wouldn't want anyone to actually program in the proto-Lisp besides
the engineers who boot up a Common Lisp system.
| - it's much easier to experiment with extensions and changes
this is wrong -- tweaking something is easier than building from scratch.
| - faster startup time
this is wrong -- startup time is unaffected by total system size.
| - small means also that the kernel fits into current cache sizes
| (I guess the boost MCL has got from the PowerPC G3 processor
| is especially because it has a small footprint and the G3 has a
| nice second level cache architecture)
what use is this when you need space for all the user code that makes
code worth writing, again?
| - you might be able to experiment with different GC strategies
unless you by "Core Lisp" mean a proto-Lisp that lives below the real
Lisp, this does not seem to be a valid argument.
| - it might be a good teaching vehicle
we've been there before. some students prefer to know that as they learn
more and more, a lot of work has already been done for them, while other
students prefer to be able to learn it all in a short time and go on to
build stuff from scratch. e.g., you could easily teach medicine in a
year if you wanted to produce doctors faster, but they would still need
seven years to be trustable in any critical situation where they would be
called upon. society would have to respond to one-year doctors with a
lot more bureaucrazy and each doctor's skills would need to be charted
with much more detail than we do today. so you would get more doctors
through the system, at phenomenal increases in total system costs. the
same is true of any other complex system that is taught in stages.
| - it could be the base for an OS kernel
nothing prevents you from doing this already. you don't need somebody
else to define a Core Lisp for you first, in other words. just do it.
| - you should be able to run thousands of Lisp threads on a single machine
| (-> a web server, file server, ...)
this does not relate to system size, only _incremental_ process size. a
bigger base system will generally have smaller incremental sizes than a
small base system, where each thread needs to set up its own environment.
I wonder which agenda John Mallery actually has -- what he says doesn't
seem to be terribly consistent. neither do your arguments, Rainer. in
brief, it looks like you guys want to destabilize the agreement that has
produced what we have today, for no good reason except that insufficient
catering to individual egos have taken place up to this point.
haven't various people tried to produce a Core English already? how well
did that those projects go? more importantly, why isn't there anything
available in Core English except the designer's teaching materials? I'd
say the evidence is clear: people don't want to be artificially limited
by some minimalist committee.
Core Lisp is a mistake, but it will be a serious drain on the resources
available in the Common Lisp community. language designer wannabes and
language redesigners should go elsewhere.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
>| - small footprint is still an advantage on various devices
>| (imaging placing a Lisp system in any arm of a robot)
>
> as others have indicated, ROM is cheaper than RAM.
This sortof leads to something I pondered upon a few months back when I
played with genetic programming and some robot simulations. Inspired by
the Toy Robots made by LEGO I hoped there existed a somewhat affordable
(toy-) robot option which could run a Lisp system. Unfortunately the
"marketed" robots were either too low on ROM and RAM and using some form
of BASIC or some (even more) crippled version of C which would take too
long to find weird things in when porting. It would have been fun to
have some toy robots try out some of the more succesful evolutionized
code. Anyone know of an easy way to get hold of stuff/code for such a
robot?
------------------------------------------------------------------
Stig Erik Sandoe Institute of Informatics, University of Bergen
····@ii.uib.no http://www.ii.uib.no/~stig/
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> * Rainer Joswig
> | How big is a working Franz Allegro lisp image?
>
> on my system, the free system memory decreases by 740K when I start up
> the second Allegro CL 5.0.1. the similar process with CLISP requires
> 1108K of fresh memory. it is very hard on my system to measure the exact
> memory consumption of a process except for the fresh memory it grabs.
You have not answered my question.
> | Reasons for a Core Lisps are:
> |
> | - small footprint is still an advantage on various devices
> | (imaging placing a Lisp system in any arm of a robot)
>
> as others have indicated, ROM is cheaper than RAM.
Unfortunately it's easy for me to put my software in RAM,
not in ROM.
> | - it's much easier to understand
>
> this is actually not so. a Core Lisp would need more macrology and more
> higher-leve code to support good programming styles,
A user would use the usual CL on top of that.
> | - it's much easier to port
>
> you don't port the Lisp code, you port the compiler and run-time system.
> if you're even moderately smart, the run-time system is written largely
> in Lisp and what you really need is a proto-Lisp, not a Core Lisp, but
> you wouldn't want anyone to actually program in the proto-Lisp besides
> the engineers who boot up a Common Lisp system.
True, but this doesn't contradict what I'm saying.
> | - it's much easier to experiment with extensions and changes
>
> this is wrong -- tweaking something is easier than building from scratch.
Tweaking something small should be easier than tweaking something
large.
> | - faster startup time
>
> this is wrong -- startup time is unaffected by total system size.
This is wrong. Sure startup time is affected
by total system size. You need to be careful about that
at initialization time and load time. Is the code still in cache, etc.
Many systems now have very fast cache systems (for example
the backside cache of the G3), taking advantage of that
is not unreasonable. You might have to deal with
non-locality of code and data, ...
> | - small means also that the kernel fits into current cache sizes
> | (I guess the boost MCL has got from the PowerPC G3 processor
> | is especially because it has a small footprint and the G3 has a
> | nice second level cache architecture)
>
> what use is this when you need space for all the user code that makes
> code worth writing, again?
The use of that is that a large part of your program might
uses routines from your kernel. Additionally runtime services
like GC would surely benefit if they could stay in cache.
> | - it might be a good teaching vehicle
>
> we've been there before.
Still you seem to respond only to one possible dimension of it.
> | - you should be able to run thousands of Lisp threads on a single machine
> | (-> a web server, file server, ...)
>
> this does not relate to system size, only _incremental_ process size.
Sure, but it also relates to things like startup time, scheduling
overhead, time to respond to requests, etc.
> a
> bigger base system will generally have smaller incremental sizes than a
> small base system, where each thread needs to set up its own environment.
yes, still you get stuff like increased non-locality. The
Lisp machine has for example introduced things like
Areas and reordering of objects in (incrementally) saved images.
> I wonder which agenda John Mallery actually has -- what he says doesn't
> seem to be terribly consistent. neither do your arguments, Rainer. in
> brief, it looks like you guys want to destabilize the agreement that has
> produced what we have today, for no good reason except that insufficient
> catering to individual egos have taken place up to this point.
Sure, go on Erik. Make fool out of yourself by blaming other people.
It's a well known tactic by you to mix in your personal attacks.
> haven't various people tried to produce a Core English already?
What has this to do with the topic I was discussing?
> Core Lisp is a mistake, but it will be a serious drain on the resources
> available in the Common Lisp community. language designer wannabes and
> language redesigners should go elsewhere.
Erik, you finally made it in my kill file. Not that I expect you to
care, but I don't feel that urgent a need to read your pointless
rantings anymore. Better try to impress beginners with your excurses
in Lisp and how the world is according to you.
In article <·······················@194.163.195.67>,
······@lavielle.com says...
> Erik, you finally made it in my kill file. Not that I expect you to
> care, but I don't feel that urgent a need to read your pointless
> rantings anymore. Better try to impress beginners with your excurses
> in Lisp and how the world is according to you.
Good grief, not you too. ;)
Anyway, I was playing with an "ultra core Lisp" about 5 years ago,
using a crude compiler for an unbelievably minimal subset of Scheme
that produced even more crude C code and used a simple compacting GC.
I got some curiously satisfying results on a 20 Mhz 386.
So this thread is fascinating me.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- tagline for Hellraiser
···@wildcard.butterfly.demon.co.uk (Martin Rodgers) writes:
> In article <·······················@194.163.195.67>,
> ······@lavielle.com says...
>
> > Erik, you finally made it in my kill file. Not that I expect you to
> > care, but I don't feel that urgent a need to read your pointless
> > rantings anymore. Better try to impress beginners with your excurses
> > in Lisp and how the world is according to you.
>
> Good grief, not you too. ;)
>
> Anyway, I was playing with an "ultra core Lisp" about 5 years ago,
> using a crude compiler for an unbelievably minimal subset of Scheme
... a subset of Scheme? :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>,
·······@copernico.parades.rm.cnr.it says...
> ... a subset of Scheme? :)
It was little more than a thin layer over C. Imagine adding minimal
list crunching, GC and a much better syntax to C.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- tagline for Hellraiser
···@wildcard.butterfly.demon.co.uk (Martin Rodgers) writes:
> In article <··············@copernico.parades.rm.cnr.it>,
> ·······@copernico.parades.rm.cnr.it says...
>
> > ... a subset of Scheme? :)
>
> It was little more than a thin layer over C. Imagine adding minimal
> list crunching, GC and a much better syntax to C.
I think you missed the (intended) sarcasm of my remark :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Fernando Mato Mira
Subject: Re: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <37A302C4.9D194823@iname.com>
Marco Antoniotti wrote:
> ···@wildcard.butterfly.demon.co.uk (Martin Rodgers) writes:
>
> > In article <··············@copernico.parades.rm.cnr.it>,
> > ·······@copernico.parades.rm.cnr.it says...
> >
> > > ... a subset of Scheme? :)
> >
> > It was little more than a thin layer over C. Imagine adding minimal
> > list crunching, GC and a much better syntax to C.
>
> I think you missed the (intended) sarcasm of my remark :)
Tail recursion elimination stayed out of the subset? :->
In article <·················@iname.com>, ········@iname.com says...
> Tail recursion elimination stayed out of the subset? :->
That's right, no tail recursion but my compiler turned calls to named
LETs into a goto, providing they were in the same function. In other
words, no real continuations. Lots of "inlining", BTW.
The compiler was brutally simple. So was the runtime support.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- tagline for Hellraiser
In article <··············@copernico.parades.rm.cnr.it>,
·······@copernico.parades.rm.cnr.it says...
> I think you missed the (intended) sarcasm of my remark :)
No, I spotted it thanks. ;)
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- tagline for Hellraiser
* Rainer Joswig
| How big is a working Franz Allegro lisp image?
* Erik Naggum
| on my system, the free system memory decreases by 740K when I start up
| the second Allegro CL 5.0.1. the similar process with CLISP requires
| 1108K of fresh memory. it is very hard on my system to measure the exact
| memory consumption of a process except for the fresh memory it grabs.
* Rainer Joswig
| You have not answered my question.
I think what I wrote suggests that I'm aware of that. your question is
like a child asking "daddy, why is the water blue?" and to avoid getting
into a lot of detail because the child doesn't understand his question,
it is sometimes useful to answer "because they put blue stuff in it".
[this is actual conversation between child and father.]
what I have written above is what the cost in RAM would be in a ROM-based
implementation. I regret that you asked an unaswerable question.
| Unfortunately it's easy for me to put my software in RAM, not in ROM.
so now "easy for me" has moved up to the top of the list of requirements?
you're not really trying to solve any problems, are you, Rainer? this
_is_ just another stupid exercise in showing how Common Lisp is Big and
Bloated and how bad that is, isn't it? let's create more problems so
we're sure we can't solve any of them! that's how we keep academics out
of the unemployment statistics when they have ceased to be useful, but it
is still not a smart way to use their brainpower.
| A user would use the usual CL on top of that [the Core Lisp].
this means that you actually confuse a proto-Lisp with a Core Lisp. I'm
frankly amazed that this is possible. people build proto-Lisps in order
to make booting the whole system easy -- it is not what people should use
to program anything, and it's so implementation-dependent that there is
no point at all in standardizing it, especially not by people who don't
actually know how to boot a Common Lisp system.
a Core Lisp that is just like a proto-Lisp upon which everything else in
Common Lisp is built is a waste of time and effort -- it would be like
defining some primitives in C and instead of ignoring that as necessity,
make a whole lot of stink about how others need to define the same
primitives in C in _their_ Common Lisps so some other Common Lisp which
has exactly the same external definition can be retargeted on another
Core Lisp. why would anyone ever think of wasting time on this? sheesh.
| Tweaking something small should be easier than tweaking something large.
this has never been the case. what makes you think it suddenly became
the case? why _should_ it be easier, when it clearly isn't?
| This is wrong. Sure startup time is affected by total system size. You
| need to be careful about that at initialization time and load time. Is
| the code still in cache, etc. Many systems now have very fast cache
| systems (for example the backside cache of the G3), taking advantage of
| that is not unreasonable. You might have to deal with non-locality of
| code and data, ...
you're just bickering now, Rainer. you do understand that this stuff is
completely tangential to the issue of total system size.
the usually _relevant_ costs of a startup is related to how much cannot
be done prior to startup. this includes dynamic linking (with shared
libraries), initialization of memory pools, and any preparations
necessary for graceful error handling and exit. this is stuff that does
not take time to do, and the likelihood that it is in cache is directly
related to how often you do it, not how big the total system is. if it
ever would be important to reduce the cache misses at startup time,
compile the startup code specially, and earn exactly nothing except that
you might win a stupid startup-time contest arranged by people who have
no clue about what makes a whole Common Lisp system useful.
| The use of that is that a large part of your program might uses routines
| from your kernel. Additionally runtime services like GC would surely
| benefit if they could stay in cache.
how would all of this wonderful stuff of yours fit in the _same_ cache
that can't hold the full system today, when it has be at least as big
after it has been slopped onto the Core Lisp? whatever made you believe
that the cache could hold more just because the core is smaller? geez.
but _are_ we really defining a Core Lisp with the strongest requirement
that it fit in today's processor caches? is that what this is exercise
is _really_ about? no, I don't think so. the cache argument is bogus,
the "easy for me" argument is bogus. this is all about Common Lisp being
too big and bloated and someone wanting so desperately to prove it just
to annoy other people.
| > I wonder which agenda John Mallery actually has -- what he says doesn't
| > seem to be terribly consistent. neither do your arguments, Rainer. in
| > brief, it looks like you guys want to destabilize the agreement that has
| > produced what we have today, for no good reason except that insufficient
| > catering to individual egos have taken place up to this point.
|
| Sure, go on Erik. Make fool out of yourself by blaming other people.
| It's a well known tactic by you to mix in your personal attacks.
yet, what is really amusing is that you answer in _much_ worse kind. the
obvious conclusion is that I must have hit on some real truth and bruised
some of the already very fragile egos.
| > haven't various people tried to produce a Core English already?
|
| What has this to do with the topic I was discussing?
it shows that you don't learn from history and available experience.
| > Core Lisp is a mistake, but it will be a serious drain on the resources
| > available in the Common Lisp community. language designer wannabes and
| > language redesigners should go elsewhere.
|
| Erik, you finally made it in my kill file.
again, it is very obvious that truth hurts: this is a waste and you guys
know it, but at least the effort will stand a chance of being remembered.
| Not that I expect you to care, but I don't feel that urgent a need to
| read your pointless rantings anymore. Better try to impress beginners
| with your excurses in Lisp and how the world is according to you.
I'm sorry, Rainer, I'm not used to being exposed to such reeking envy,
but I feel profoundly sorry for you, yet I'm happy you won't respond, now
that I am in your kill file: the vileness of your response suggests that
there is no limit to what disgusting level you could sink to in order to
prove I'm a fool you should not have to listen to, even though you do
know I speak the truth about your useless waste of time.
a Core Lisp would be good if we wanted to encourage more implementations
in the free software world, or wanted to encourage the retargetability of
existing implementations. already, however, whoever wants to reimplement
Common Lisp is better off buying or reusing existing code for the
exterior of the language (unless the argument from McCarthy and Joswig is
that the existing implementations aren't as good as they would have made
them, had they been allowed to do them) -- any smarter approach to
implementation would also be different from the past, and so any Core
Lisp would therefore make better implementations _less_ likely.
but what better way to respond to "it's a waste of time, stupid!" than to
acknowledge it by responding "I'm not listening to you!". this would
have been _so_ amusing had it not been for the enormous waste of effort
and derailing of community efforts that will now take place in spite of
the obvious.
I also thought this kind of idiocy was what we had the Scheme community
to learn from and not have to repeat ourselves. I guess I was wrong:
some people just have to make their very own mistakes before they learn.
now, even with the obvious futility of this project, there are a need for
Core Lisps in the plural: how you define them is so dependent on the
specific application needs that each project will want its own definition
-- and not just because they have unique needs, but because it takes more
time to evaluate the existing alternatives than to roll one's own. so
it's better to let each project learn from others via the literature and
define his own Core Lisp, than to standardize it for all to use.
the history of programming has shown us that subsetting languages does
not work, neither in the definition phase where you try to define which
components some component depends on (people then agree on which subset
to use and the full definition is lost), nor in the shaking of the
component tree so unneeded components fall out (programmers will want to
use features without having to remember their component, and will hate to
reimplement things only because they don't want a whole component). yet,
every Lisp implementor has to grapple with the "cold load order problem"
-- from which substrate the first few definitions can be executed. every
Lisp system that is loading needs to have a few pieces in place, but in a
natively compiled Lisp, what's necessary for loading the system is not
what is necessary for running the system once fully loaded. and which
primitives to port and base others on depends on how the compiler is
built and used, and cannot be ported to another compiler unless that
compiler have demands put on it that it is meaningless to demand from a
competitor in a free market.
I can only assume that the people who want to define a subset are not
familiar with the boot problem in the environments they use all day, or
ignore it for some higher agenda. e.g., it is "educational" to try to
dump a random package with Emacs. effectively, the packages that are
dumped with Emacs are written in a much smaller Emacs Lisp than the
packages that are loaded during normal execution. now, what does the
smart programmer do when he tries to load a new package that needs some
functionality from another package that should not be loaded? why, he
moves the definitions around so they fit! he does not, and I repeat: he
does not, sit down to define a standard for which functions are needed in
the "Core Emacs Lisp" and try to get all the packages in the system be
expressible in that language. but such is what Core Lisp would be to
Common Lisp.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* Rainer Joswig
>| Reasons for a Core Lisps are:
>|
>| - small footprint is still an advantage on various devices
>| (imaging placing a Lisp system in any arm of a robot)
>
> as others have indicated, ROM is cheaper than RAM.
But ROM is not free in any sense. And some applications will always be
cost-, size-, or power-sensitive.
>| - it's much easier to understand
>
> this is actually not so.
This depends very much on the language specification, and upon the
implementation.
>| - it's much easier to port
>
> you don't port the Lisp code, you port the compiler and run-time system.
I agree with Erik so far...
> if you're even moderately smart, the run-time system is written largely
> in Lisp and what you really need is a proto-Lisp, not a Core Lisp, but
> you wouldn't want anyone to actually program in the proto-Lisp besides
> the engineers who boot up a Common Lisp system.
... and this is where I disagree. What's the difference between
"proto-Lisp" and "Core Lisp"? No one has so much as posted a
hypothetical description of a Core Lisp, so where is your basis for
comparison?
>| - it's much easier to experiment with extensions and changes
>
> this is wrong -- tweaking something is easier than building from scratch.
I don't see how Rainer's comment precludes tweaking.
>| - faster startup time
>
> this is wrong -- startup time is unaffected by total system size.
Again, since no spec has been made available for comparison, I don't see
how one can draw a conclusion either way.
>| - small means also that the kernel fits into current cache sizes
>| (I guess the boost MCL has got from the PowerPC G3 processor
>| is especially because it has a small footprint and the G3 has a
>| nice second level cache architecture)
>
> what use is this when you need space for all the user code that makes
> code worth writing, again?
In general I agree with Erik, though I think the hope is that Core Lisp
+ extensions + application <= cache size.
>| - you might be able to experiment with different GC strategies
>
> unless you by "Core Lisp" mean a proto-Lisp that lives below the real
> Lisp, this does not seem to be a valid argument.
Again, since no one has spec'd a Core Lisp, this can't be answered.
>| - it might be a good teaching vehicle
>
> we've been there before. [...]
I'm not going to comment on this.
>| - it could be the base for an OS kernel
>
> nothing prevents you from doing this already. you don't need somebody
> else to define a Core Lisp for you first, in other words. just do it.
I think you'd have to design a Core Lisp very carefully to be able to
build an OS kernel in it. Most commercial CLs, as they exist today,
wouldn't work. (One notable exception being Symbolics Common Lisp.)
>| - you should be able to run thousands of Lisp threads on a single machine
>| (-> a web server, file server, ...)
>
> this does not relate to system size, only _incremental_ process size. a
> bigger base system will generally have smaller incremental sizes than a
> small base system, where each thread needs to set up its own environment.
Actually this is more a function of the multitasking strategy and
implementation, and as such is not really answerable in the absence of a
spec for same.
> haven't various people tried to produce a Core English already?
What does that have to do with programming languages?
> Core Lisp is a mistake, but it will be a serious drain on the resources
> available in the Common Lisp community. language designer wannabes and
> language redesigners should go elsewhere.
I strongly disagree. To me, Core Lisp is the heart of a layered Lisp
system that can be bulked up to full ANSI CL (or beyond) or pared down
to just the essentials, as the application requires. Few applications
use all the features provided by ANSI CL, so why burden all applications
with them?
Users have been screaming for a core + libraries architecture for years.
It's time we gave it to them.
-- Chuck, definitely not speaking for any Lisp vendors!
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
In article <············@shell5.ba.best.com>, ······@best.com (Chuck Fry) wrote:
> In general I agree with Erik, though I think the hope is that Core Lisp
> + extensions + application <= cache size.
I just would be sufficient to ensure that the most used
parts of a system will fit into the cache: For example
code that will run very often (like incremental GC,
memory allocation routines, the thread scheduler, base
CL library, ...)
and data that might be used very often (prototype objects,
resource pools, symbol tables, ...).
> >| - it might be a good teaching vehicle
> >
> > we've been there before. [...]
>
> I'm not going to comment on this.
The idea is that you want to give students a system
they can understand in one or two semesters and on
which they can base useful work - like experimenting
with multiple processors, distribution or whole program
analysis.
Similar goals have been followed by Scheme (as a teaching
vehicle for introductory computer science) or
by Oberon (which runs on raw PCs.)
In article <·······················@194.163.195.67>,
Rainer Joswig <······@lavielle.com> wrote:
>In article <············@shell5.ba.best.com>, ······@best.com (Chuck Fry) wrote:
>
>> In general I agree with Erik, though I think the hope is that Core Lisp
>> + extensions + application <= cache size.
>
>I just would be sufficient to ensure that the most used
>parts of a system will fit into the cache: For example
>code that will run very often (like incremental GC,
>memory allocation routines, the thread scheduler, base
>CL library, ...)
... interrupt service routines...
>and data that might be used very often (prototype objects,
>resource pools, symbol tables, ...).
Add: the most frequently used levels of the generational allocation
pool.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
From: Christopher R. Barry
Subject: Re: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <87g126zv1h.fsf@2xtreme.net>
······@best.com (Chuck Fry) writes:
> .... and this is where I disagree. What's the difference between
> "proto-Lisp" and "Core Lisp"? No one has so much as posted a
> hypothetical description of a Core Lisp, so where is your basis for
> comparison?
A proto-Lisp is not something for "end-users" or for general
programming. A proto-Lisp may have primitive versions of functions
written in assembly or C that will cause segmentation faults instead
of exceptions if not used correctly and it may also not have any GC
(at least until a later compilation stage) because it is used to
implement the GC. The sole purpose of the proto-Lisp is to
define/compile/boot a higher-level Lisp. It is not to be used by
itself.
A Core Lisp is a "complete" or standalone Lisp which provides the
necessary primitives to implement the full condition system, CLOS, all
of the types or whatever else you decide to leave out. It is safe to
use by itself so it must have at least part of the condition system
implemented, a GC, part of the typesystem and do error checking so
that you can't funcall #'+ on two strings and crash, as you
conceivably could with a proto-Lisp. A Core Lisp would likely be
implemented via a proto-Lisp. A Core Lisp is a "portable CL base
language."
> I strongly disagree. To me, Core Lisp is the heart of a layered Lisp
> system that can be bulked up to full ANSI CL (or beyond) or pared down
> to just the essentials, as the application requires. Few applications
> use all the features provided by ANSI CL, so why burden all applications
> with them?
Erik already addressed this point when he said: "whether you should
allow the tree shaking before rather than after application
development doesn't seem like a question worth answering at this
time."
In a better world I wouldn't be arguing against a Core Lisp but given
the limited resources of the Lisp community I can't help but think the
time could be better spent elsewhere. It seems every software (not
just language) community goes through this "big vs. small" war. Some
years ago with the Linux kernel community there was a good bit of
debating whether the Linux kernel should cater itself better to
embedded, real-time/deterministic applications like automotive braking
systems or robust kernel multithreading and good multiple-processor
scalability like what you would like with a graphical desktop and a
high-end server. Linus went with the latter and a lot of people hated
his decision and there was even an RT-Linux project started which was
a stripped down Linux kernel that couldn't run applications the real
Linux kernel could.
John Mallery, Rainer and whoever else that wants a Core Lisp should
throw together a mailing list and come up with a formal specification
there and then show us what they've got when the're ready to present
something rather than ask J13, the vendors and the Lisp community at
large to do all the work.
[Passing thought: How many implementations of ISLisp are there....]
Christopher
In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> John Mallery, Rainer and whoever else that wants a Core Lisp should
> throw together a mailing list and come up with a formal specification
> there
The last thing I need is advice from a bozo like you.
> and then show us what they've got when the're ready to present
> something rather than ask J13, the vendors and the Lisp community at
> large to do all the work.
That's too much.
You are a real idiot and you are lying. I especially
hate fools like you who have nothing substantial to contribute
other than spreading lies. You don't even
know these people you are talking about. Neither are
you member of J13, nor are you working for a Lisp
vendor. Are you in the "Lisp community"? Did
you contribute anything substantially lately?
Did I miss something?
If you feel you can go on and behave like Erik Naggum
(who is largely responsible for the ugly tone in
this newsgroup) you should get atleast 10% of his brain, first.
I'm not asking anybody to do the work.
Where did you get that from?
I'd like to see a public apology from you for that statement.
These people you are talking about have more contributed
to the "Lisp community" then you ever will.
From: Christopher R. Barry
Subject: Re: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <87d7xazqaz.fsf@2xtreme.net>
······@lavielle.com (Rainer Joswig) writes:
> You are a real idiot and you are lying. I especially
> hate fools like you who have nothing substantial to contribute
> other than spreading lies. You don't even
> know these people you are talking about. Neither are
> you member of J13, nor are you working for a Lisp
> vendor. Are you in the "Lisp community"? Did
> you contribute anything substantially lately?
> Did I miss something?
>
> If you feel you can go on and behave like Erik Naggum
> (who is largely responsible for the ugly tone in
> this newsgroup) you should get atleast 10% of his brain, first.
>
> I'm not asking anybody to do the work.
> Where did you get that from?
John Mallery sent a statement *to J13* calling for a Core Lisp or a
"portable base language."
The post I replied to from Chuck contained:
Users have been screaming for a core + libraries architecture for
years. It's time we gave it to them.
Who is this "we" to which Chuck refers?
Furthurmore Rainer, by debating for a Core Lisp in a public Lisp
community forum such as comp.lang.lisp you are in a way requesting
resources from the Lisp community. I have better things to do with my
time than to explain why this is so to you but if that doesn't make
sense then fine.
> These people you are talking about have more contributed to the
> "Lisp community" then you ever will.
The only named "people I am talking about" in the post of mine you are
refering to are John Mallery and yourself. I'm not convinced that
CL-HTTP is a significant contribution to the Lisp community as long as
Mallery "retains commercial publication rights" (per his license) of
any Lisp program I compile that calls a CL-HTTP function. He could
either properly commercially license the thing and charge for it, or
give it a _real_ free software license. Currently it is in some sort
of limbo. Anyone that contributes code to the basic server is
essentially doing Mallery's work for him since the license flat out
says
"...CL-HTTP was developed by and is owned by John C. Mallery;"
among other things for so-called "community-ware."
And since you make the claim that you have contributed more to the
Lisp community than I ever will (and I'm 19 years old and have owned a
PC a full 2 years now BTW), what may I ask have you contributed to the
community, Rainer Joswig, other than your usual insightful pearls of
wisdom to this newsgroup?
Christopher
In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> > I'm not asking anybody to do the work.
> > Where did you get that from?
>
> John Mallery sent a statement *to J13* calling for a Core Lisp or a
> "portable base language."
I'm not John Mallery.
> The post I replied to from Chuck contained:
I'm not Chuck.
> Furthurmore Rainer, by debating for a Core Lisp in a public Lisp
> community forum such as comp.lang.lisp you are in a way requesting
> resources from the Lisp community.
I'm just discussing this here with people. Whatever
conclusions you draw are your own and not based
on knowledge of anything that is related to this topic.
If **you** will give a tutorial at a Lisp user meeting
and people will come and want to hear what you
have to say - then we will talk again. But until now
you are just posting here without having accomplished
anything (besides having a PC for two years) and you think
that this gives you the right to write personal
attacks or give advice to other people.
> The only named "people I am talking about" in the post of mine you are
> refering to are John Mallery and yourself. I'm not convinced that
> CL-HTTP is a significant contribution to the Lisp community
Who are you that anyone would care whether you are convinced
or not? A community lives from sharing (knowledge,
help, teaching, code, ...). I simply
fail to see any contribution on your side
that gives you any right to talk in this public forum
like you do.
That's your problem, you just fail to acknowledge
that there are people out there that do something
and not talk bullshit like yourself. Simply do
post less and do write more code.
Especially bad is that you are attacking him without
ever talked to him, seen him, in a public forum
where he would not respond to you. This is absolutely bad
style. Instead you present your mad rantings about
the CL-HTTP license. First you need to earn
**your** respect.
> And since you make the claim that you have contributed more to the
> Lisp community than I ever will (and I'm 19 years old and have owned a
> PC a full 2 years now BTW),
That's exactly the reason why you should't take your mouth as
full as you do.
> what may I ask have you contributed to the
> community, Rainer Joswig,
This is another ridiculous question. Even when this is
Usenet you might need to learn to show respect to other
people or they will not want to deal with you.
*** Again a public apology of your statement about me, is necessary. ***
You write "John Mallery, Rainer and whoever else that wants a Core Lisp should
throw together a mailing list and come up with a formal specification
there and then show us what they've got when the're ready to present
something rather than ask J13, the vendors and the Lisp community at
large to do all the work."
I'm not asking others "to do all the work". I don't want
that others get this impression. You have no knowledge at
all about what and whom I ask something. You are neither
member of J13 nor are you working for a Lisp vendor.
So you can have no knowledge at all what I'm asking them
or whether I'm asking them something at all.
* Rainer Joswig
| a bozo like you.
| You are a real idiot
| you are lying.
| I especially hate fools like you
let's just keep this in mind for a second.
| If you feel you can go on and behave like Erik Naggum (who is largely
| responsible for the ugly tone in this newsgroup)
Rainer, I'm not responsible for your behavior. you're responsible for
your own behavior. all the time, with no exceptions. if you don't like
what you see others do, behave better yourself, do not _ever_ blame your
inability to be a mature adult on anyone else. grow up or shut up.
if you want to be angry, be angry, but take responsibility for that, too,
don't pretend that it's somebody else's fault that you are angry. if you
look real close at what I do, I never, ever blame anybody else for my
very own irritation at people, and I have never in my entire life made
anyone else appear to be responsible for my actions. I realize now that
you are really envious of that, but take it out in some other way, OK?
regardless of whether your Baby Lisp is a good idea or not, I think we
have heard enough for a while.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
In article <··············@2xtreme.net>,
Christopher R. Barry <······@2xtreme.net> wrote:
>······@best.com (Chuck Fry) writes:
>> I strongly disagree. To me, Core Lisp is the heart of a layered Lisp
>> system that can be bulked up to full ANSI CL (or beyond) or pared down
>> to just the essentials, as the application requires. Few applications
>> use all the features provided by ANSI CL, so why burden all applications
>> with them?
>
>Erik already addressed this point when he said: "whether you should
>allow the tree shaking before rather than after application
>development doesn't seem like a question worth answering at this
>time."
But ex post facto tree shaking is not always the right answer, because
it's not easy to know what features are in use in a Lisp application,
even with static analysis of the entire program.
Lisp programmers, as the old saw goes, "know the value of everything but
the cost of nothing." A layered implementation would go a long way
towards making the features vs. resources tradeoffs more explicit.
>John Mallery, Rainer and whoever else that wants a Core Lisp should
>throw together a mailing list and come up with a formal specification
>there and then show us what they've got when the're ready to present
>something rather than ask J13, the vendors and the Lisp community at
>large to do all the work.
I think a better idea would be to start with trial implementations, and
derive the specs from experience with them. If we start from arguing
about specs, without a trial implementation, we could spend years and
never have anything tangible to show for it. It's easy to imagine
castles in the sky; it's a lot harder to build usable structures on the
ground.
>[Passing thought: How many implementations of ISLisp are there....]
I think you just proved the point of my last paragraph.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
* Chuck Fry wrote:
> But ex post facto tree shaking is not always the right answer, because
> it's not easy to know what features are in use in a Lisp application,
> even with static analysis of the entire program.
I think this is one of those things that you can fix quite easily
though. You just say `I am not using anything but what you can work
out I am, and this stuff'. Of course you could be wrong and your
program will then break at runtime, which a layered system would not
do.
This is rather similar, it seems to me, to the anti-CLOS arguments one
sometimes hears (or used to hear), which have the general form of
`because CLOS allows redefinitions of almost anything, you can never
optimise'. Well that is true, but an implementation is quite free to
add (non-standard) `sealing' declarations and then optimise everything
to hell. If you violate those declarations, you'll lose, but no worse
than you would in a language which supported them in the language. If
implementations of these appears perhaps at some point they could be
standardised.
Which leads on to...
> I think a better idea would be to start with trial implementations, and
> derive the specs from experience with them. If we start from arguing
> about specs, without a trial implementation, we could spend years and
> never have anything tangible to show for it. It's easy to imagine
> castles in the sky; it's a lot harder to build usable structures on the
> ground.
I agree strongly with this. If there is demand, let there be
implementations first, then standards!
--tim
* Chuck Fry
| What's the difference between "proto-Lisp" and "Core Lisp"? No one has
| so much as posted a hypothetical description of a Core Lisp, so where is
| your basis for comparison?
a proto-Lisp is very close to the compiler and the machine and has access
to a lot of low-level stuff, like pointers, representational details of
complex types, etc, and allows you to isolate them from the exported
Lisp. as a Core Lisp has been described (by intended use), it would be a
programming language in its own right, defining primitives upon which the
rest of Common Lisp needs to be defined, but which are primitives and
which need access to the machine is very hard to tell. CLOS could be
defined entirely in a Common Lisp sans CLOS, but to make it perform well,
you need a lot of access to lower-level stuff. efficient stream I/O is
the same way, and the two combined really need special support to do well.
| > this is wrong -- startup time is unaffected by total system size.
|
| Again, since no spec has been made available for comparison, I don't see
| how one can draw a conclusion either way.
by watching other systems, large and small, of course. size of the
system has nothing to do with it. that is, other factors are so much
more important that system size becomes completely irrelevant.
| > haven't various people tried to produce a Core English already?
|
| What does that have to do with programming languages?
if you ask hard enough questions, no answer about programming languages
has to do with programming languages. take Kent's many philosophic,
linguistic, and psychologic comments. they aren't about programming
languages per se, but about people defining and using programming
languages, and as long as we are human, that actually has strong merit.
if we aren't considering humans, however, a lot more options become
available in programming language design, and none of the lessons learned
from other experiments involving languages and humans have any bearing on
what we do.
| Users have been screaming for a core + libraries architecture for years.
| It's time we gave it to them.
users have asked for features and extensions to Perl and C++, and that's
what they got. I think the tobacco industry uses the same core argument.
the good way is to give people what they need to be happy, not what they
want. they want core + libraries, but that's not what they need, as
every person who has set out to do this in the past have discovered.
what they _do_ need is very hard to figure out as long as they keep
thinking they need core + libraries. the problem is: when people _get_
core + libraries, they want languages with everything in them, because
it's a terrible mess to deal with core + incompatible and overlapping
libraries.
let's take a good look at what core + libraries would solve, and let's at
least pretend that core + libraries is not the solution. which _other_
ways to obtain the desiderata will we find in our search?
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
From: Lars Marius Garshol
Subject: Re: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <wk7lnjxzvn.fsf@ifi.uio.no>
* Rainer Joswig
|
| "* CL Portable Base Language: Develop a base language to which all
| extant Common Lisp implementations can be targeted. This language
| should include locatives and basic OS operations like processes,
| file I/O, networking.
Does anyone know what the chances are that this will actually happen?
Is it controversial in any way that this should happen? Is there
interest?
--Lars M.
In article <··············@ifi.uio.no>,
Lars Marius Garshol <······@ifi.uio.no> wrote:
>
>* Rainer Joswig
>|
>| "* CL Portable Base Language: Develop a base language to which all
>| extant Common Lisp implementations can be targeted. This language
>| should include locatives and basic OS operations like processes,
>| file I/O, networking.
>
>Does anyone know what the chances are that this will actually happen?
I have no idea.
>Is it controversial in any way that this should happen? Is there
>interest?
Yes, it's controversial -- look at the discussion in this thread
already.
Is there interest? Yes, I'm interested! I think there are many good
reasons for a standardized core Lisp, which I don't have time to
enumerate right now.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
From: Lars Marius Garshol
Subject: Re: Core Lisp (was Re: cautios question (about languages))
Date:
Message-ID: <wk6733xwap.fsf@ifi.uio.no>
* Lars Marius Garshol
|
| [CL Portable Base Language]
| Is it controversial in any way that this should happen? Is there
| interest?
* Chuck Fry
|
| Yes, it's controversial -- look at the discussion in this thread
| already.
That discussion seems to be about Core Lisp, not CL Portable Base
Language. (OK, Marco mentioned it, but nobody else seems to have.)
| Is there interest? Yes, I'm interested! I think there are many
| good reasons for a standardized core Lisp, which I don't have time
| to enumerate right now.
I'm not sure if I care about core Lisp, but I do care about the PBL.
--Lars M.
······@lavielle.com (Rainer Joswig) writes:
> GCL and Clisp (as nice as they are) fail to support crucial
> things like an advanced GC, threads and performance.
I am not all that in favor of Threads in Lisp as long as there is no
standard set in stone. (Yes. CLIM docs have one. How widepsread is it?)
Let me comment on the following.
> Reasons for a Core Lisps are:
>
> - small footprint is still an advantage on various devices
> (imaging placing a Lisp system in any arm of a robot)
Good reason
> - it's much easier to understand
Not necessarily
> - it's much easier to port
Not necessarily
> - it's much easier to experiment with extensions and changes
What "extensions"? I would disagree with this. Extensions should be
seen only in conformance with the ANSI standard.
...
>
> There were projects in this direction already.
> Minima was a mininal Lisp system from Symbolics
> (the opposite of Genera, so to speak). You could have
> embedded systems running Minima. Symbolics
> even once built special hardware for a customer:
> http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/zora/zora.html
> See L, etc.
>
>
> or to quote "Modernizing Common Lisp: Recommended Extensions", John Mallery, ...:
>
> "The most important recommendation with the most leverage is the
> recommendation to develop a PORTABLE BASE LANGUAGE FOR COMMON LISP.
> This strategic move provides:
>
> * An opportunity to reengineer the core language;
> * A minimal base to port to new platforms;
> * Opportunities for new hardware and compiler efforts
> (base-to-platform & portable-to-base);
> * Increased sharing of higher-level code."
>
> ...
>
> "* CL Portable Base Language: Develop a base language to which
> all extant Common Lisp implementations can be targeted. This
> language should include locatives and basic OS operations like
> processes, file I/O, networking.
I beg to differ. All of these 'desiderata' are not part of a 'core'.
They are desirable features of a full blown system programming
language. May of thes could be *added* to CL as it is, by providing
an appropriate set of packages (i.e. many of them).
> This base layer will
> increase portability of lisp applications and enable work to
> improve performance with specialized hardware or compilers.
> This layer should make efforts to support real-time and
> parallel dialects. Experimental, Very High Impact, Examples,
> Implementations, Hard. KR, RL, JM"
If we consider Java as a sort of hindsight on many CL design decisions
(as I think it is), we see that the story does not go this way, when
it comes to embedded systems (read: memory constrained - that's the name of
the game).
The latest "small" JVM from Sun and Motorola (the KVM) runs in about
80k with a given set of libraries. It runs on the Palm Pilot. But
its main characteristic is that it *drops* many of the features of the
JDK that - by similitude - according to Mallery should go in the
'core' CL. I do not know what kind of GC or threading they provide in
the KVW, but certainly they sacrificed portability of code. An
application for the KVM/Pilot will most likely not run under a generic
JVM higher in Sun's hierarchy of Java architectures.
So the story is very simple. You need to *drop* parts of the
language. Not requiring *extra* things like networking.
Apart form this there are trends in embedded systems which seems
couterintuitive to the software engineer. An embedded device is never
(at least until now) built according to *what it should do*. The
cycle is more like.
Hardware engineer along with manager:
"Let's 16 bytes and a third of memory on the chip which will cost 4
USD, now let's cram the very complex RANDOM number generator on it.
If we don't do it this way then somebody else will and they will sell
their system to the system integrator"
Software engineer:
"But for .25 USD more we can have 472 bytes and four fifths of memory
and then I will be able to add PLUS to the system."
Hardware engineer along with manager:
"Ary you mad?"
Of course, if you then count the number of chips in a car you'll be
astounded (upper tier BMWs have about 20). But the realization that
having more memory and less chips may be more cost effective in terms
of 'time to market' and reusability is not there yet. After all,
capitalism is all about quarterly reports. As Quark said in Rule of
Acquisition #X, "Long term benefits are always less important than
short term profits". :)
BTW. This are personal opinions which do not reflect that of my
collegues and bosses :)
So, the story is the following. If you want to have a (Common) Lisp
running on an embedded system today, you need to shoot for a <100K
"processor" which should include some form of GC. Anything different
would not work. The core language should run with this contraints in
mind and be specified in such a way to have the full CL runnable on
it, once the memory contraints are lifted.
(end-of-ranting)
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>,
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>······@lavielle.com (Rainer Joswig) writes:
>> or to quote "Modernizing Common Lisp: Recommended Extensions", John Mallery, ...:
>>
>> "The most important recommendation with the most leverage is the
>> recommendation to develop a PORTABLE BASE LANGUAGE FOR COMMON LISP.
>> This strategic move provides:
>>
>> * An opportunity to reengineer the core language;
>> * A minimal base to port to new platforms;
>> * Opportunities for new hardware and compiler efforts
>> (base-to-platform & portable-to-base);
>> * Increased sharing of higher-level code."
>>
>> ...
>>
>> "* CL Portable Base Language: Develop a base language to which
>> all extant Common Lisp implementations can be targeted. This
>> language should include locatives and basic OS operations like
>> processes, file I/O, networking.
>
>I beg to differ. All of these 'desiderata' are not part of a 'core'.
>They are desirable features of a full blown system programming
>language. May of thes could be *added* to CL as it is, by providing
>an appropriate set of packages (i.e. many of them).
Marco is right, these are desirable features of a full blown system
programming language. Consider the source. This recommendation comes
from people with substantial experience with Lisp *as a system
programming language*.
Why should anyone want any less from a language? If you want less than
a full blown system programming language, use Java.
Without seeing a detailed proposal, I don't think it's fair to comment
on the necessity of supporting file I/O, processes, etc. in the base
Lisp. There are a range of underlying multitasking/multiprocessing and
file system implementations in the world today, and I don't think a
one-size-fits-all approach will work for all of them. If you assume a
typical workstation or PC environment, there may be enough commonality
to get away with this.
>> This base layer will
>> increase portability of lisp applications and enable work to
>> improve performance with specialized hardware or compilers.
>> This layer should make efforts to support real-time and
>> parallel dialects. Experimental, Very High Impact, Examples,
>> Implementations, Hard. KR, RL, JM"
>
>If we consider Java as a sort of hindsight on many CL design decisions
>(as I think it is), we see that the story does not go this way, when
>it comes to embedded systems (read: memory constrained - that's the name of
>the game).
But small embedded systems, while an important application domain, are
not the only game in town.
>The latest "small" JVM from Sun and Motorola (the KVM) runs in about
>80k with a given set of libraries. It runs on the Palm Pilot. But
>its main characteristic is that it *drops* many of the features of the
>JDK that - by similitude - according to Mallery should go in the
>'core' CL.
But again, look at the environment in which it's meant to run. That's
appropriate for a system with one user, extremely limited I/O, limited
memory, and no file system to speak of.
>So the story is very simple. You need to *drop* parts of the
>language. Not requiring *extra* things like networking.
[... much deleted ...]
>So, the story is the following. If you want to have a (Common) Lisp
>running on an embedded system today, you need to shoot for a <100K
>"processor" which should include some form of GC. Anything different
>would not work. The core language should run with this contraints in
>mind and be specified in such a way to have the full CL runnable on
>it, once the memory contraints are lifted.
I think the conflict here is that Marco is thinking of a Lisp that would
run *exclusively* in embedded-system-like environments, while the MIT
team is probably thinking about richer environments. I don't think you
can satisfy both requirements with a single implementation. But I could
be wrong.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
In article <············@shell5.ba.best.com>, ······@best.com (Chuck Fry) wrote:
> Marco is right, these are desirable features of a full blown system
> programming language. Consider the source. This recommendation comes
> from people with substantial experience with Lisp *as a system
> programming language*.
These are also questions that will come up when
you start writing applications like a web server.
Not a toy one, but one where really large amounts of people
will issue requests. ***I*** want to be able
to use a web server to serve the site of,
say, the Time magazine. I don't want to have it
crawl because the threading is brain damaged,
a full GC runs every five minutes or I'm losing
cycles while the system is busy thrashing its
caches. And I want to write my code in Lisp.
CL-HTTP at the White House site for example runs on two
Virtual Lisp Machines (also using fancy stuff like
the Statice OODB). It must be possible
to deploy this stuff using stock hardware
using either a Lisp-only system or a "conventional"
Lisp running on a OS like Solaris or even Windows NT.
The customers **I'm** thinking of are publishing
companies with **huge* amounts of hits on their
web sites - companies using stuff like PHP3 (shudder)
added to Apache.
On Fri, 30 Jul 1999 02:32:38 +0200, ······@lavielle.com (Rainer Joswig)
wrote:
> CL-HTTP at the White House site for example runs on two
> Virtual Lisp Machines (also using fancy stuff like
What is a _Virtual_ Lisp Machine? A Symbolics LispM card for Macs?
Paolo
--
Paolo Amoroso <·······@mclink.it>
In article <··············@rainbow.studorg.tuwien.ac.at>, ········@ag.or.at wrote:
> ·······@mclink.it (Paolo Amoroso) writes:
>
> > On Fri, 30 Jul 1999 02:32:38 +0200, ······@lavielle.com (Rainer Joswig)
> > wrote:
> > =
>
> > > CL-HTTP at the White House site for example runs on two
> > > Virtual Lisp Machines (also using fancy stuff like
> > =
>
> > What is a _Virtual_ Lisp Machine? A Symbolics LispM card for Macs?
>
> These cards are called Ivory.
The processor is called "Ivory". The card for the Macs is
called MacIvory (1, 2 or 3).
> A virtual Lisp Machine is Genera (the OS of the Symbolics Lisp
> Machines) running under Digital Unix (or whatever it's called now) on
> an Alpha.
A Virtual Lisp Machine is Open Genera running under Digital
Unix on DEC Alpha. Open Genera has an assembler coded
emulator of the Ivory processor underneath.
> I've been told they need two Virtual Lisp Machines because one VLM
> tends to have long (full) GC times.
Hmm, it might also be for having two machines answering requests.
······@best.com (Chuck Fry) writes:
...
> >So, the story is the following. If you want to have a (Common) Lisp
> >running on an embedded system today, you need to shoot for a <100K
> >"processor" which should include some form of GC. Anything different
> >would not work. The core language should run with this contraints in
> >mind and be specified in such a way to have the full CL runnable on
> >it, once the memory contraints are lifted.
>
> I think the conflict here is that Marco is thinking of a Lisp that would
> run *exclusively* in embedded-system-like environments, while the MIT
> team is probably thinking about richer environments. I don't think you
> can satisfy both requirements with a single implementation. But I could
> be wrong.
Yes and no. My problem is that the word "core" evokes in me the
enotion of something "small". Hence my posting.
The idea of layering is not new and it should be pursued, at least to
get things right first. *Then* we get them fast.
It just seems to me that what Mallery originated is the notion that
you need to get some "fundamental" things (for lack of a better
adjective) in the current CL design. E.g. multithreading (not only
this of course), which right now is not present in a satisfactory way
in CL implementations.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
······@lavielle.com (Rainer Joswig) writes:
> > -- and one
> > apparently very portable commercial offering -- Franz Allegro.
>
> "Portable" is relative - portable across Unix systems perhaps?
>
Unix and Windows 9x and NT. I get the impression that they can port
to anything pretty much including embedded-type systems, but Duane or
someone should speak to that.
--tim
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > > -- and one
> > > apparently very portable commercial offering -- Franz Allegro.
> >
> > "Portable" is relative - portable across Unix systems perhaps?
> >
>
> Unix and Windows 9x and NT. I get the impression that they can port
> to anything pretty much including embedded-type systems, but Duane or
> someone should speak to that.
Hmm, it's surely nice that they now have it "portable".
But it took them quite some time to do so.
Earlier ACL versions were different between Windows and Unix.
Having ported it to Unix and Windows doesn't make it
"very portable", IMHO.
I will answer both of these together:
> In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>
> > ······@lavielle.com (Rainer Joswig) writes:
> >
> > > > -- and one
> > > > apparently very portable commercial offering -- Franz Allegro.
> > >
> > > "Portable" is relative - portable across Unix systems perhaps?
> > >
> >
> > Unix and Windows 9x and NT. I get the impression that they can port
> > to anything pretty much including embedded-type systems, but Duane or
> > someone should speak to that.
There are two aspects of a port that one must worry about:
1. The architecture. This is usually not a problem for byte-code
lisps, And is an extra task for us. However, we have the porting
effort to new architectures down to a relatively short time; it used
to take over a year to add a new architecture to our fold, but now it
is a matter of weeks. Optimizations can follow, but correctness comes
quickly.
2. The os interface. This is the major problem for all lisps, and
it tends to level the playing field. (lisp is is not the only language
that is affected, though; and even that great high-level assembler, C,
sometimes bleeds some os differences through to the user). C is usually
otherwise portable because it is well-understood and is the major
language that almost every hardware-vendor provides for their product.
Porting to embedded systems will mostly depend on the system/monitor
interface, but should not be too hard. Instead, it is more a question
of the demand for such a thing; most of the ports we've done we've either
been paid for or we've decided it was good business based on the general
nature of the architecture; embedded systems are less general, and though
we've been approached for ports to them, I can only remember once when
we were actually offered money to do the port.
Our lisp is definitely not as portable, even theoretically, as one that
is written in a different language such as C, or one that compiles to
a virtual lisp machine that executes byte-codes, due to the necessary
architecture port. However, we have seen problems with byte-code lisps
(e.g. emacs/xemacs, which used to generate portable byte codes no longer
do so). It is up to each vendor to exercise control over the
implementations they keep and the versions they run on. I believe
that we are very competitive in that area: For example, I have 16 rlogins
to different machines at all times in my xemacs; when I run a script that
makes our lisp it runs on 19 different machines at once, including an
x86/NT and Alpha/Nt machine over various rsh packages. Thus, I keep
my development in-sync at (almost) all times.
This results in a different kind of portability; one where the user sees
identical results on all ports of the same version of Allegro on all
architectures [Disclaimer: this is the goal, not always attainable].
Over time our support staff has had a harder time being able to tell
the difference when customers send in bug reports. And, as a measure
of the success of the ports, the number of times in which it makes a
difference what architecture the problem is on has become smaller over
time, as well.
······@lavielle.com (Rainer Joswig) writes:
> Hmm, it's surely nice that they now have it "portable".
> But it took them quite some time to do so.
Yes, it did.
> Earlier ACL versions were different between Windows and Unix.
This is exactly why it took so long. The two versions were night
and day. One was CLtL1 + CLOS, and the other was post-CLtL2. One
was multithreaded and one was not. We took the unix lisp, ported to
the x86 (the linux version was a side-effect of this), and then
ported to NT and put CG on top for the NT port. It was definitely
our hardest port.
> Having ported it to Unix and Windows doesn't make it
> "very portable", IMHO.
That is correct. However, we've learned a lot from doing all of
these ports, and so the next challenges become much easier each
time. We had also had experience in other operating systems, like
DEC/VMS and IBM VM/360, and though these didn't work out business-wise,
they contributed to the portability of our o/s interface. We were
also on Crays and Amdahls, but since Unicos and UTS are both unix, they
don't qualify as different.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> I will answer both of these together:
Thanks for your thoughtful reply.
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> > Having ported it to Unix and Windows doesn't make it
> > "very portable", IMHO.
>
> That is correct. However, we've learned a lot from doing all of
> these ports, and so the next challenges become much easier each
> time. We had also had experience in other operating systems, like
> DEC/VMS and IBM VM/360, and though these didn't work out business-wise,
> they contributed to the portability of our o/s interface. We were
> also on Crays and Amdahls, but since Unicos and UTS are both unix, they
> don't qualify as different.
Could you comment on the "difficulty" of porting it to say
Be OS or MacOS X?
I was quite surprised to see Franz supporting Linux PPC -
was that one of the "few weeks" ports? I found it
a bit amazing that you could afford the effort to do the
port - it's a good sign, though.
······@lavielle.com (Rainer Joswig) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
> > > Having ported it to Unix and Windows doesn't make it
> > > "very portable", IMHO.
> >
> > That is correct. However, we've learned a lot from doing all of
> > these ports, and so the next challenges become much easier each
> > time. We had also had experience in other operating systems, like
> > DEC/VMS and IBM VM/360, and though these didn't work out business-wise,
> > they contributed to the portability of our o/s interface. We were
> > also on Crays and Amdahls, but since Unicos and UTS are both unix, they
> > don't qualify as different.
>
> Could you comment on the "difficulty" of porting it to say
> Be OS or MacOS X?
I honestly don't know BeOS. From what I understand, it is a fully
preemptive multitasking os like unix, so it might not be hard. I
hadn't looked at it lately ever since it lost the bid to replace
Rhapsody, about the same time Jobs came back to Apple and shut the
hardware OEMs down.
MacOS X server is just BSD4.x on top of the Mach kernel.
> I was quite surprised to see Franz supporting Linux PPC -
> was that one of the "few weeks" ports?
Actually, it was only a few days :-) There were a few trivial changes
to make it compatible with the MkLinux port, which was a few-weeks
port. That might not be a fair statement, however, since the actual
time span was over a year; we actually started the port on the DR 2.1
release of MKlinux, when Apple was still "supporting" it; we had to
report some of the same bugs that we had reported to linux/x86 a year
or so before that. In manpower scale, though, it was not hard.
> I found it
> a bit amazing that you could afford the effort to do the
> port - it's a good sign, though.
Perhaps we are a little more portable than you might think! And I
had forgotten about another port in my last post: remember Allegro
CL 3.0 on NeXT? To the extent that Mach is any different than unix,
we do have experience on that one, too. And though we didn't have
a window-interface to NeXT, note that the MacOS X Yellow Box is really
Rhapsody, which is ... which is really NeXTstep...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote: [1999-07-29 17:08 -0700]
[...]
> We had also had experience in other operating systems, like
> DEC/VMS and IBM VM/360
[...]
That's interesting. I didn't know anyone ever contemplated
providing Common Lisp on a strictly-IBM platform. Is there
publicly accessible information about your IBM effort?
(I assume you mean VM/370 (it had only an experimental
implementation on a 360 as far as I know) which later became
VM/SP etc.)
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Vassil Nikolov <········@poboxes.com> writes:
> Duane Rettig wrote: [1999-07-29 17:08 -0700]
>
> [...]
> > We had also had experience in other operating systems, like
> > DEC/VMS and IBM VM/360
> [...]
>
> That's interesting. I didn't know anyone ever contemplated
> providing Common Lisp on a strictly-IBM platform. Is there
> publicly accessible information about your IBM effort?
No, it never got past the alpha stage. The project languished when
we couldn't find any customers. Not that we knew _how_ to find
customers in an IBM world at that time ...
> (I assume you mean VM/370 (it had only an experimental
> implementation on a 360 as far as I know) which later became
> VM/SP etc.)
You're correct, thanks. I always get those numbers mixed up,
having come from an Amdahl background, where the magic numbers
were 470, 580, and 5890. I guess I could have just called it VM
or VM/CMS, as well.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote:
>
> Vassil Nikolov <········@poboxes.com> writes:
>
> > Duane Rettig wrote: [1999-07-29 17:08 -0700]
> >
> > [...]
> > > We had also had experience in other operating systems, like
> > > DEC/VMS and IBM VM/360
> > [...]
> >
> > That's interesting. I didn't know anyone ever contemplated
> > providing Common Lisp on a strictly-IBM platform. Is there
> > publicly accessible information about your IBM effort?
>
> No, it never got past the alpha stage. The project languished when
> we couldn't find any customers. Not that we knew _how_ to find
> customers in an IBM world at that time ...
AS/400 looks really popular now, probably it is fairly POSIX compliant
and it runs on PowerPC's - I always wondered why no one needs CL on it.
Maybe C based systems like Elwood CL run on them just fine?
Robert
Robert Monfera wrote:
> AS/400 looks really popular now, probably it is fairly POSIX compliant
> and it runs on PowerPC's - I always wondered why no one needs CL on it.
From my limited experience, I am not a big fan of AS/400. IMHO a more
useful task than porting CL to this most excellent OS would be ... I don't
know ... counting the number of angels that you can fit on the head of pin
...
:-) will
Robert Monfera <·······@fisec.com> writes:
> AS/400 looks really popular now, probably it is fairly POSIX compliant
> and it runs on PowerPC's - I always wondered why no one needs CL on it.
> Maybe C based systems like Elwood CL run on them just fine?
> Robert
I'd guess that the overlap between the AS/400 community and the CL
community is rather smallish. If you look at what uses AS/400s have
been traditionally put to (things like domain-specific business
applications), you are squarely back into an area, where CL is not
a well-known contender. So you'd have to create your market for a CL
implementation first, which most CL vendors would find difficult
currently.
I guess it's sad, because I still think that CL would shine in the
complex, inter-dependend, mission-critical environment that most
business applications currently inhabit. Having had first and
second-hand experience with SAP R/3, I'm all the more convinced that
the current way isn't the right way. But you'd have to overcome
deep-rooted prejudices/traditions first...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
In article <·······················@194.163.195.67>,
Rainer Joswig <······@lavielle.com> wrote:
>How big is a working Franz Allegro lisp image? Last time I looked,
>ACL generated really large code on RISC machines
>(has this changed?).
In general, RISC trades compactness of object code for the ability to
execute that code very quickly. The reasons are obvious: the typical
3-register fixed-length instruction format with 16 or more registers
from which to choose, in combination with a limit of one relatively
simple operation per instruction.
Contrast this with the x86 architecture, which is accumulator-based with
a small number of registers, but whose instructions are variable length,
and thus require more logic to decode. The x86 wins on code density for
many simple code fragments, but the limited number of registers requires
much saving and restoring when computations are more involved.
Also note that a lot of Allegro's perceived "bloat" in small functions
is type-checking and other overhead, which (when appropriate to the
task) can be reduced or eliminated with the right declarations and good
data structure design.
-- Chuck, longtime Allegro user and student of CPU architecture
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
* Rainer Joswig wrote:
> - you could run it on bare PCs
> - you could run it in switches
> - you could run it as networking nodes running web servers, ...
> - you could use it on board of a space ship
> - you could put it on robots
> - you could put it in a game console
> - ...
But full CL is already small enough to do at least the space ship
part, and I'd guess all the others too (game consoles, for instance
are really big machines now). CL is really a small system these days.
There may be other reasons for a small core, but these are probably
not very good ones.
--tim
In article <···············@lostwithiel.tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> * Rainer Joswig wrote:
>
> > - you could run it on bare PCs
> > - you could run it in switches
> > - you could run it as networking nodes running web servers, ...
> > - you could use it on board of a space ship
> > - you could put it on robots
> > - you could put it in a game console
> > - ...
>
> But full CL is already small enough to do at least the space ship
> part, and I'd guess all the others too (game consoles, for instance
> are really big machines now).
The next generation maybe - not the current one.
- Both Nintendo 64 and the Playstation have tight limits on RAM.
- Nintendo 64 has a big limit: the cartriges are expensive.
The largest ones are currently 32 MB (256 Mbit).
- The Playstation currently has the limit of a double
speed CD-ROM drive - which makes loading things a pain.
> CL is really a small system these days.
>
> There may be other reasons for a small core, but these are probably
> not very good ones.
>
> --tim
It's really funny. I get some complete different answers on
this topic. Some say yes, space is a big problem - others
say no it isn't.
In article <·······················@194.163.195.67>, ······@lavielle.com (Rainer Joswig) wrote:
> > But full CL is already small enough to do at least the space ship
> > part, and I'd guess all the others too (game consoles, for instance
> > are really big machines now).
>
> The next generation maybe - not the current one.
>
> - Both Nintendo 64 and the Playstation have tight limits on RAM.
Oops, forgot to mention the Nintendo Gameboy, which is not
a console - but a **very** popular gaming platform,
······@lavielle.com (Rainer Joswig) writes:
> What the Common Lisp community needs (IMHO, -> see the "MIT List"),
> is a small Common Lisp core (incl. threads and networking).
> The small core then could be moved around (different platforms,
> distributed computing, web stuff, new compilers, ...) much faster.
> It also could be the kernel for a new operating system.
Well, there is already the possibility of sub-setting the existing
standard. The problem here might be, that those who want to sub-set
can't agree on a common sub-set. It might be advantageous to discuss
such a common sub-set in a sub-group of the current standardization
process. OTOH, I don't see who _of the implementors_ would be
interested in such a sub-set. Those which have existing
implementations probably don't need a sub-set, or they would have
created one already.
That would only leave those implementors, which _don't_ have an
existing (fairly complete) implementation. I don't see many of those
around. And without an implementor of the sub-set, what good would
the sub-set do? And more importantly, who would design it? Without a
specific audience and implementor in mind, I don't see how a good
sub-set could be created. IIRC similar reasons where the cause for
the current situation, where sub-sets are allowed, but no standard
sub-sets where defined. See the corresponding write-up (which IIRC,
is included in the HyperSpec).
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <379ECCC4.1D4269CA@iname.com>
Kent M Pitman wrote:
> resolution of conflicts. Languages are like political parties; you
> should choose the one that is maintained by people who think like
> you do and care about the things you care about. It sounds, based on
> your brief summary like that would be the Scheme crowd.
But the OO thing pushes him to che CL side so..
But now that one can do FUN, instead of #'FUN,
(lambda ..) instead of #'(lambda ..)
((lambda ..) ..) instead of (funcall (lambda ..) ..)
what's left are warts like (funcall fun ..) and naming inconsistencies
[no real prob with the latter, just define nullp (or null?, pair? (or cons?)),
etc]
Saying (CAR NIL) (CDR NIL) are wrong is just a game of words, and whether Lisp
or Scheme is right about #f is one of the great mysteries of the universe..
If you read "The Little Schemer", only in a couple of occassions does the
ugliness show.
The package system is constantly under attack, and while some Schemes have
nice module systems (eg: MzScheme), there's no standard.
You can write beautiful code in CL. Maybe it not "perfect", but it's not so
far from that.Scheme is small, so you can get all of it quick. Get your basic
lisp style up and running.
Then look at CL. You can learn things you never dreamed of while doing
Smalltalk, Eiffel, etc. (maybe tinyclos would do too, but I'm not sure.
Certainly tinyclos is nicer, but it's the son of CLOS, after all). You'll find
several books on CLOS. Will you find _any_ for the Scheme object systems
(practically all of which cannot even touch CLOS?).
BTW, don't let _anybody_ talk you into believing that CL is to Scheme as C++
is to C, that's plainly an extremely innacurate and dangerous analogy.
Welcome to schizofrenia ;-)
[PS: I have an Eiffel background, am charmed by Scheme's and purely functional
languages, but I'm happy with CL (sometimes I'll wonder "what's next" but I'll
look more to FP than to Scheme). It's easy to think about Scheme being `dirty'
then, too.
I really hate bad stuff, including C++, and sometimes I surprise myself when I
do some design using templates that is `cool', or by liking some well written
software like ACE, that makes things `neat' (it's a dellusion, bu we all know
that ;->).
So maybe you can take CL. That's your call.]
Fernando Mato Mira <········@iname.com> writes:
Replying not specifically to you, Fernando, but to some specific things
you said that triggered me to want to add some general points
in this discussion. Your words included, semi-out-of-context, to help
understand what triggered these thoughts.
> But now that one can do FUN, instead of #'FUN,
> (lambda ..) instead of #'(lambda ..)
>
> ((lambda ..) ..) instead of (funcall (lambda ..) ..)
>
> what's left are warts like (funcall fun ..) and naming inconsistencies
> [no real prob with the latter, just define nullp (or null?, pair?
> (or cons?)), etc]
I will continue to defend FUNCALL as a non-wart. I think it's the
other way around. At the very minimuym, you should understand that
there is an equally strong aesthetic theory by which (F X) to call a
variable F is UNaesthetic. The Scheme community, in keeping with
their one-namespace view, also often have a one-aesthetic chauvinism
as well. The issue that divides us is less the technical decision for
"a single namespace" and more the political decision for "single
decisions". My favorite quote in this area is from an unknown source
which I would happily and gratefully identify if I could: "There are
two kinds of people in the world: people who think there are two kinds
of people in the world and people who do not."
I also think a lack of political inclusivity is a wart. We know very
little about the human brain, probably, compared to what we might
know. But among those things we know is that it is capable of
accomodating a huge amount of what the Scheme community would call
"unaesthetic" complexity. That is, the kinds of natural languages
people devise are full of special case and we have special brain
hardware that make our use of that quite efficient. To build languages
that do not take good advantage of our ability to do this is to
waste our personal processor power. All the claims that are made about
what languages are learnable or not are unscientific anecdotes
based on claims of how hard it was for teachers who had a bias toward
certain presentations or who had prsentations differing in huge ways
(not just namespace) retrospectively and unscientifically gauging reasons
and surely boiling them down to reasons that due not satisfy any definition
of science I know. My experience is that CL is easy to teach to anyone
who has not been fed propaganda from other languages about how languages
"should be" and who does not balk merely because he/she has been
trained to balk. Just as the whle LISP family is easy to teach to anyone
who has not been trained to balk at non-infix. The degree to which
the aesthetics by which Lisp is often externally judged is born with
you is questionable at best. People do have a born-in aesthetics, but
I think they often unlearn their intuitions about it when faced by a lack of
ability to articulate it and a pushy person who purports (sometimes without
foundation) who alleges to be able to articulate what they think better
than they themselves can do. People LEARN to be bothered by two namespaces
because they are TAUGHT to think namespaces don't matter. But namespaces
are ROUTINELY used in natural language, and people accomodate them very well.
Almost no word in any naturally arising human language has only a single
definition, and yet people do not rise in revolt at this "lack of elegance".
They resolve by context. If you want to do SCIENCE about what is and
is not "natural", the data awaits and it does not come from languages
that are made and taught by their makers to captive audiences over a five
to twenty year span.
Human-derived attempts to make unambiguous languages have gone
nowhere. English, which is full of contextual nuance and blunt
construction, has won over the regularities of Latin and Greek and the
pseudo-regularities of languages like Spanish and German partly, at
least, because people don't have patience with aesthetics when they
stand in the way of practicality. They want to ELECT practicality
when it suits their need, but they don't want to be REQUIRED
practicality.
> You can write beautiful code in CL. Maybe it not "perfect", but it's not so
> far from that. Scheme is small, so you can get all of it quick.
Short languages make long programs, I claim.
Long languages make short programs.
The more pre-defined stuff you can draw on, and the richer
the available set of words in a given context, the fewer words
you must say to get across your meaning. Langauges that syntactically
isolate you from the space of things you would say at a given moment
in a given program make either the program bigger (as you say more baroque
things or as you rewrite your program to avoid saying baroque things).
In CL, if you have written
(defun foo (list) ... <cursor>
and you want to now access the LIST function, you can do it with only local
editing. You can ALSO access the LIST function with only local editing.
In Scheme, the decision to bind the variable LIST is a [premature]
decision not to use the variable LIST in the program you are writing.
To access the outer variable requires rewriting the program. This is
usually "compensated" for by not ever using the obvious names in
programs, preferring variables like "LST". This makes programs
inelegant, too [that is, by someone elses's (my) metric, metrics of
elegance not being uniquely determined], because it doublles the size
of the local set of terms, having in effect to always choose different
names for globally defined names than local ones.
CL allows the decision about which LIST to access to be locally
administered, and the "price" (to some) or "feature" (to others) of
this is that the kind of use is case-marked. (FUNCALL f x) identifies
the UNUSUAL (in CL) and less syntactically optimized case of calling a
variable in ordder to allow (f x) to mean a call to the thing
familiarly known as F without fear that F has been locally bound.
This is a simple trade-off. Scheme assumes you will be passing so
many functions that you will have at least an equi-likely chance of
wanting to call a variable named F as a globally defined function
named F, and so it assumes you want to optimize this case. Most CL
programmers I know would gag if functional args were passed around
with enough frequency to justify optimizing this case. Likewise, as
arguments, it's not common to pass the contents of globally defined
function names in CL, so the case of passing one is pessimized
slightly in order to make it clear that (f x) is passing a local name
[you don't have to look to be sure if the binding list is on a
previous screen. you always know x means "some local x" and that the
user would use #'x to denote a global function by this name.
BOTH languages are doing Statistics and Politics, though, not science.
That's not bad--it's what's called for; but it is not fair to say that
we have made a "political outcome" and Scheme has made a "scientific
outcome". A maxim I've made up for myself on this is the following:
"There are no political answers, only political questions." (Something
I just this moment thought of: It follows from strong typing that this
must be true, right? Both arms of the IF have to have the same return
type.) Both languages are probably doing right by their user
base. Each one is aesthetic within the context of what it is trying to
promote. Each one is political in that it has an agenda of a
programming style that it thinks is useful. Loosely, and I'm
exaggerating slightly for visual effect, so please don't be a stickler
here: Scheme: tolerate, but don't prefer, non-functions. Lisp:
tolerate, but don't prefer, functions. But what really burns me is
the oft-made claim by the Scheme community that their statistical
trade-off makes so much sense that it can be referred to without
adverbial qualification as "aesthetic" as if there were no other kind
of aesthetic worth mentioning.
I don't think Scheme is more aesthetic than Lisp, but I always send people
who want "aesthetics" toward the Scheme community because I think that
Scheme is a magnate for people who think that the word "aesthetic" as an
unqualified term and because I just tire of talking to people with that
kind of intolerant attitude. I suppose that makes me intolerant.
One never get anything for free--the cost of being around tolerant folks
is to be intolerant. Hmm.
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <379F6940.85FF6E66@iname.com>
Kent M Pitman wrote:
> I will continue to defend FUNCALL as a non-wart. I think it's the
> other way around. At the very minimuym, you should understand that
Sure ((lambda (x) x) 1) is a wart in the CL context (unless maybe if say "search
in operator space" as I did before,
but then, one should at least be able to specify anonymous macros as well. But
still, why can I remove FUNCALL
for that but not for bindings?).
One expression. `Prettier' and ugly at the same time.
But I assume the reason is compatibility (a noble goal, at least for CL ;->) and
not fancy.
Some might say even when making it better you make it worse. Oh, well..
Fernando Mato Mira <········@iname.com> writes:
> Kent M Pitman wrote:
>
> > I will continue to defend FUNCALL as a non-wart. I think it's the
> > other way around. At the very minimuym, you should understand that
>
> Sure ((lambda (x) x) 1) is a wart in the CL context
I don't know why. First, CL is about tolerance, so multiple paradigms
have a place because there are multiple kinds of people. Second, this
expression is a very old tradition, and I see no wart in tradition any
more than I would see in a finely crafted 19th century table. Third,
I don't see anything conceptually inconsistent about this. I was taught
that the car of a form is for the name of a function, and (lambda (x) x)
is one of the ways to name the identity function. Just as for Joe you
can say "Joe" or "that guy standing over there"; in this case you can
say IDENTITY or (LAMBDA (X) X). I read #'(LAMBDA (X) X) as meaning
"the function whose name is (lambda (x) x)" and I read
(LAMBDA (X) X) as "the macro expression that expands to the function
whose name is (LAMBDA (X) X)". I don't find it troubling to have both.
Nor inelegant.
No more "inelegant" than it is to live in a society that has two or ten
major religions. I would find it "inelegant" to live in a society that
forced everyone to pray to one religion just because that was
administratively simpler for some bureaucrat who could just as easily
ignore the religions that don't affect him personally and leave them to
be used by those who do desire them.
> (unless maybe if
> say "search in operator space" as I did before,
I did not understand this.
> but then, one should at least be able to specify anonymous macros as
> well.
I don't have any philosophical objection to this, though I've only used
them about half a dozen times in my entire career. For that frequency
of use, doing
(macrolet ((do-it () ...))
(do-it))
is adequately anonymous for me. I'm not sure why this relates to the
elegance of the other issues though--this seems orthogonal to me, but
maybe you can tie it in.
> But still, why can I remove FUNCALL for that but not for
> bindings?).
I did not understand this either.
> One expression. `Prettier' and ugly at the same time.
Nor this.
> But I assume the reason is compatibility (a noble goal, at least for
> CL ;->) and not fancy.
Nothing that I could discern in the above is a design decision made
for compatibility reasons, other than "compatibility with the desires
of the user community", which is not the classical meaning of
compatibility. I don't think the decision to have FUNCALL or FUNCTION
or two namespaces is motivated by backward compatibility. There are
reasons of presentational clarity that call for the use of these
separations. There are pragmatic reasons. And there are even some
efficiency arguments for the distinction. I would design the language
with this if there was no compabitility. That's what I've been trying
to say. There are different underlying sensibilities at work here. I
do not find the absence of FUNCALL aesthetic at all. I do not find it
simpler.
> Some might say even when making it better you make it worse. Oh, well..
Some might and do say this. I am not asserting they don't. I am saying
there are multiple sentiments and that my believing its aesthetic must
mean others think it aesthetic. But I do think others should not refer
to it as unconditionally unaesthetic. I think they should understand that
their belief that something is either aesthetic or unaesthetic is a personal
choice not necessarily uniquely determined and not necessarily shared
with [some or all] others.
I am for TOLERANCE of multiple sentiments. I am for allowing people to
like what they like without being hassled about it. I am really tired of
having people focus on what is NOT something they like; CL provides multiple
ways of doing things, and it's possible for people to focus on the things
they do find aesthetic. I am AGAINST giving people a hard time for
liking different things than others like, as long as those people don't
try to tell the others they should change, or that their view is inferior.
It's not been a good day for me. I'm sorry if this makes me sound a bit
stressed here. But I still wanted to make these comments. I apologize
in advance for the tone.
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <37A0218A.CDBBA458@iname.com>
Kent M Pitman wrote:
> Fernando Mato Mira <········@iname.com> writes:
>
> > Kent M Pitman wrote:
> >
> > > I will continue to defend FUNCALL as a non-wart. I think it's the
> > > other way around. At the very minimuym, you should understand that
> >
> > Sure ((lambda (x) x) 1) is a wart in the CL context
>
> I don't see anything conceptually inconsistent about this. I was taught
> that the car of a form is for the name of a function, and (lambda (x) x)
> is one of the ways to name the identity function. Just as for Joe you
> > (unless maybe if
> > say "search in operator space" as I did before,
>
> I did not understand this.
What you just said.
> > But still, why can I remove FUNCALL for that but not for
> > bindings?).
>
> I did not understand this either.
It's OK to do:
(funcall (lambda (x) x) 1) --> ((lambda (x) x) 1)
but not
(flet ((f --> (flet ((f
(funcall f)) (f))
>
> > One expression. `Prettier' and ugly at the same time.
See above.
> > But I assume the reason is compatibility (a noble goal, at least for
> > CL ;->) and not fancy.
[FUNCALL defense]
I was talking about funcall ellision for compatibility with Scheme, not about
having FUNCALL for CL backward compatibility.
> It's not been a good day for me. I'm sorry if this makes me sound a bit
> stressed here. But I still wanted to make these comments. I apologize
> in advance for the tone.
I think it's worse to irritate/waste people's time by not expressing oneself
more clearly
(what's the emoticon for "reflective" or "self-referent"?
[No need to reply for any potential `does not apply here', I'm guilty enough of
that] ;->)
Kent M Pitman wrote:
>> > I will continue to defend FUNCALL as a non-wart. I think it's the
>> > other way around. ...
>Fernando Mato Mira <········@iname.com> writes:
>> Sure ((lambda (x) x) 1) is a wart in the CL context
We had the very same discussion in our AutoLISP group recently as well
in my private AutoLISP stdlib mailinglist. the point is that i refused
to use a functional argument in first place and rather used APPLY (we
have no FUNCALL in AutoLISP, but APPLY is almost the same)
http://xarch.tu-graz.ac.at/autocad/stdlib/archive/ "Re: Sorting times"
and "sorting"
my point was "bad style" and "unreadability", where "bad style" was just
the hammer for the only true argument "unreadability". people are not
used to read functions this way. but both do work and can be used.
the contra argument was "performance". some function calls were faster
implicitly in first place than by using (APPLY #'fun (list arg)),
probably because of the added LIST call. and only on certain systems.
knowing my compiler internals I know that (APPLY (FUNCTION ... can be by
far better optimized than ((lambda ...) ...), so the performance
argument was only true on certain older interpreted AutoLISPs.
The next contra APPLY argument (by clever Vladimir Nesterowsky) was that
the ultimative way for a functional argument to our SORT is by not
quoting the FUNARG. passing by value not by name!
(SORT lst (lambda (a b) (< (car a) (car b)))
; btw: we have no :key arg for sort,
; even not a sort, and we have no optional args
benchmarks showed that this was really the fastest possible way to
implement a sort in AutoLISP. amazing, not?
thanksfully I could counter with the arguments uncontrollable
side-effects at function call and LISP incompatibility, but this left a
bad taste.
side-effects should be avoided anyway in sort funargs, and
incompatibility to any other system far away in time critical functions
is not a strong argument. esp. not in a library where "performance"
should be more important than the vague point "readability".
Kent was very correct in defending the usage of "inelegant". It happens
to be used by myself with newbies where I just don't want to explain it
in gory technical details or as here in political issues:
"never pass a function by value, pass it by name (or closure as in CL)".
our FUNCTION so far doesn't establish a closure but should do so in the
nearer future, though saying it publicly this would frighten users to
hell. "closure" or "lexical" are exactly the buzzwords nobody wants to
hear in AutoLISP as "AI" in LISP cycles.
the only other arguments can be "consistency" and "readability" in this
very special case.
Kent M Pitman wrote:
>I don't know why. First, CL is about tolerance, so multiple paradigms
>have a place because there are multiple kinds of people. Second, this
>expression is a very old tradition, and I see no wart in tradition any
>more than I would see in a finely crafted 19th century table. Third,
>I don't see anything conceptually inconsistent about this. I was taught
>that the car of a form is for the name of a function, and (lambda (x) x)
>is one of the ways to name the identity function. Just as for Joe you
>can say "Joe" or "that guy standing over there"; in this case you can
>say IDENTITY or (LAMBDA (X) X). I read #'(LAMBDA (X) X) as meaning
>"the function whose name is (lambda (x) x)" and I read
>(LAMBDA (X) X) as "the macro expression that expands to the function
>whose name is (LAMBDA (X) X)". I don't find it troubling to have both.
>Nor inelegant.
>
>No more "inelegant" than it is to live in a society that has two or ten
>major religions. I would find it "inelegant" to live in a society that
>forced everyone to pray to one religion just because that was
>administratively simpler for some bureaucrat who could just as easily
>ignore the religions that don't affect him personally and leave them to
>be used by those who do desire them.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Kent M Pitman <······@world.std.com> writes:
> This is a simple trade-off. Scheme assumes you will be passing so
> many functions that you will have at least an equi-likely chance of
> wanting to call a variable named F as a globally defined function
> named F, and so it assumes you want to optimize this case. Most CL
> programmers I know would gag if functional args were passed around
> with enough frequency to justify optimizing this case. Likewise, as
> arguments, it's not common to pass the contents of globally defined
> function names in CL, so the case of passing one is pessimized
> slightly in order to make it clear that (f x) is passing a local name
Do you intend to mean that CL programmers use less HOF (higher order
functions) techniques than Schemers? What about all Lispers fighting
together for the case of LAMBDA against the evil C etc. crowd? :-)
Or rather that more is defined at top-level, without too deep nesting,
for reasons you exposed another time, mostly being able to dynamically
overwrite functions etc. individually?
Do you intend to mean that the style in CL is like in C where you
don't pass much function pointers around, mostly primitive integers
and constructed structs, except for the obvious sort()
parameterization? Or like in OO, where you mostly manipulate
structs/records/objects/subjects as well? (E.g. few Smalltalkers seem
to pass block closures around, the usual exception being the sorter
for a collection).
> outcome". A maxim I've made up for myself on this is the following:
> "There are no political answers, only political questions." (Something
> I just this moment thought of: It follows from strong typing that this
> must be true, right? Both arms of the IF have to have the same return
> type.)
Or the return type is the union of the two types
for the languages that allow this.
Regards,
Jorg Hohle
Telekom Research Center -- SW-Reliability
* Joerg-Cyril Hoehle
| Do you intend to mean that CL programmers use less HOF (higher order
| functions) techniques than Schemers? What about all Lispers fighting
| together for the case of LAMBDA against the evil C etc. crowd? :-)
I'd say that Schemers use anonymous functions and higher-order functions
because that's the only way their language really supports. Lispers use
these techniques when they are pragmatically superior to the large number
of good alternatives. likewise, Schemers use recursion whether it's the
best solution or not, because that's what they have been taught is the
only way. Lispers use recursion when that is clearer than iteration, but
at least they are aware of the cost if the function needs a value stack.
| Do you intend to mean that the style in CL is like in C where you don't
| pass much function pointers around, mostly primitive integers and
| constructed structs, except for the obvious sort() parameterization?
have you read anything from Kent that indicates such nonsense, or are you
just another scheming Schemer out to prove that Scheme is superior, when
anyone who has seen an inferiority complex at work knows what's going on?
in Common Lisp, we pass functions around all the time, but not usually
_anonymous_ functions, and we don't use closures when we have structures
and classes, and we don't generally call the value of function-returning
functions right away because _more_ elegant means to do the same is
available in CLOS.
| Or like in OO, where you mostly manipulate
| structs/records/objects/subjects as well?
why do you have this very peculiar need to reduce Common Lisp to one
paradigm? have you understood exactly nothing of what Kent Pitman is
writing about all the time? Common Lisp is about allowing different
cultures to co-exist, and lets us all borrow from the cultures we want.
Scheme is not like that at all. one reason I don't like Scheme is how
Schemers don't like people who aren't exactly like them.
bottom line is: Common Lisp lets smart, well-educated people think and
then do whatever they think is best in any given case. Scheme lets
people do whatever smart, well-educated people once thought were best for
all cases.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
>
> * Joerg-Cyril Hoehle
> | Do you intend to mean that CL programmers use less HOF (higher order
> | functions) techniques than Schemers? What about all Lispers fighting
> | together for the case of LAMBDA against the evil C etc. crowd? :-)
>
> I'd say that Schemers use anonymous functions and higher-order functions
> because that's the only way their language really supports. Lispers use
> these techniques when they are pragmatically superior to the large number
> of good alternatives.
Very well said.
> likewise, Schemers use recursion whether it's the
> best solution or not, because that's what they have been taught is the
> only way.
Right. Scheme did not start out this way. Historically, Sussman and
Steele meant it to offer choices. But because choice A (loop-style
iteration rather than recursion) was so prevalent, they didn't waste
any teaching time talking about that as an option, and focused only on
choice B (recursion) until people forgot that the original point of the
thing was to increase the set of people's choices.
On 30 Jul 1999 08:38:29 +0000, Erik Naggum <····@naggum.no> wrote:
>* Joerg-Cyril Hoehle
>| Do you intend to mean that CL programmers use less HOF (higher order
>| functions) techniques than Schemers? What about all Lispers fighting
>| together for the case of LAMBDA against the evil C etc. crowd? :-)
>
> I'd say that Schemers use anonymous functions and higher-order functions
> because that's the only way their language really supports. Lispers use
> these techniques when they are pragmatically superior to the large number
> of good alternatives. likewise, Schemers use recursion whether it's the
> best solution or not, because that's what they have been taught is the
> only way. Lispers use recursion when that is clearer than iteration, but
> at least they are aware of the cost if the function needs a value stack.
>
>| Do you intend to mean that the style in CL is like in C where you don't
>| pass much function pointers around, mostly primitive integers and
>| constructed structs, except for the obvious sort() parameterization?
>
> have you read anything from Kent that indicates such nonsense, or are you
> just another scheming Schemer out to prove that Scheme is superior, when
> anyone who has seen an inferiority complex at work knows what's going on?
Are you just a vulgar CLer that read anti-CL sentiment into questions
whether such sentiment was intended or not?
I didn't take the question to be a "slam" as much as a question of
style.
> in Common Lisp, we pass functions around all the time, but not usually
> _anonymous_ functions, and we don't use closures when we have structures
> and classes, and we don't generally call the value of function-returning
> functions right away because _more_ elegant means to do the same is
> available in CLOS.
Fair enough.
>| Or like in OO, where you mostly manipulate
>| structs/records/objects/subjects as well?
>
> why do you have this very peculiar need to reduce Common Lisp to one
> paradigm? have you understood exactly nothing of what Kent Pitman is
> writing about all the time? Common Lisp is about allowing different
> cultures to co-exist, and lets us all borrow from the cultures we want.
> Scheme is not like that at all. one reason I don't like Scheme is how
> Schemers don't like people who aren't exactly like them.
When he has asked about several possible paradigms, and how CL might
fit with them, how, precisely does this represent an implication that
CL must forcibly be "reduced" to use one paradigm?
>bottom line is: Common Lisp lets smart, well-educated people think and
>then do whatever they think is best in any given case. Scheme lets
>people do whatever smart, well-educated people once thought were best for
>all cases.
I think you're seeing a conspiracy of "Evil Schemers" against CL where
there isn't one.
--
Rules of the Evil Overlord #6. "I will not gloat over my enemies'
predicament before killing them."
········@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>
* Christopher Browne
| Are you just a vulgar CLer that read anti-CL sentiment into questions
| whether such sentiment was intended or not?
well, I recognize _your_ intent.
| When he has asked about several possible paradigms, and how CL might fit
| with them, how, precisely does this represent an implication that CL must
| forcibly be "reduced" to use one paradigm?
because the questions asked did not indicate that the requestor
understood that multiple paradigms could be supported by one language.
| I think you're seeing a conspiracy of "Evil Schemers" against CL where
| there isn't one.
I can beat that: I _know_ you see evil intentions that aren't there.
I also think you're stupid who can't see more than one way to read my
anti-Scheme articles and go on to fault me for your own poor vision.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
On 09 Aug 1999 14:25:12 +0000, Erik Naggum <····@naggum.no> wrote:
>* Christopher Browne
>| Are you just a vulgar CLer that read anti-CL sentiment into questions
>| whether such sentiment was intended or not?
>
> well, I recognize _your_ intent.
[Snip]
I've read several posts by Erik in which he treats questions as assaults
on his favorite language. He may believe that this is some form of
advocacy. Take it with a grain of salt. He's done it to me too.
OTOH, he does seem to be quite strong technically, and sometimes he will
be of great help.
--
Kenneth P. Turvey <·······@SprocketShop.com>
----------------- http://www.tranquility.net/~kturvey
We all enter this world in the same way: naked; screaming; soaked in
blood. But if you live your life right, that kind of thing doesn't
have to stop there. -- Dana Gould
On Mon, 9 Aug 1999 11:36:39 -0500, Kenneth P. Turvey
<·······@pug1.sprocketshop.com> wrote:
>On 09 Aug 1999 14:25:12 +0000, Erik Naggum <····@naggum.no> wrote:
>>* Christopher Browne
>>| Are you just a vulgar CLer that read anti-CL sentiment into questions
>>| whether such sentiment was intended or not?
>>
>> well, I recognize _your_ intent.
>[Snip]
>
>I've read several posts by Erik in which he treats questions as assaults
>on his favorite language. He may believe that this is some form of
>advocacy. Take it with a grain of salt. He's done it to me too.
Apparently the (decidedly intended) pun got missed... (What does
"Common" translate to in Latin?)
I certainly do take it with a grain of salt.
>OTOH, he does seem to be quite strong technically, and sometimes he
>will be of great help.
Agreed.
--
Be careful when a loop exits to the same place from side and bottom.
········@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
Erik Naggum wrote: [1999-08-10 08:11 +0000]
[...]
> an ornithologist [...] suggested it should be called "Garden Lisp"
> [...] but he was British, so he had an excuse to
> think in such terms to begin with. I think I like "Garden Lisp", anyway.
[...]
I just read the article Kent Pitman mentioned in a recent posting, and
there I found a use of `garden':
What has been done is to associate information with the symbol,
name, describing any special treatment that is to be given its
form before and after the application of the definition--but the
function which is applied is just a garden variety function with
no special information information attached to it.
(`Special Forms in Lisp,' Kent Pitman,
http://world.std.com/~pitman/Papers/Special-Forms.html)
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
* Christopher Browne
| Apparently the (decidedly intended) pun got missed... (What does
| "Common" translate to in Latin?)
I know too much Latin to understand that pun, but here's a better
interpretation: an ornithologist I sat beside on a flight which was much
too long for his company wondered what I was doing, and once illuminated,
he suggested it should be called "Garden Lisp" to avoid the implication
you seem to be grasping for, but he was British, so he had an excuse to
think in such terms to begin with. I think I like "Garden Lisp", anyway.
| I certainly do take it with a grain of salt.
you know, such a line sounds a lot better without your teeth clenched.
#:Erik
--
(defun pringles (chips)
(loop (pop chips)))
Erik Naggum wrote:
> I think I like "Garden Lisp", anyway.
So do I. I also like the english strangeitude that is the phrase 'common or
garden.'
Best Regards,
:-) will
Kent M Pitman <······@world.std.com> writes:
Ahem!
> Human-derived attempts to make unambiguous languages have gone
> nowhere. English, which is full of contextual nuance and blunt
> construction, has won over the regularities of Latin and Greek and the
> pseudo-regularities of languages like Spanish and German partly, at
> least, because people don't have patience with aesthetics when they
> stand in the way of practicality. They want to ELECT practicality
> when it suits their need, but they don't want to be REQUIRED
> practicality.
At a certain point in history Latin had won over Greek and a plethora
of other languages in the Mediterranean basin. "La Divina Commedia"
is from the 13th century :) German had won over Latin in the mid 800
hundred for scientific communication and "War and Peace" begins with
"En fin..." :)
I am sure I could gang up with Vassil Nikolov and come up with a
(defpackage "LATIN" (:use))
That would allow you to program in Latin :)
Languages are strange. History has strange ways to define what's
better. Sects and cults can keep on going proclaiming the faith.
People whoi write on C.L.L. are such.
And for the Italians over here (it's an inside joke sorry) :) ).....
I propose a name for an Italian Common Lisp user group:
Rifondazione Comulispa!
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> Ahem!
>
> > Human-derived attempts to make unambiguous languages have gone
> > nowhere. English, which is full of contextual nuance and blunt
> > construction, has won over the regularities of Latin and Greek and the
> > pseudo-regularities of languages like Spanish and German partly, at
> > least, because people don't have patience with aesthetics when they
> > stand in the way of practicality. They want to ELECT practicality
> > when it suits their need, but they don't want to be REQUIRED
> > practicality.
>
> At a certain point in history Latin had won over Greek and a plethora
> of other languages in the Mediterranean basin. "La Divina Commedia"
> is from the 13th century :) German had won over Latin in the mid 800
> hundred for scientific communication and "War and Peace" begins with
> "En fin..." :)
I got some private mail about this, too. There are political and other
factors involved here.
But even if you take any one of those languages and ignore the
inter-language fighting, you can see that strong/regular language
features fall in favor of weaker ones. That is, people's natural
inclination is to make lots of variations for pragmatic reasons,
especially ones that favor pronunciation, not to try to distill the
language to a microscopic and easy-to-teach core. Often the
pronunciation accomodations make the language harder to learn, not
easier, but presumably the reason people do it is that they'd rather
have a language they can use easily than one they can learn easily,
because they are more equipped to learn it in spite of irregularity
than they are to speak it in spite of regularity.
Kent M Pitman <······@world.std.com> writes:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > At a certain point in history Latin had won over Greek and a plethora
> > of other languages in the Mediterranean basin. "La Divina Commedia"
> > is from the 13th century :) German had won over Latin in the mid 800
> > hundred for scientific communication and "War and Peace" begins with
> > "En fin..." :)
>
> I got some private mail about this, too. There are political and other
> factors involved here.
>
> But even if you take any one of those languages and ignore the
> inter-language fighting, you can see that strong/regular language
> features fall in favor of weaker ones. That is, people's natural
> inclination is to make lots of variations for pragmatic reasons,
> especially ones that favor pronunciation, not to try to distill the
> language to a microscopic and easy-to-teach core. Often the
> pronunciation accomodations make the language harder to learn, not
> easier, but presumably the reason people do it is that they'd rather
> have a language they can use easily than one they can learn easily,
> because they are more equipped to learn it in spite of irregularity
> than they are to speak it in spite of regularity.
You are stating the obvious: there is *no* relationship whatsoever
between written and spoken English. :)
Spelling context in Italian or German are nonsense :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Kent M Pitman <······@world.std.com> writes:
> But even if you take any one of those languages and ignore the
> inter-language fighting, you can see that strong/regular language
> features fall in favor of weaker ones.
I'm not a professional linguist but I strongly doubt you can
generalize that. When you take the history of a language family over a
few thousand years you can see whole shifts from analytical to
inflected and back again. It's true that for Indo-European languages
the shift has been to losing the 8 original cases (although Old
Lithuanian even picked up some additional ones from the Finnish-Ugrian
group) in favor of more analytical features but in general natural
languages are also ecologies in which tradeoffs are made. The
conjugation of verbs in French is very complex which has led to the
disappearance of a lot of tenses in normal speech and a plethora of
tenses that are nowadays regarded as literary or affected. On the
other hand, Turkish has even more tenses but its verbs are very
regular.
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
Lieven Marchand <···@bewoner.dma.be> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > But even if you take any one of those languages and ignore the
> > inter-language fighting, you can see that strong/regular language
> > features fall in favor of weaker ones.
>
> I'm not a professional linguist but I strongly doubt you can
> generalize that. When you take the history of a language family over a
> few thousand years you can see whole shifts from analytical to
> inflected and back again. It's true that for Indo-European languages
> the shift has been to losing the 8 original cases (although Old
> Lithuanian even picked up some additional ones from the Finnish-Ugrian
> group) in favor of more analytical features but in general natural
> languages are also ecologies in which tradeoffs are made. The
> conjugation of verbs in French is very complex which has led to the
> disappearance of a lot of tenses in normal speech and a plethora of
> tenses that are nowadays regarded as literary or affected. On the
> other hand, Turkish has even more tenses but its verbs are very
> regular.
You're reading way more into this than I intended. My point was rather
more simple: That if there was a need, in order to accomodate a mass
user base, for a language to have few cases, there would have been
wars fought over this issue itself. Or that people would have
rebelled against the grammar teachers and insisted on simplicity. But
they haven't. They have endured twists and turns that defy explanation.
They have opted for languages that are messy. They have added special-cases
to otherwise regular rules. You can see it between languages and inside
them. Regularity is not what wins out in the marketplace of speakers.
If it were, we'd all be speaking Esperanto or some such simple thing with
a well-designed small core, easy to explain rules, etc. But that's not
what people want or need.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
> Regularity is not what wins out in the marketplace of speakers.
> If it were, we'd all be speaking Esperanto or some such simple
> thing with a well-designed small core, easy to explain rules,
> etc. But that's not what people want or need.
On the contrary, there is a natural trend toward regular rules in a
language. It's only the very common ones which can survive as
irregular.
Thomas L. Rochestro
http://www.esperanto.net
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
·····@my-deja.com writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
>
> > Regularity is not what wins out in the marketplace of speakers.
> > If it were, we'd all be speaking Esperanto or some such simple
> > thing with a well-designed small core, easy to explain rules,
> > etc. But that's not what people want or need.
>
> On the contrary, there is a natural trend toward regular rules in a
> language. It's only the very common ones which can survive as
> irregular.
You perhaps missed the (unwritten) stress in my remark, which others did
as well. I have gotten huge numbers of replies which take on the form
of contradicting me, yet say the same thing as I was trying to express,
or very close to it.
The critical commonality between what you and I wrote is that languages
tolerate the irregularities. Scheme is, to me, almost an
obsessive-compulsive attitude toward regularity, that says that regularity
and aesthetic must dominate over all over things. My feeling is that
regularity and aesthetic are conceptual tools, just as an "exception to a
rule" is a conceptual tool. The striving for regularity is, as you say,
a common trend in languages. However, there is no central regularity
which is the uniquely determined goal of those many observable trends,
and so languages do not converge. They just roll out certain irregularities
to make room for new ones, or they have local convergences of regularity
that get attacked later by incompatible regularities elsewhere in the
language. What makes the languages work in spite of this is the fact that
people have adequate brain structure to accomodate irregularity without
fretting over it. The notion, invented by computer people, that a text
means nothing if not 100% correct, is a sad one. People have worked for
centuries to make language a lot more fault tolerant than that, and one
reason people think computer people are too nitpicky is that they make such
a big deal out of some inconsequential little detail. Computer people will
have made more progress when they have compilers that, like people, say
"oh, that's not really syntactically right, but I can see where you are
going with that and I'll do it anyway". And when they have languages that
support multiple ways of expression to allow emphasis or redundancy or other
intangibles that the mathy among us insist are "not informationally necessary".
My remarks which started this were over questions of whether having several
ways to say IF (IF, COND, WHEN, UNLESS, etc.) is really bad, or whether
it's empowering... or whether having multiple ways to specify anonymous
functions--i.e., both (lambda (x) x) and #'(lambda (x) x)--is bad. I think
it's good to be inclusive and to have lots of ways to do things because
people have lots of ways of thinking about things, and because it doesn't
trouble people to have lots of ways of thinking. I think it's bad when
people say that languages have to do things exactly one way that is pure
and pristine and unsubject to change or question or competition. Because
I think that's just religious dogma, not based on any scientific proof
that's ever been done that demonstrates the inability of languages to
survive in the face of less pristine arrangement. Indeed, most computer
languages that survive are very complicated. That may not be criterial
to their survival, and don't misquote me to say it is, but what it tells
you is that being irregular in places, or preferring practical to the
aesthetic, is not as "obviously fatal" to a language as some might have
one believe. That's not to say I don't strive for regularity in languages;
I do. I just don't think the language has failed when I don't achieve
the nirvana of The One and Only One Pure Aesthetic and Regular Language.
Regularity is a value, not an end.
Kent M Pitman wrote: [1999-07-30 23:08 +0000]
[...]
> What makes the languages work in spite of this is the fact that
> people have adequate brain structure to accomodate irregularity without
> fretting over it.
[...]
I have this strong intuition that in fact such irregularities are very
important to allow faster and more reliable language perception and
generation, by providing just the right amount of redundancy.
Note how many irregularities occur in those elements of a language
that are used most often (e.g. `to be' in English), i.e. that are under
greatest stress in terms of having to be optimised both for speed
and safety, so to say.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Vassil Nikolov <········@poboxes.com> writes:
> I have this strong intuition that in fact such irregularities are very
> important to allow faster and more reliable language perception and
> generation, by providing just the right amount of redundancy.
> Note how many irregularities occur in those elements of a language
> that are used most often (e.g. `to be' in English), i.e. that are under
> greatest stress in terms of having to be optimised both for speed
> and safety, so to say.
I think irregularities also support a market economy involving
distributed and divided control structure separately fussing with
different pieces in different ways without central
locking/synchronization. If any two people who might affect a
language had to talk to one another to get the write-lock on the
language, it inhibits their ability to do their focused work. But if
they do their work separately, they may optimize different local
values. By violating regularity occasionally, a language says "there
is diminished burden on the users to add, extend, or change things"
and that invites lower overhead participation. Also, if problems might
result from lack of control, tools evolve to cope; in a language where
the definition of the language is "it is perfectly coordinated and
regular", you build fragile tools that depend for their correctness
on everyone being completely neurotic about regularity, too, or else
the system doesn't compose.
Just my opinion.
Kent M Pitman wrote:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > Ahem!
> >
> > > Human-derived attempts to make unambiguous languages have gone
> > > nowhere. English, which is full of contextual nuance and blunt
> > > construction, has won over the regularities of Latin and Greek and the
> > > pseudo-regularities of languages like Spanish and German partly, at
> > > least, because people don't have patience with aesthetics when they
> > > stand in the way of practicality. They want to ELECT practicality
> > > when it suits their need, but they don't want to be REQUIRED
> > > practicality.
It's also more fun.
> > At a certain point in history Latin had won over Greek and a plethora
> > of other languages in the Mediterranean basin.
Is this not something to do with the fact that this was the language of choice
of an imperial bureaucracy?
> That is, people's natural inclination is to make lots of variations for
> pragmatic reasons, especially ones that favor pronunciation, not to try to
> distill the language to a microscopic and easy-to-teach core.
My understanding of the development of english is that it was developed in
england and was a kind of trading language to enable way of a disperate series
of comunities to communicate with each other. This was because, being on the
edge of the European continent, these dark northern islands were regularly
invaded by people such as the Romans (speaking Latin), the Saxons and Angles
(speaking German dialects), the Vikings (speaking Scandanavian dialect), the
Normans (speaking early French) and so on.
A large set of complex tenses and gramatical construct were then trashed to a
minimal form to enable people to talk to each other about such burning topics
as how much they hated their neighbours in the next village, how much for the
fish? and who was having an adulterous with who else.
Then there is the strong influence of the church in England, all the early
writing carried out in Latin; and the choices made by the ruling elite at the
time. It wasn't until the late middle-ages that the offical language (French)
was rejected and english became acceptable.
It should also be noted that until recently (that is the life time of my
grandparents) that normal working people in the UK took great delight in
talking in all sorts of really strange accents and dialects so as to make
themselve totally incomprehensible to anybody other than people born within a
radius of about 40 miles and that english was still a trading and official
('imperial') language of the elite.
Infact there are parts of the UK in which people take delight in speaking
languages that have nothing to do with english at all. Look at cymraeg or
gaelic.
> Often the pronunciation accomodations make the language harder to learn, not
> easier, but presumably the reason people do it is that they'd rather have a
> language they can use easily than one they can learn easily, because they
> are more equipped to learn it in spite of irregularity than they are to
> speak it in spite of regularity.
English in not at all regular, particulary when it comes to spelling. It is
very flexible particularly when spoken. Any language with a very simple tense
and verb structure, and the ability to steal anything neat that comes along
(look at excellent words like verandah, gazibo or concervatory, any language
that needs three words for a shed in your back garden for sitting in must have
something for it). This results in a very very large vocabulary that you can
just string together easily.
But I do not want to denigrade any other languages. I feel deeply ashamed that
my education has let me down to such an extent that I only know a smattering
of words in other languages. I wish could read and speak German (the native
tongue of my beloved Wittegenstein, Gunter Grass ....) or Italian (Primo Levi,
Dante ...) or French (Zola, Flobert ...), or Russian (Landau, Dostoevsky ...)
or all the languages in the world. If only I could live for a thousand years
so that I could learn all the languages that there are :-(
But what has this got to do with computer languages? I'm not entirely sure as
I think I lost the plot a while ago.
OK, languages should be large, irregular, easily extendible, fun, full of
dialects and nuances and all those other good thing that as an english speaker
I like about english. Just could you do something about the spelling?
:-) will
ps: The next question is of course, do Americans speak english? Or just
American ;-)
William Deakin <·····@pindar.com> writes:
> > Often the pronunciation accomodations make the language harder to learn, not
> > easier, but presumably the reason people do it is that they'd rather have a
> > language they can use easily than one they can learn easily, because they
> > are more equipped to learn it in spite of irregularity than they are to
> > speak it in spite of regularity.
>
> English in not at all regular, particulary when it comes to spelling.
Although presented in words that syntactically make it appear to refute
my point (which you probably misunderstood, and which I've discussed
with you in private e-mail and won't repeat here), this statement of yours
exactly makes my point. If regular spelling is something people needed,
English would have been fixed a long time ago. My key point was this:
Regularity is not what makes or breaks a language. People cope with
irregularity routinely. What makes or breaks a language, besides politics
(which inevitably gets involved in all these discussions but which is not
a refutation to anything I've said), is whether it's "easy to use". And
what makes languages easy to use is NOT simplicity.
I've perhaps confused everyone because they THINK I meant that "lots
of cases", as in Latin or Greek or still somewhat in German, is "less
simple". I don't think that. I think that in principle, that's more
simple. Cases in a language are a small set of rules that, if applied
consistently, would allow you lots of leveraged information. In a
heavily cased language, you'd expect word order was EXTREMELY flexible
because the cases could uncover the role of all the parts. But in
fact, modern languages that uses cases have eroded the regularity of
the cases to the point where the information you can recover from them
is less what you'd ideally be able to recover. German cases are not regular
enough that you can just look at "der" and immediately infer the use of
that word. Ambiguity abounds and the partial information being contributed
by parts of sentences from gender and case are not "regular". You'd think
if this was a problem, the language would be drifting toward increased
case marking, since that would be toward a simpler grammar. But in fact,
it drifts even within that one language, toward the practical in ways that
defy a global notion of "regularity". Yes, the politics of the church
might have pulled things together internally for a while for High German,
but the local communities immediately toss that valuable "centralization
and regularity" to the wind in face of what works better for their need
of the moment. The same story repeats itself in other languages. English
is different all over, and what makes it powerful as a language is that
it copes with speakers doing very different things. There needs be no
central caucus on the issue of what gender to make each noun. Nouns get
added and people can figure out how to use them. Special cases? Yes, but
they are very localized in effect, and that supports a decentralized
community. Regular rules have to be issued from a place that is the authority
in that regularity, and that's just too hard.
In the end, even the politics of decentralization would not be enough reason
for us to cope with irregularity if our brains couldn't handle it though.
But the fact is that our brains can handle a zillion special cases in parallel
and fast enough that we can still speak all of the languages that take years
to learn but that are quite efficient when we speak them. Comparatively,
just about all computer languages take almost no time to learn, and if there
is a problem--it's not the choice of words, but the choice of how to think
about the thing you want to have words for. So, bottom line, all the fussing
people do over little tiny things like "how many namespaces are there" or
"should there really be two primitives IF and COND, or is one enough?" is just
so much silliness. No one cares. The language will compose fine if you
have three ways to say various things. Messy as it is in a few little places,
the mess in CL is not out of control enough to keep large systems from being
built, and that's what matters. The kind of mess that's there is the kind
of mess that confuses people who decide they want to be confused, not the
kind of mess that must inherently confuse.
Kent M Pitman wrote:
> William Deakin <·····@pindar.com> writes:
> > English in not at all regular, particulary when it comes to spelling.
>
> Although presented in words that syntactically make it appear to refute
> my point (which you probably misunderstood, and which I've discussed
> with you in private e-mail and won't repeat here), this statement of yours
> exactly makes my point.
I look forward to reading the private email on Monday since I can't get at
it from where I am now :-) I'm sorry about the syntax but I did agree with
your point about spelling. As in fact, I agree with what you are saying.
I happen to like english as a way of thinking, rather as I like CL as a
programming way of thinking. I was just trying to say somethings about why
english is like it is because of many factors and also because it is very
pragmatic in its aproach to purity and simplicity. And I thought a little
digression into the history of the development of english might help. Or
not.
As I admit later in my posting, I got a bit carried away and lost the plot.
I will try and think up something to say more sensible. But it wasn't my
intention to get up your nose (except the bit about americans :-)).
soz.
:-) will
Kent M Pitman <······@world.std.com> wrote:
+---------------
| And what makes languages easy to use is NOT simplicity.
+---------------
Did I miss it, or has no-one yet mentioned Steele in this thread...?
http://cm.bell-labs.com/cm/cs/who/wadler/steele-oopsla98.ps
"Growing a Language"
[Why large languages are better than small languages, and
languages that can grow from small to large are the best.]
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Kent M Pitman <······@world.std.com> writes:
> William Deakin <·····@pindar.com> writes: [...]
>
> Although presented in words that syntactically make it appear to refute
> my point (which you probably misunderstood, and which I've discussed
> with you in private e-mail and won't repeat here),
William asked me about this e-mail and I went to look for it and
couldn't find it. I had several other interchanges with people
over private e-mail on this and guess I got confused. Sorry 'bout
that. (All the @'s and .com's here look alike, I guess.)
William Deakin <·····@pindar.com> writes:
> But what has this got to do with computer languages? I'm not entirely
> sure as I think I lost the plot a while ago.
>
> OK, languages should be large, irregular, easily extendible, fun,
> full of dialects and nuances and all those other good thing that as
> an english speaker I like about english. Just could you do something
> about the spelling?
That's why Common Lisp is so great: CL is all of the above, and you
don't have to worry about spelling, since your CL environment takes
care of that (via completion, lookup, and all the other goodies)... ;)
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
William Deakin <·····@pindar.com> writes:
> > Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> >
> > > At a certain point in history Latin had won over Greek and a plethora
> > > of other languages in the Mediterranean basin.
>
> Is this not something to do with the fact that this was the language
> of choice of an imperial bureaucracy?
This are your words, not mine :)
> ps: The next question is of course, do Americans speak english? Or just
> American ;-)
Do Mexican speak Spanish? Or just American?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti wrote:
> William Deakin <·····@pindar.com> writes:
>
> > > Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> > >
> > > > At a certain point in history Latin had won over Greek and a plethora
> > > > of other languages in the Mediterranean basin.
> >
> > Is this not something to do with the fact that this was the language
> > of choice of an imperial bureaucracy?
>
> This are your words, not mine :)
>
I am really sorry. I got the editing wrong. The 'At a certain point in history
Latin...' was from the posting by Kent Pitman and not you :-| I hope this
misattribution has not cause offence.
> > ps: The next question is of course, do Americans speak english? Or just
> > American ;-)
>
> Do Mexican speak Spanish? Or just American?
Or in fact do they simply speak Mexican? ;-)
RESPECT!
:-) will
William Deakin <·····@pindar.com> writes:
> A large set of complex tenses and gramatical construct were then trashed to a
> minimal form to enable people to talk to each other about such burning topics
> as how much they hated their neighbours in the next village, how much for the
> fish? and who was having an adulterous with who else.
I think this is the same thing I read somewhere -- English is
basically a frozen-out creole (between, I guess, some Germanic
language, come Celtic language, Norse (is that Germanic?) and perhaps
little bits of Latin), and that explains a lot of the way it is.
Perhaps CL is a kind of frozen-out creole in some sense too.
--tim
Tim Bradshaw wrote:
> William Deakin <·····@pindar.com> writes:
>
> > A large set of complex tenses and gramatical construct were then trashed to a
> > minimal form to enable people to talk to each other about such burning topics
> > as how much they hated their neighbours in the next village, how much for the
> > fish? and who was having an adulterous with who else.
>
> I think this is the same thing I read somewhere -- English is basically a
> frozen-out creole (between, I guess, some Germanic language, come Celtic
> language, Norse (is that Germanic?) and perhaps
> little bits of Latin), and that explains a lot of the way it is.
There was an interesting series on the development and history of english on BBC 2
about 10 years ago, or so. I watched it and my folks bought the book of the series.
Fascinating stuff. I also alway liked the fact that JRR Tolkein was a translator of
Beowulf, of which I have a battered copy of at home. I also believe there is a
yearly prize at Brum Uni name in his honour for the best Old English translation
(won by a mate of mine when I was there). But enough already! This is c.l.l.
:-)~ will
From: John M. Miller
Subject: Re: cautios question (about languages)
Date:
Message-ID: <7nsdkg$gmn$1@nnrp1.deja.com>
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
<snip>
> I will continue to defend FUNCALL as a non-wart. I think it's the
> other way around. At the very minimuym, you should understand that
> there is an equally strong aesthetic theory by which (F X) to call a
> variable F is UNaesthetic. The Scheme community, in keeping with
> their one-namespace view, also often have a one-aesthetic chauvinism
> as well. The issue that divides us is less the technical decision for
> "a single namespace" and more the political decision for "single
> decisions". My favorite quote in this area is from an unknown source
> which I would happily and gratefully identify if I could: "There are
> two kinds of people in the world: people who think there are two kinds
> of people in the world and people who do not."
<BIG snip>
The only other place I ever saw this was in the "Illuminati Trilogy" by
Robert Shea and Robert Anton Wilson. I believe those books were
published in the early 70's. BTW, those books are full of good quotes,
but this is the only one I clearly remember. This also may be my
favorite all-time quote (right behind Linus Torvalds "Linux - so fast it
can do infinite loops in .2 seconds"), it is my daily mantra for dealing
with all the difficult people in the world...
Cheers,
John
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Marco Antoniotti wrote: [1999-07-29 10:25 +0200]
[...]
> "La Divina Commedia"
> is from the 13th century :)
Trecento is the 14th century. ;nitpicking
[...]
> I am sure I could gang up with Vassil Nikolov and come up with a
>
> (defpackage "LATIN" (:use))
>
> That would allow you to program in Latin :)
LISPVSCOMMVNIS---sure, count me in...
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Fernando Mato Mira <········@iname.com> wrote:
>The package system is constantly under attack, and while some Schemes have
>nice module systems (eg: MzScheme), there's no standard.
"nice" is different. for me the MzScheme/MrEd/DrScheme module system
(the "units") is one of the most powerful ones, but "horrible" to read
and understand.
CL packages and defsystem are IMHO much simplier and of comparable
functionality.
Just this example for the module (better "library") COMPAT.SS:
Files: compat.ss, compatu.ss, compatr.ss, compats.ss
Requires: functios.ss
Opened form requires: functiou.ss
Syntactic forms only: compatm.ss
Signature: mzlib:compat^
Unit: ············@, imports mzlib:function^
whenever see such weird characters as ·@" or "^" I get totally
frightened. please not another perl!
--
Reini
Reini Urban wrote:
> whenever see such weird characters as ·@" or "^" I get totally frightened.
> please not another perl!
Ha Ha, I will take over the world by loading viruses triggered by the � symbol!
RESPECT :-) will
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <37A17B64.FB50D628@iname.com>
Reini Urban wrote:
> whenever see such weird characters as ·@" or "^" I get totally
> frightened.
I don't like that either.
[Insert recurrent ILOG Talk reminder here]
Friedrich Dominicus <···················@inka.de> wrote in message
······················@inka.de...
> I have try to find out myself and checked some Scheme and Lisp pages.
> But althought I'm sure this question was asked a hundred times before, I
> wasn't able to figure it out.
>
> It's about Scheme and Common Lisp. Does it make sense to learn one or
> the other, or both, or just one of it?
>
> My background: I'm an Eiffel-Programmer, and I think I know quite a bit
> about C/C++ and I refuse to do programming a line of C++.
I think you'll find a really powerfull language with CL.
If you like Eiffel you should look at this URL :
http://www.muc.de/~hoelzl/tools/dbc/dbc-intro.html
It contains a CL package for Design by Contract programming.
It shows how easy it is to integrate new ideas in CL.
Hope you'll enjoy it.
You should also have a look at the OO features of Common Lisp.
The Meta Object Protocol is really worthwhile.
http://www.elwood.com/alu/mop/contents.html
Marc Battyani
In article <··················································@lp.airnews.net>, "Marc Battyani" <·············@csi.com> wrote:
> You should also have a look at the OO features of Common Lisp.
> The Meta Object Protocol is really worthwhile.
> http://www.elwood.com/alu/mop/contents.html
Hey, give him a break. He is just learning this stuff. ;-)
Rainer Joswig <······@lavielle.com> wrote in message
····························@194.163.195.67...
> In article
<··················································@lp.airnews.net>, "Marc
Battyani" <·············@csi.com> wrote:
>
> > You should also have a look at the OO features of Common Lisp.
> > The Meta Object Protocol is really worthwhile.
> > http://www.elwood.com/alu/mop/contents.html
>
> Hey, give him a break. He is just learning this stuff. ;-)
OK, OK. Though I wonder if he is still there. His post prompted such a huge
post flood on so many subjects that he could think that comp.lang.lisp is an
chaotic system...
From: Fernando Mato Mira
Subject: Re: cautios question (about languages)
Date:
Message-ID: <37A4BF89.1AD8ED38@iname.com>
Marc Battyani wrote:
> OK, OK. Though I wonder if he is still there. His post prompted such a huge
> post flood on so many subjects that he could think that comp.lang.lisp is an
> chaotic system...
Oh. It is not? ;-)