Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

A strange question...

26 views
Skip to first unread message

Vlastimil Adamovsky

unread,
Oct 20, 2002, 12:30:29 PM10/20/02
to
I know, somebody will roll his eye balls......but I have to ask...

Has somebody written Smalltalk in Lisp or Lisp in Smalltalk?
Is it doable?
Is it a good idea?

I am only asking :)

Vlastik


Pascal Costanza

unread,
Oct 20, 2002, 1:06:34 PM10/20/02
to

I think this is an excellent idea! I am currently implementing a Java
Virtual Machine in Common Lisp - as far as I know, Smalltalk has a
standardized "bytecode" format as well, so implementing a Smalltalk
"virtual machine" should be equally feasible.

Here are some of the advantages I see:

+ The Common Lisp code for a Virtual Machine is very compact and quite
straightforward, so relatively easy to understand.

+ You don't need to implement this as an interpreter, but you can do
"just-in-time" compilation into Lisp code via macros. So you get a fair
amount of efficiency nearly for free. (Note that most Common Lisp
implementations compile the Lisp code into native machine code,
including even the Lisp code you generate at runtime.)

+ Since Common Lisp is an ANSI standard, such a Virtual Machine is
easily portable to various platforms.

+ You can translate the classes of the source language (Java, Smalltalk,
whatever) into CLOS (Common Lisp Object System, part of the ANSI
standard). CLOS is extremely flexible, so you can easily modify CLOS in
order to correctly handle the object model of the respective source
language.

+ Furthermore, CLOS allows you to adapt the classes and objects of the
source language afterwards, even at runtime. (In other words, you get
"dynamic aspect-orientation" for free. ;)

+ In the long run, Common Lisp could turn out as a very useful
environment for integrating various languages. So you could, for
example, mix Java and Smalltalk (and Python, Ruby, ML, Haskell, and so
on, and so on... ;).

(So essentially, Common Lisp could play the role of the so-called
"Common Language Runtime" component of Microsoft .NET. The difference is
that the CLR isn't nearly as flexible as Common Lisp. So instead of
waiting for some future version of the CLR to get the flexibility it
actually needs to really keep the promise of .NET, we could start right
now with Common Lisp!)


Pascal

--
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend

rush

unread,
Oct 20, 2002, 1:32:15 PM10/20/02
to

"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in message
news:3db2da7f$1...@nntp2.nac.net...

> I know, somebody will roll his eye balls......but I have to ask...
>
> Has somebody written Smalltalk in Lisp or Lisp in Smalltalk?
> Is it doable?

well since there is a Prolog implentation written in Smalltalk, and since
there is LISP implementation written in Prolog, yes, there could be LISP
implementation written in Smalltalk :))) ,

> Is it a good idea?

but, I would assume that the above implementation would not be champion in
efficiency :)

Possible usages of LISP in Smalltalk:
-writting a mixed app where a some specific reasoning is written in LISP
(perhaps in allready tested libraries)
cons:
-efficiency might not be so good
-may be possible to achieve the same result with C level interface to native
LISP

Possible usages of Smalltalk in LISP
-simple implementation
-good for students practice
cons:
-might not be very efficient implementation


rush


Vassili Bykov

unread,
Oct 20, 2002, 1:41:45 PM10/20/02
to
"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in news:3db2da7f$1_1
@nntp2.nac.net:

Jun, included with VW, includes Lisp and Prolog implementation. There was
another another Lisp and Scheme in Smalltalk implementation, I think by Ian
Piumarta. Any "X in Y" is doable, whether it is a good idea depends mostly
on your definition of "a good idea". :)


--
Vassili Bykov [|] vassili "at" parcplace "dot" com
VisualWorks Engineering
[:s | s, s printString] value: '[:s | s, s printString] value: '

Andreas Wacknitz

unread,
Oct 20, 2002, 2:39:48 PM10/20/02
to
Vlastimil Adamovsky wrote:

Take a look at Smalltalk/X. AFAIK it has Prolog, Lisp, and Java.

Andreas

Vlastimil Adamovsky

unread,
Oct 20, 2002, 4:34:25 PM10/20/02
to
It's amazing! Is your work an "open source"?

Vlastik

"Pascal Costanza" <cost...@web.de> wrote in message
news:aounqp$kug$1...@newsreader2.netcologne.de...

Thomas F. Burdick

unread,
Oct 20, 2002, 4:59:05 PM10/20/02
to
"Vlastimil Adamovsky" <am...@ambrasoft.com> writes:

> I know, somebody will roll his eye balls......but I have to ask...
>
> Has somebody written Smalltalk in Lisp or Lisp in Smalltalk?
> Is it doable?

It's doable, but a non-toy Lisp or Smalltalk is a lot of work. I
think Lisp-in-Smalltalk is a much worse idea than the reverse, because
CLOS is multiple-inheritance and has multiple-dispatch generic
functions; to do this in ST, you'd be fighting against the native
object system. Mapping ST object system semantics onto CLOS would be
very straightforward, though. Once you had the system to handle ST
code, and your primitive classes and methods defined, you'd be nowhere
near done. Both Smalltalk and Lisp have huge standard libraries, and
they're fairly different, so they wouldn't work very well together.
And once you had the standard library written, you'd need development
tools if you expected anyone to use your new ST-in-Lisp.

Or maybe you meant a straightforward implementation of ST or Lisp,
with the other being nothing more than an implementation language. In
that case, Lisp is a wonderful language to write compilers in, and I'd
imagine VMs would be nice in it, too. One nicety that's particularly
useful in compilers is being able to use dynamic binding when you want
it. I think I would be less likely to want to use ST as a compiler
language, but I'm a Lisper first, Smalltalker second, so that's not
surprising. Both would be head-and-shoulders above any other
implementation languages that come to mind.

> Is it a good idea?

I think it's not. If you're trying to get the two to live in the same
image, I don't think it's worth the massive effort it would cost. If
you're trying to use one as the implementation language for the other,
I think it would be a disservice to the users. A nice feature of most
Lisp and Smalltalk systems is that they're Lisp/ST (almost) all the
way down. This means that the vendor can carefully expose some of the
implementation internals to the user; the user can sometimes take
advantage of the implementation; if it's a source-available system,
the user can modify some of the internals, or even just look at how
they work. As an implementor, I'd rather implement ST in Lisp than in
Smalltalk, but as a ST user, I'd be very annoyed with such a system.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Thaddeus L Olczyk

unread,
Oct 20, 2002, 6:18:10 PM10/20/02
to

A Lisp interpreter can be implemented very trivial in ST in about 30
lines.


Smalltalk at: 'Def:Fun:' put:
[ :name :aBlockClosure |
Smalltalk at: name put: aBlockClosure. ]

Smalltalk at: 'Eval: aList' put:
[ |tmp|
tmp:=aList collect: [ :e | (e isArray) ifTrue: [ Eval: e]].
^( tmp at: 1 ) values: ( tmp subArray: 2 ).
]

My ST is weak so you have to refine some of the calls ( eg isArray ,
which may not be define ), but you get the idea.

The sad thing is that your hear all this talk from the rabid ST
proponents about how "ST is pure", but this shows how trivial
it is to emulate a nonOO language. Some purity.

Pascal Costanza

unread,
Oct 20, 2002, 7:33:36 PM10/20/02
to
Vlastimil Adamovsky wrote:
> It's amazing! Is your work an "open source"?
>
> Vlastik

Thanks. ;) I haven't made up my mind yet. I'd like to make the source
code available for free for research purposes (for example, for
prototyping Java language extensions), but I wouldn't mind earning some
money either. ;) It's a matter of how much interest there is in such work.

However, it's too soon yet to speculate on this. I think I will have the
first examples up and running within the next one or two months, but
they will be just pure single-threaded Java, without "native" code.
Support for multi-threading and support for the standard Java API will
be a vast amount of work. Let's see...

Vlastimil Adamovsky

unread,
Oct 20, 2002, 7:41:40 PM10/20/02
to
"Pascal Costanza" <cost...@web.de> wrote in message
news:aovegg$788$1...@newsreader2.netcologne.de...

> Vlastimil Adamovsky wrote:
> > It's amazing! Is your work an "open source"?
> >
> > Vlastik
>
> Thanks. ;) I haven't made up my mind yet. I'd like to make the source
> code available for free for research purposes (for example, for
> prototyping Java language extensions), but I wouldn't mind earning some
> money either. ;) It's a matter of how much interest there is in such work.

If you want to be a software developer, forget about money.....:))
Software guys are usually underpaid na matter how much they make.

>
> However, it's too soon yet to speculate on this. I think I will have the
> first examples up and running within the next one or two months, but
> they will be just pure single-threaded Java, without "native" code.
> Support for multi-threading and support for the standard Java API will
> be a vast amount of work. Let's see...

My interest is exlusively academic. I don't intend to make money on software
:)
To much work for little money ...... If you will do whatever you do because
you like what you do, the money will come by itself (sooner or later, very
often later :)


Vlastik

Marc Spitzer

unread,
Oct 20, 2002, 9:02:03 PM10/20/02
to
"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in
news:3db33...@nntp2.nac.net:

> "Pascal Costanza" <cost...@web.de> wrote in message
> news:aovegg$788$1...@newsreader2.netcologne.de...
>> Vlastimil Adamovsky wrote:
>> > It's amazing! Is your work an "open source"?
>> >
>> > Vlastik
>>
>> Thanks. ;) I haven't made up my mind yet. I'd like to make the source
>> code available for free for research purposes (for example, for
>> prototyping Java language extensions), but I wouldn't mind earning
>> some money either. ;) It's a matter of how much interest there is in
>> such work.
>
> If you want to be a software developer, forget about money.....:))
> Software guys are usually underpaid na matter how much they make.

And who's fault is that? Start a small company to provide software
services. Learn to speak MBA/Bussiness speak so you can tell them how
and why this will save them money to pay you for product. Then get payed
what you are worth. If a company has a $5,000,000.00/year problem and
you can fix it in 3 months then charge them for 1/2 a years loss. This
makes sence to the busnessman, pay money problem go away cool. Remember
you are not charging for your time/labor but for the solution you
provide, this is called value and they pay for value.


marc

Boris Popov

unread,
Oct 20, 2002, 9:16:16 PM10/20/02
to
"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in message
news:3db33...@nntp2.nac.net...

> "Pascal Costanza" <cost...@web.de> wrote in message
> news:aovegg$788$1...@newsreader2.netcologne.de...
> > Vlastimil Adamovsky wrote:
> > > It's amazing! Is your work an "open source"?
> > >
> > > Vlastik
> >
> > Thanks. ;) I haven't made up my mind yet. I'd like to make the source
> > code available for free for research purposes (for example, for
> > prototyping Java language extensions), but I wouldn't mind earning some
> > money either. ;) It's a matter of how much interest there is in such
work.
>
> If you want to be a software developer, forget about money.....:))
> Software guys are usually underpaid na matter how much they make.

That's quite a statement. Even though there's never too much money, saying
that most software developers are underpaid "no matter how much they make"
makes me want to ask why exactly do you think so?

>
> >
> > However, it's too soon yet to speculate on this. I think I will have the
> > first examples up and running within the next one or two months, but
> > they will be just pure single-threaded Java, without "native" code.
> > Support for multi-threading and support for the standard Java API will
> > be a vast amount of work. Let's see...
>
> My interest is exlusively academic. I don't intend to make money on
software
> :)

If you consider yourself to be a software developer and you're not planning
to make money off your work, then how are you going to make a living?

> To much work for little money ......

Are you looking for easy money in this business? I was under the impression
that the times when it was an everyday occurence are long gone, aren't they?

> If you will do whatever you do because
> you like what you do, the money will come by itself (sooner or later, very
> often later :)

Money never comes by itself. You have to work hard for it, unless your uncle
dies and leaves you with some extra cash :)

-Boris


Vlastimil Adamovsky

unread,
Oct 20, 2002, 9:20:50 PM10/20/02
to

"Marc Spitzer" <mspi...@optonline.net> wrote in message
news:Xns92ADD71547AA4ms...@167.206.3.3...

> "Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in
> news:3db33...@nntp2.nac.net:
>
> > "Pascal Costanza" <cost...@web.de> wrote in message
> > news:aovegg$788$1...@newsreader2.netcologne.de...
> >> Vlastimil Adamovsky wrote:
> >> > It's amazing! Is your work an "open source"?
> >> >
> >> > Vlastik
> >>
> >> Thanks. ;) I haven't made up my mind yet. I'd like to make the source
> >> code available for free for research purposes (for example, for
> >> prototyping Java language extensions), but I wouldn't mind earning
> >> some money either. ;) It's a matter of how much interest there is in
> >> such work.
> >
> > If you want to be a software developer, forget about money.....:))
> > Software guys are usually underpaid na matter how much they make.
>
> And who's fault is that? Start a small company to provide software
> services.

Good idea :)

> Learn to speak MBA/Bussiness speak so you can tell them how
> and why this will save them money to pay you for product.

I know a company having a $X,000,000/year problem, so they fired all
expensive persons and hired twice as many people for half salary per person.
The problem is still there, though managable twice as less .
Go and try to talk to that company. I tried. I tried to talk money.....
It seems they are afraid of savings :))

>Then get payed what you are worth.

You never get paid what you are worth. You will get what you will negotiate
out.

> If a company has a $5,000,000.00/year problem and
> you can fix it in 3 months then charge them for 1/2 a years loss.

Cool..:) A manager making $150,000 or $200,000 per year will take a check
or write out a $2,500,000 check..:) Have you heard of envy? (not ENVY:)

>This
> makes sence to the busnessman, pay money problem go away cool. Remember
> you are not charging for your time/labor but for the solution you
> provide, this is called value and they pay for value.

OK, back to reality :)

Vlastik


Steven L. Collins

unread,
Oct 20, 2002, 10:26:36 PM10/20/02
to

"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in message
news:3db2da7f$1...@nntp2.nac.net...

IIRC the CD included with the book "Squeak" ISBN 0-13-028028-3 by Mark
Guzdial includes a simple Lisp Interpreter as an extra. It's not mentioned
in the book just something included as an example. This may give you some
idea's

Steven


Vlastimil Adamovsky

unread,
Oct 20, 2002, 10:33:03 PM10/20/02
to
"Boris Popov" <nospa...@shaw.ca> wrote in message
news:AzIs9.544379$v53.22...@news3.calgary.shaw.ca...

> "Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in message
> news:3db33...@nntp2.nac.net...
> > "Pascal Costanza" <cost...@web.de> wrote in message
> > news:aovegg$788$1...@newsreader2.netcologne.de...
> > > Vlastimil Adamovsky wrote:
> > > > It's amazing! Is your work an "open source"?
> > > >
> > > > Vlastik
> > >
> > > Thanks. ;) I haven't made up my mind yet. I'd like to make the source
> > > code available for free for research purposes (for example, for
> > > prototyping Java language extensions), but I wouldn't mind earning
some
> > > money either. ;) It's a matter of how much interest there is in such
> work.
> >
> > If you want to be a software developer, forget about money.....:))
> > Software guys are usually underpaid na matter how much they make.
>
> That's quite a statement. Even though there's never too much money, saying
> that most software developers are underpaid "no matter how much they make"
> makes me want to ask why exactly do you think so?

I made a bad joke...I will stick to the Smalltalk subject from now on.

>
> >
> > >
> > > However, it's too soon yet to speculate on this. I think I will have
the
> > > first examples up and running within the next one or two months, but
> > > they will be just pure single-threaded Java, without "native" code.
> > > Support for multi-threading and support for the standard Java API will
> > > be a vast amount of work. Let's see...
> >
> > My interest is exlusively academic. I don't intend to make money on
> software
> > :)
>
> If you consider yourself to be a software developer and you're not
planning
> to make money off your work, then how are you going to make a living?

I wrote: "I don't intend to make money on software"....it was not expressed
very
well. I wanted to write "shrink wraped software"..... I am making money on
consulting
and webhosting services. But economy is changing blindingly fast, so when
you will
read this, I may be sitting and writing a next Smalltalk killer application
that will be sold "off the shell"......
Besides, NJ Lottery has $5,000,000 Jack pot now..maybe more.

OK, jokes aside.... I do software for a joy, not for money. It is not my
fault I get paid.
I am fighting quite hard to get Smalltalk where it belongs, I would like to
see it back on
Wall Street, in pharmaceutical industry...... Each time when I am being
contacted to do some
work I am being told, that I have to help them to move "away" from
Smalltalk......
And there is no reason for it..... Simply to fix some code, fix design and
that's it.....
But customer is always right :)

>
> > To much work for little money ......
>
> Are you looking for easy money in this business? I was under the
impression
> that the times when it was an everyday occurence are long gone, aren't
they?
>
> > If you will do whatever you do because
> > you like what you do, the money will come by itself (sooner or later,
very
> > often later :)
>
> Money never comes by itself. You have to work hard for it, unless your
uncle
> dies and leaves you with some extra cash :)

Don't work hard, use Smalltalk ! :)

>
> -Boris
>
>


news.verizon.net

unread,
Oct 20, 2002, 10:57:26 PM10/20/02
to
GNU Smalltalk has a Lisp implantation included in one of distribution's
directories.

"Pascal Costanza" <cost...@web.de> wrote in message

news:aounqp$kug$1...@newsreader2.netcologne.de...

Vlastimil Adamovsky

unread,
Oct 20, 2002, 11:02:02 PM10/20/02
to
I actually like more the idea of Smalltalk having been written in Lisp

Vlastik

"news.verizon.net" <vze4...@verizon.net> wrote in message
news:q2Ks9.17554$Pk1....@nwrddc02.gnilink.net...

Vlastimil Adamovsky

unread,
Oct 20, 2002, 11:03:07 PM10/20/02
to
Thanks, I will try to get the book...

Vlastik

"Steven L. Collins" <ste...@ix.netcom.com> wrote in message
news:aovocb$ilc$1...@nntp9.atl.mindspring.net...

Marc Spitzer

unread,
Oct 20, 2002, 11:25:30 PM10/20/02
to
"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in
news:3db356cd$1...@nntp2.nac.net:

No, it looks like they are afraid of people who can make them look bad.
Many managers are afraid of people who can say "no it will not work and
here is why" or "that did not work the last 2 times you tried it."

>>Then get payed what you are worth.
>
> You never get paid what you are worth. You will get what you will
> negotiate out.
>

That is what you are worth, as a professional. It is the agreed apon
value of your services.



>> If a company has a $5,000,000.00/year problem and
>> you can fix it in 3 months then charge them for 1/2 a years loss.
>
> Cool..:) A manager making $150,000 or $200,000 per year will take a
> check or write out a $2,500,000 check..:) Have you heard of envy?
> (not ENVY:)
>

A manager who can point to a yearly savins of 5,000,000/year for a one
time payment has just made big points with his bosses and should be fast
tracked for promotion. Also the manager must have some faith in you as a
vendor and you need to build it with them.

>>This
>> makes sence to the busnessman, pay money problem go away cool.
>> Remember you are not charging for your time/labor but for the
>> solution you provide, this is called value and they pay for value.
>
> OK, back to reality :)

I never left. Managers who spend money want to be able to point to
success in reducing operating costs. They want to do this to show it to
their bosses so they do not get fired/not promoted. They have money in
their budget and they will be asked why they did not use it.

marc

>
> Vlastik
>
>

Boris Popov

unread,
Oct 20, 2002, 11:30:43 PM10/20/02
to
"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in message
news:3db367b9$1...@nntp2.nac.net...
>
> [...bunch of stuff skipped...]
>

You have a very strange sense of humor :)

-Boris


Marc Spitzer

unread,
Oct 20, 2002, 11:36:35 PM10/20/02
to
"Boris Popov" <nospa...@shaw.ca> wrote in
news:AzIs9.544379$v53.22...@news3.calgary.shaw.ca:

> Money never comes by itself. You have to work hard for it, unless your
> uncle dies and leaves you with some extra cash :)

Well you can always try to get it the old fashioned way, marry it.

marc

>
> -Boris
>
>
>

Boris Popov

unread,
Oct 20, 2002, 11:47:19 PM10/20/02
to
"Marc Spitzer" <mspi...@optonline.net> wrote in message
news:Xns92ADF147EB561ms...@167.206.3.3...

Good point!

-Boris


Frank A. Adrian

unread,
Oct 21, 2002, 1:34:26 AM10/21/02
to
Vlastimil Adamovsky wrote:

> Has somebody written Smalltalk in Lisp or Lisp in Smalltalk?

When I worked at ParcPlace Systems, I made a few Lisp objects to start doing
just that.

> Is it doable?
Yes. The main issue is not so much in making the objects function properly,
but in making the two systems interoperate. Where you put the points of
integration can influence each side. For example, do you make the Lisp
type package a subclass of SystemDictionary? Conversely, do you allow
instances of SystemDictionary to be used in place of a package? How does
one call Smalltalk methods from Lisp code? How about vice-versa (Since
every message send in Smalltalk must have a target, what target do you use
to get to a Lisp function)?

> Is it a good idea?

As good as any. It's a lot of work and will probably pay off about as much
as the amount of thought and work that is put into it.

faa


Ronald Schröder

unread,
Oct 21, 2002, 9:52:16 AM10/21/02
to
"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in message news:<3db2da7f$1...@nntp2.nac.net>...

Look at http://www.chartexplorer.com/dolphin/SWScheme/ for a Scheme
implemented in Dolphin Smalltalk

Have fun,

Ronald

Vlastimil Adamovsky

unread,
Oct 21, 2002, 1:02:19 PM10/21/02
to
Actually, you are right.

Vlastik


Vlastimil Adamovsky

unread,
Oct 21, 2002, 1:05:15 PM10/21/02
to
It was my last attempt to by funny... Now I am taking it serously and
am working on some interesting suff...(VBA 6.3 SDK and Smalltalk MT will be
involved)...


Vlastik

"Boris Popov" <nospa...@shaw.ca> wrote in message

news:DxKs9.544610$v53.23...@news3.calgary.shaw.ca...

Marc Spitzer

unread,
Oct 21, 2002, 7:47:46 PM10/21/02
to
"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in news:3db43376$1_2
@nntp2.nac.net:

> Actually, you are right.

I was? How odd.

;)

marc

>
> Vlastik
>
>

Gary Owsiany

unread,
Oct 21, 2002, 9:00:19 PM10/21/02
to

"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in message
news:3db356cd$1...@nntp2.nac.net...
<snip>

> I know a company having a $X,000,000/year problem, so they fired all
> expensive persons and hired twice as many people for half salary per
person.
> The problem is still there, though managable twice as less .
> Go and try to talk to that company. I tried. I tried to talk money.....
> It seems they are afraid of savings :))
>
You need to understand how a corporate manager thinks. In my experience, he
is not thinking about efficiencies, rather he is thinking about empire
building. For example, which manager is more important:
1. He has 5 top programmers and a $1 million budget, or
2. He has 15 mediocre programmers and a $20 million budget.
They both produce the same amount of completed projects.

In the corporate world, head count and budget mean power so #2 is considered
more successful. Nobody is looking at the quality of the code being
produced, just at whether it "works" (I use the term lightly) and if it is
released "reasonably" on time. Therefore, the situation you described
repeats itself over and over again.

Gary


Vlastimil Adamovsky

unread,
Oct 21, 2002, 9:30:37 PM10/21/02
to

"Gary Owsiany" <gar...@swbell.net> wrote in message
news:Dq1t9.141$iB3.55...@newssvr12.news.prodigy.com...

That's exactly how it is....... I have seen it over and over..... And again,
it has influence
on whether Smalltalk will be widely accepted or not....

Vlastik


Marco Antoniotti

unread,
Oct 22, 2002, 9:23:54 AM10/22/02
to

"Gary Owsiany" <gar...@swbell.net> writes:

You forgot to add that, in a time of crisis, it is the smaller unit
that gets cut :}

Cheers

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

Joe Marshall

unread,
Oct 22, 2002, 9:53:51 AM10/22/02
to
"Gary Owsiany" <gar...@swbell.net> writes:

> You need to understand how a corporate manager thinks.

What? I'm not sure I understand your definition of `think'.

Wade Humeniuk

unread,
Oct 22, 2002, 10:13:47 AM10/22/02
to

"Gary Owsiany" <gar...@swbell.net> wrote in message
news:Dq1t9.141$iB3.55...@newssvr12.news.prodigy.com...
> You need to understand how a corporate manager thinks. In my experience, he
> is not thinking about efficiencies, rather he is thinking about empire
> building. For example, which manager is more important:
> 1. He has 5 top programmers and a $1 million budget, or
> 2. He has 15 mediocre programmers and a $20 million budget.
> They both produce the same amount of completed projects.
>
> In the corporate world, head count and budget mean power so #2 is considered
> more successful. Nobody is looking at the quality of the code being
> produced, just at whether it "works" (I use the term lightly) and if it is
> released "reasonably" on time. Therefore, the situation you described
> repeats itself over and over again.

It is hard to verify whether this is true. Even if companies act like this, the
important thing to them is that they are still profitable (and they are). There
are also factors mixed in of managing and directing projects, psychology,
leadership and probably many other little things. Also mediocre programmer
does not necessarily mean mediocre person.

I have certainly known software development/project managers, my wife is one,
and they basically admit that they do not know if someone is doing
a good job or not. They find the situation frustrating. A programmer
may meet or not meet a schedule, but
it says nothing about whether the schedule was accurate. They find
that there is so much bafflegab coming from the developers that they
cannot decide. So in some ways efficiency is replaced by the security
of inflated estimates in time and money. Since a software project lives
within a larger corporate structure, the other parts have to be somewhat
assured the the system will be there at a certain time. When I worked
in construction I found the same thing, inflated schedules, but pretty
predictable schedules.


--
Wade

Email: (format nil "~A@~A.~A" "whumeniu" "telus" "net")


Erik Naggum

unread,
Oct 22, 2002, 10:25:23 AM10/22/02
to
* Gary Owsiany

| You need to understand how a corporate manager thinks.

* Joe Marshall


| What? I'm not sure I understand your definition of `think'.

I think it is the "think" that people use for "feel" because they feel
that "feel" would mark them as inferior human beings.

Most people would rather die than think. In fact, they do.

I heard from a behaviorist the other day that new managerial theories are
first tested on animals.

Even my cat can see through simple reward schemes that work wonders on
people for many years and she does better at delayed gratification tests
than many children. I would undoubtedly tolerate such people better if
they had fur and purred and lived for less than 20 years.

--
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

Vlastimil Adamovsky

unread,
Oct 22, 2002, 12:14:09 PM10/22/02
to

"Marco Antoniotti" <mar...@cs.nyu.edu> wrote in message
news:y6cu1je...@octagon.valis.nyu.edu...

I never thought abou that :)) Now I understand why the crisis is worsening
:)))

Vlastik

Rich Demers

unread,
Oct 23, 2002, 5:03:03 PM10/23/02
to
"Vlastimil Adamovsky" <am...@ambrasoft.com> wrote in message news:<3db2da7f$1...@nntp2.nac.net>...
> I know, somebody will roll his eye balls......but I have to ask...
>
> Has somebody written Smalltalk in Lisp or Lisp in Smalltalk?
> Is it doable?
> Is it a good idea?
>
> I am only asking :)
>
> Vlastik

I think there is a more interesting inter-language question:

Are there any unique aspects/features/functions of the Lisp paradigm
that would be good/useful additions to Smalltalk? Heaven knows other
languages have borrowed heavily from Smalltalk (C++, Java,
Objective-C, Python, etc.).

I am a strong believer in borrowing whatever I find useful from other
languages. One of the beauties of Smalltalk is that it is so easy to
implement such "borrowings" with a Smalltalk syntax in the class
library - without touching the virtual machine.

Personally, I have been looking hard at APL (one of the most powerful
languages ever!) as a good source of such borrowings. Even though it
has a fundamentally different paradigm, there's no reason some of its
functions can't be adapted into Smalltalk (encode, decode, deal,
roll...) along with the reduction and scanning of arrays.

It's the same thing as in natural languges. The language that is best
able to borrow from other languages "wins" in the long run. If there
is such a thing as a global natural language today, it is English
because it is so flexible and so open to borrowing from other
languages - Latin, French, German, Native American, Japanese, etc.
This is the role I believe Smalltalk can take among programming
languages.

Christopher C. Stacy

unread,
Oct 23, 2002, 5:37:00 PM10/23/02
to
>>>>> On 23 Oct 2002 14:03:03 -0700, Rich Demers ("Rich") writes:

Rich> I am a strong believer in borrowing whatever I find useful from
Rich> other languages. One of the beauties of Smalltalk is that it
Rich> is so easy to implement such "borrowings" with a Smalltalk
Rich> syntax in the class library - without touching the virtual machine.

Going the other way: Lisp originally borrowed the message passing
syntax from Smalltalk. In Flavors, which was the object system
before CLOS, one would write things like (SEND WINDOW :DEEXPOSE).
However, we moved back to (DEEXPOSE WINDOW) with CLOS.

Rich> Personally, I have been looking hard at APL (one of the most powerful

Yeah, APL was the language I loved before I discovered Lisp!
Common Lisp has REDUCE; also check out the SERIES package by Dick Waters.

Rich> It's the same thing as in natural languges. The language that is best
Rich> able to borrow from other languages "wins" in the long run.

Lisp stole FORMAT from FORTRAN, along with many other facilities.

The thing about APL, though, is that a lot of its beauty is in the syntax.
Someone said, "APL is like a diamond, Lisp is like a ball of mud.",
the point being that Lisp is capable of retaining its Lispish beauty
while still absorbing other ideas, but APL's crystal lattice shatters
when you try to add things to it.

Rich Demers

unread,
Oct 24, 2002, 10:59:14 AM10/24/02
to
cst...@dtpq.com (Christopher C. Stacy) wrote in message news:<u8z0on...@dtpq.com>...

>
> The thing about APL, though, is that a lot of its beauty is in the syntax.
> Someone said, "APL is like a diamond, Lisp is like a ball of mud.",
> the point being that Lisp is capable of retaining its Lispish beauty
> while still absorbing other ideas, but APL's crystal lattice shatters
> when you try to add things to it.

Unfortunately, APL's syntactic beauty comes with too high a price - a
character set that virtually no one else can use. In any case, my
objective is not to copy APL into Smalltalk or to implement APL in
Smalltalk, it is to enrich Smalltalk with ideas from APL. I want to
selectively reuse APL ideas within Smalltalk's framework of objects
and messages, and through Smalltalk's normal syntax.

APL has been characterized as an Array Programming Language, as
opposed to an Object-Oriented programming language. This is supposed
to mean that these are incompatible paradigms, but that is obviously
not true.

Smalltalk operates as a programming language on a couple of levels.
At the "programming" level, it has the features one finds in most
programming languages for working with scalar data objects (numeric,
string, boolean, date, time, etc) and structured objects (arrays,
sets, bags, ordered collections, linked lists, etc.). And at the
"domain" level, it has features for working with programmer-defined
domain objects (Employee, Part, Account, etc). It's all objects, but
in most applications, the domain level is built on top of the
programming level. Numbers and strings and collections are used to
implement domain objects.

The same is true in APL, but there are no "objects," per se.
Programming level data and functions are language primitives, and
domain level entities are named uses of the programming entities.

As I see it, there are four challanges:
1. To enrich the Smalltalk scalar object classes with additional APL
functions, like deal, roll, encode, decode, etc.

2. To enrich the Smalltalk collection classes with APL-like vectors
and matrices - along with the APL functions and operators that work
with them.

3. To ensure that their elements can be any class of Smalltalk object
(not just scalar data objects), as is true for other Smalltalk
collection classes.

4. Performance! Can a Smalltalk implementation of these APL ideas be
efficient enough to be useful? But hey, you know the XP mantra: "Make
it work, Make it right. Make it FAST!"

What do you think? Is this worth pursuing?

Regards...Rich

Stephen J. Bevan

unread,
Oct 24, 2002, 12:16:08 PM10/24/02
to
richd...@msn.com (Rich Demers) writes:
> Unfortunately, APL's syntactic beauty comes with too high a price - a
> character set that virtually no one else can use.

Have you looked at J <http://www.jsoftware.com> or K <http://www.kx.com>
both of which use ASCII and have some interesting features of their own?

Christopher Browne

unread,
Oct 24, 2002, 4:53:02 PM10/24/02
to

They /are/ interesting, and do use ASCII.

I think it's probably still easy to argue that their "unique use of
ASCII characters" still leaves them fragile in much the same ways.
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://cbbrowne.com/info/oses.html
The average woman would rather have beauty than brains because the
average man can see better than he can think.

David Rush

unread,
Oct 25, 2002, 4:02:21 AM10/25/02
to
richd...@msn.com (Rich Demers) writes:
> I think there is a more interesting inter-language question:
>
> Are there any unique aspects/features/functions of the Lisp paradigm
> that would be good/useful additions to Smalltalk?

Is it possible to write the Y combinator using only Smalltalk block
closures yet? Sometimes you just want functions, you know.

david rush
A former Smalltalker
--
It's always tempting to impute
Unlikely virtues to the cute
-- P. J. O'Rourke

David Simmons

unread,
Oct 25, 2002, 4:32:16 AM10/25/02
to
"David Rush" <ku...@bellsouth.net> wrote in message
news:apatqc$mma$2...@pixie.nscp.aoltw.net...

> richd...@msn.com (Rich Demers) writes:
> > I think there is a more interesting inter-language question:
> >
> > Are there any unique aspects/features/functions of the Lisp paradigm
> > that would be good/useful additions to Smalltalk?
>
> Is it possible to write the Y combinator using only Smalltalk block
> closures yet? Sometimes you just want functions, you know.

Are you talking about something to the effect of:

fn := ["block#1"] + ["block#2"].

r := fn(expr, expr, ...)

Being equivalent to:

fn1 := ["block#1"].
fn2 := ["block#2"].

r1 := fn1(expr, expr, ...).
r2 := fn2(expr, expr, ...).

r := {r1, r2}.

??? Delegates ???

Note, the above example is from SmallScript.

-- Dave S. [www.smallscript.org]

David Rush

unread,
Oct 25, 2002, 4:45:20 AM10/25/02
to
richd...@msn.com (Rich Demers) writes:
> As I see it, there are four challanges:
> 1. To enrich the Smalltalk scalar object classes with additional APL
> functions, like deal, roll, encode, decode, etc.

minor.

> 2. To enrich the Smalltalk collection classes with APL-like vectors
> and matrices - along with the APL functions and operators that work
> with them.

Vector-like things already exist, no? Matrices are another issue, one
where there is likely to be as much complexity as the whole
collection-class hierarchy.

> 3. To ensure that their elements can be any class of Smalltalk object
> (not just scalar data objects), as is true for other Smalltalk
> collection classes.

And how fast do you want it to go?

> 4. Performance! Can a Smalltalk implementation of these APL ideas be
> efficient enough to be useful?

If you factor the class hierarchy enough, then I think so. Being able
to tweak the VM would surely be a plus (think of primitive matrix
multiply operations...).

> What do you think? Is this worth pursuing?

See the .sigmonster's contribution, really. I hate it when he
pre-empts me.

david rush
--
Do not ask how. Ask rather why. Once you know your reason,
your method will be obvious.
-- The book of Bears (zen scheme, ch 1 verse 22)

Alex Shinn

unread,
Oct 25, 2002, 5:37:03 AM10/25/02
to
>>>>> "David" == David Rush <ku...@bellsouth.net> writes:

David> richd...@msn.com (Rich Demers) writes:
>> I think there is a more interesting inter-language question:
>>
>> Are there any unique aspects/features/functions of the Lisp
>> paradigm that would be good/useful additions to Smalltalk?

David> Is it possible to write the Y combinator using only Smalltalk
David> block closures yet? Sometimes you just want functions, you
David> know.

y := [:gen| [:f| f value: f]
value: [:f| gen value: [:x| (f value: f) value: x]]].

Sample script that works with GNU Smalltalk below. Run with one arg,
the Fibonacci number you want to generate.

--
Alex

#Smalltalk == "start of -*- Smalltalk -*- comment
exec gst "$0" -aQ $@ # end of Smalltalk comment"!

Smalltalk at: #y put: 0!
Smalltalk at: #n put: 0!
Smalltalk at: #fgen put: 0!
Smalltalk at: #fib put: 0!

y := [:gen| [:f| f value: f]
value: [:f| gen value: [:x| (f value: f) value: x]]].

fgen := [:f| [:n| (n < 2) ifTrue: [1]
ifFalse: [((f value: (n - 1))
+ (f value: (n - 2)))]]].

fib := y value: fgen.

n := Smalltalk arguments isEmpty
ifTrue: [1]
ifFalse: [(Smalltalk arguments at: 1) asInteger].

(fib value: n) printNl !


Eugene Wallingford

unread,
Oct 25, 2002, 11:55:42 AM10/25/02
to
David Rush <ku...@bellsouth.net> wrote:

> Is it possible to write the Y combinator using only Smalltalk block
> closures yet? Sometimes you just want functions, you know.

Blocks-as-closures now exist as a modification to the Squeak
VM and will be a part of the standard release in an upcoming
version.

--
+-------------------------------------------------------------------------+
| Eugene Wallingford wall...@cs.uni.edu |
| University of Northern Iowa |
| Intelligent Systems Laboratory |
+-------------------------------------------------------------------------+

panu

unread,
Oct 25, 2002, 5:18:19 PM10/25/02
to
Rich Demers wrote:

> ... Are there any unique aspects/features/functions of the Lisp paradigm


> that would be good/useful additions to Smalltalk?

About a week ago there was a thread titled "Loneliness of Nil".
On hindsight it seems much of the controversy was caused by some
participants thinking about "nil as in Lisp" while others
were - simultaneously - thinking about "nil as in Smalltalk".

In Lisp nil is (more or less) equal to an "empty list".
In Smalltalk nil is best thought of as "undefined value",
since "OrderedCollection new" is already a good representation
of an empty list. And because a variable that was never given
a value, returns nil when you ask for that value.

This I think points to an interesting difference between
(more or less pure) functional languages like Lisp, and
Object Oriented languages like Smalltalk, in general.
Now it's over a decade since I worked with Lisp, so I'll
appreciate any counter arguments from the Lisp community,
to what follows...

In a functional language everything is computed by a function.
A program really is just a big function which depending on the
arguments returns the value of some sub-function. A function can
return a list of values, and that list can be empty, i.e. nil.

The semantics of an empty list can be interpreted as 'the answer
to your question is: There are none'. For instance if you called
a function that returns a person's middle initials, you might
receive an empty list / nil as the answer, meaning the person has
no middle initials in their name.

The alternative interpretation of "Your question doesn't make sense"
seems less natural, because if we adopt it, how could we represent
the other case ("there is none!")?

I may be wrong but it now seems to me that in pure Lisp there is
no such concept as 'undefined value'. There is only the nil, which
should be interpreted as "no values", rather than "unknown value".

In Smalltalk in contrast we have 'nil' to represent "unknown
information" but also 'Collection new' to represent "no values".
These are clearly two different things, with different semantics.

If I'm right (which sometimes happens), it would seem that OO-
languages have a distinct advantage over functional languages
here.

In Smalltalk it is easy to 'reflect' on a program since
we have 'nil' to signify that something is "missing from"
the OO model represented by the Smalltalk program. This
is used frequently in 'lazy initializers' which first use
reflection to realize that a variable has no value, and
if so create a default value for it.

Also, I can override #notUnderstood: so that any message
without a corresponding defined method returns 'nil' to signify
that the program has "no information" about how to interpret
the request. This means something like "This attribute is
undefined" or "Request not understood" - as opposed to:

"I understand the question and I'm able to tell you
the answer is: 'none'".

An OO program seems to be more capable of "knowing what it doesn't
know", than a functional program, which is simply what it is, a big
function with several components.

I may be wrong, but I guess my question boils down to:

1. "What is the equivalent of Smalltalk's #notUnderstood: in
functional languages?"

2. "How do you distinguish between 'missing information', and
known information that the 'answer is an empty list' ?"


-Panu Viljamaa
"A computer running Smalltalk seems more conscious"

Tom Lord

unread,
Oct 25, 2002, 6:15:05 PM10/25/02
to

I may be wrong, but I guess my question boils down to:

1. "What is the equivalent of Smalltalk's #notUnderstood: in
functional languages?"

It depends on the language. The closest thing in Scheme is an error;
the closest thing in many dialects is an exception.

In both cases, the idea is to shelter the "ordinary" flow of control
from this issue. In the case of exceptions, the idea is provide
programmers the option of recovering flow of control.

2. "How do you distinguish between 'missing
information', and known information that the 'answer
is an empty list' ?"


Mostly as above.


You have a weird way of looking at nil, in that you insist on reducing
it to an english noun-clause.

English is not particularly great at encoding data structures.

In programming, we define structures of a mathematical nature -- the
art being to define a structure that is a good model of the
application at hand. Simultaneously, we seek data structures that are
convenient to manipulate in a program.

If computer programming has contributed at all to the intellectual
development of humans, it is in the area of such modeling. We
programmers have found models that could not have been found if we
confined ourselves to "natural language". We are inventing new
natural language to talk about the new models. There is no
substitute for understanding computational math other than to
understand computational math.

Convenience of manipulation is an important consideration. Not too
long ago, I had a mini-epiphany while working with some Emacs lisp
code.

The epiphany was this: the "liberal" use of nil (as false, as end of
list, as a nil-returning argument to CAR and CDR) is damn convenient.
I made the decision to take advantage of `(car nil) => nil' and so
forth in this program. The result was that the code accomplished
more, with less work. I wound up with algorithms that were perfectly
transparent, when read presuming that various values were not nil --
but that also worked with nil. You could read the algorithm first,
presuming not-nil, and get the gist. Then you could ask "what happens
if such-and-such value is nil" and, much more often than not, the
Right Answer simply fell out of the same algorithm. Gosh the RnRS
authors are full of hot air in this area :-)

Nothing is False (alas, precious little is permitted)
-t
--------

Nerf is Dead. Long Live Nerf. A finer and prouder kitchen cat was
never born. Long Live Maxwell, His Brother, who, in spite of the
limitations of cat cognition, has taken sorrowful notice of His
Absense.

Nerf died, in part, of poverty. In Nerf's name, may the Revolution
live on, and flourish.

Adam Warner

unread,
Oct 25, 2002, 6:20:30 PM10/25/02
to
Hi panu,

When the distinction is important the functional language can return more
than one value. Here's a hash table example:

(setf hash-table (make-hash-table))
(gethash 'unknown-key hash-table)

Returns two values: nil and nil.

The first nil denotes no value associated with the key.
The second nil denotes that no key exists.

(setf (gethash 'key hash-table) nil)
(gethash 'key hash-table)

Returns two values: nil and t. That is the symbol key exists (t) and is
associated with the value nil.

> In Smalltalk it is easy to 'reflect' on a program since we have 'nil' to
> signify that something is "missing from" the OO model represented by the
> Smalltalk program. This is used frequently in 'lazy initializers' which
> first use reflection to realize that a variable has no value, and if so
> create a default value for it.
>
> Also, I can override #notUnderstood: so that any message without a
> corresponding defined method returns 'nil' to signify that the program has
> "no information" about how to interpret the request. This means something
> like "This attribute is undefined" or "Request not understood" - as
> opposed to:
>
> "I understand the question and I'm able to tell you
> the answer is: 'none'".
>
> An OO program seems to be more capable of "knowing what it doesn't know",
> than a functional program, which is simply what it is, a big function with
> several components.
>
> I may be wrong, but I guess my question boils down to:
>
> 1. "What is the equivalent of Smalltalk's #notUnderstood: in
> functional languages?"
>
> 2. "How do you distinguish between 'missing information', and
> known information that the 'answer is an empty list' ?"

By returning an additional value to clarify the status of the empty list.
Usually there is no need to make such a distinction. But even if there is,
why can't a non-nil symbol denote a missing value--let's call it
missing-information. Then you might argue that there could be information
that's similar to missing-information so we need a way to distinguish
between missing-information and information that is missing but is not
missing-information. Again you could return a second value to eliminate
the ambiguity.

While I don't know much about the OO-paradigm you could also do this in
Lisp:

(defstruct info missing answer)

(make-info :missing t :answer nil)

This returns the structure #S(info :missing t :answer nil). It's easy to
find out the values of info-answer and info-missing.

Don't forget that Lisp is multi-paradigm. So if the answer is "OO is
better" then the Lispers can take off their functional programming hat and
agree with you. The same with imperative programming or iteration.

Regards,
Adam

Vassil Nikolov

unread,
Oct 25, 2002, 6:46:39 PM10/25/02
to
On Fri, 25 Oct 2002 17:18:19 -0400, panu <pa...@fcc.net> said:

[...]
PV> In Lisp nil is (more or less) equal to an "empty list".

In Lisp, NIL is primarily the `null' reference. It then becomes
the empty list, because the null reference is the natural value for
the last tail of a list. True, technically the value of NIL is an
object (the symbol which is the value of (INTERN "CL:NIL")), but
not `conceptually.' (And that object is (to be treated as)
immutable.)

PV> In Smalltalk nil is best thought of as "undefined value",
PV> since "OrderedCollection new" is already a good representation
PV> of an empty list.

I don't know Smalltalk that well, if at all, but isn't
"OrderedCollection new" an object?

This is an important point. An ordered collection in Lisp would be
a sequence. An empty ordered collection would then be a sequence
whose length is 0. There are two possibilities: the empty list,
and a vector of length 0. Now, if you want to destructively add an
element to an empty sequence, you just cannot do that with the
empty list in Lisp, but you can, at least in a number of cases, do
that with a vector of length 0 (for example, if it has a fill
pointer, or if it is adjustable). In that sense, Lisp's empty list
is not an object, while an empty vector is.

(I have probably screwed up the terminology somewhat, but I hope at
least the point is clear. A `sequence of length 0' is, of course,
a value S such that (= (LENGTH S) 0).)

PV> And because a variable that was never given
PV> a value, returns nil when you ask for that value.

If we are talking about a special variable in Lisp, then it would
be unbound in such a case, which is different from it having a
value of NIL, and which is a situation where it is an error to
access its value.

If we are talking about a lexical variable, then it will be
implicitly initialized to NIL if the programmer did not provide an
explicit initial value, but I don't know if this is analogous to
the situation in Smalltalk.

There is another difference between Lisp and other object-oriented
languages (yes, Lisp is object-oriented, and not just because of
CLOS). Again, I don't really know how it is in Smalltalk, but in
Java, for example, null is a value that is of any (object) type,
while in Lisp NIL is a value of only two types, NULL (whose only
value is NIL) and LIST (which is a special case anyway, being the
union of NULL and CONS).

So, for example, if in Lisp a variable has been declared as (say) a
string, it is an error if that variable is set to NIL (this error
may or may not be actually signalled depending on a number of
circumstances, but that is a different matter). In Java, on the
other hand, it is perfectly OK for a String variable to have a
value of null, and it in fact happens quite often. (This, combined
with the fact that you cannot invoke a method off null, leads to a
rather unwelcome proliferation of things like
``(s != null)? s.substring(b, e) : null''.)

[...]
PV> 2. "How do you distinguish between 'missing information', and


known information that the 'answer is an empty list' ?"

There isn't a `one size fits all' solution.

Sometimes just returning NIL is good enough.

Sometimes the programmer may provide a value to be returned for
`missing information' (as in GET's last argument, or READ's
eof-value argument), which would default to NIL.

Sometimes an additional value would be returned, serving as a
`missing information' flag (see e.g. SUBTYPEP).

Sometimes an error would be signalled for the case of missing
information.

(I would also like to note that I am not very concerned which is
the True Way of Functional Programming, or the True Way of
Object-Oriented Programming, for choosing the `missing information'
value.)

---Vassil.

--
For an M-person job assigned to an N-person team, only rarely M=N.

Matthew Danish

unread,
Oct 25, 2002, 8:51:27 PM10/25/02
to
On Fri, Oct 25, 2002 at 06:46:39PM -0400, Vassil Nikolov wrote:
> element to an empty sequence, you just cannot do that with the
> empty list in Lisp, but you can, at least in a number of cases, do
> that with a vector of length 0 (for example, if it has a fill
> pointer, or if it is adjustable). In that sense, Lisp's empty list
> is not an object, while an empty vector is.
>
> (I have probably screwed up the terminology somewhat, but I hope at

Yes: you yourself have already pointed out that NIL is an immutable
object. In what sense is Lisp's empty list not an object? Perhaps you
meant that Lisp's empty list is not a mutable object, if you are
speaking of the above context?

--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

Vassil Nikolov

unread,
Oct 25, 2002, 10:53:06 PM10/25/02
to

Correction:

On 25 Oct 2002 18:46:39 -0400, Vassil Nikolov <vnik...@poboxes.com>
made a stupid mistake:

VN> (the symbol which is the value of (INTERN "CL:NIL"))
^^^^^^^^^^^^^^^^^

As it was kindly pointed out to me, the above is incorrect and
should be (INTERN "NIL" (FIND-PACKAGE "CL")). My bad.

Vassil Nikolov

unread,
Oct 25, 2002, 11:22:36 PM10/25/02
to
On Fri, 25 Oct 2002 20:51:27 -0400, Matthew Danish <mda...@andrew.cmu.edu> said:

On Fri, Oct 25, 2002 at 06:46:39PM -0400, Vassil Nikolov wrote:

VN> element to an empty sequence, you just cannot do that with the
VN> empty list in Lisp, but you can, at least in a number of cases, do
VN> that with a vector of length 0 (for example, if it has a fill
VN> pointer, or if it is adjustable). In that sense, Lisp's empty list
VN> is not an object, while an empty vector is.
VN>
VN> (I have probably screwed up the terminology somewhat, but I hope at

MD> Yes: you yourself have already pointed out that NIL is an immutable
MD> object. In what sense is Lisp's empty list not an object?

In an intuitive sense which to my shame I find hard to explain...

MD> Perhaps you
MD> meant that Lisp's empty list is not a mutable object, if you are
MD> speaking of the above context?

It's more than that---it is a special object that is `the tag of
nothing' (`To be able to tag Nothing! Why, it's as much as an
ordinary object system can do to tag real objects!').

Maybe the DELETE example explains it best. As everyone learns
sooner or later, (DELETE FOO BAR) is wrong; one must say
(SETQ BAR (DELETE FOO BAR)). The non-essential reason for this is
that DELETE might not actually work destructively, or modify the
conses in the way one expects; the essential reason, which holds
even if DELETE is constrained to do the `natural' destructive
thing, is that the result might be NIL. This is of course related
to the `call by value of reference' can of worms...

(In a language, or a library, where a list object is represented by
something like a structure defined by (DEFSTRUCT LIST-OBJECT HEAD),
destructive deletion would not have the above issue, and the empty
list would be the equivalent of #S(LIST-OBJECT :HEAD NIL).)

---Vassil.

P.S. I have a suspicion that this has already been explained a
finite number of times, but I am too lazy tonight to do the proper
search, for which I apologize.

Kalle Olavi Niemitalo

unread,
Oct 26, 2002, 3:06:37 AM10/26/02
to
Vassil Nikolov <vnik...@poboxes.com> writes:

> As it was kindly pointed out to me, the above is incorrect and
> should be (INTERN "NIL" (FIND-PACKAGE "CL")). My bad.

The second parameter is a package designator, so this can also be
written (INTERN "NIL" "CL").

Kalle Olavi Niemitalo

unread,
Oct 26, 2002, 3:43:12 AM10/26/02
to
Vassil Nikolov <vnik...@poboxes.com> writes:

> True, technically the value of NIL is an object (the symbol
> which is the value of (INTERN "CL:NIL")), but not `conceptually.'
> (And that object is (to be treated as) immutable.)

According to CLHS 11.1.2.1.2.1, it can be lexically bound as a
function or macro: (FLET ((NIL ())) (NIL)). Debian CMUCL 3.1.4
and SBCL 0.7.8-1 get this wrong: they allow binding T and (SETF
NIL) but not NIL.

I don't see any restriction against changing the property list
either.

Matthew Danish

unread,
Oct 26, 2002, 8:27:37 AM10/26/02
to
On Fri, Oct 25, 2002 at 11:22:36PM -0400, Vassil Nikolov wrote:
> On Fri, 25 Oct 2002 20:51:27 -0400, Matthew Danish <mda...@andrew.cmu.edu> said:
>
> On Fri, Oct 25, 2002 at 06:46:39PM -0400, Vassil Nikolov wrote:
> VN> element to an empty sequence, you just cannot do that with the
> VN> empty list in Lisp, but you can, at least in a number of cases, do
> VN> that with a vector of length 0 (for example, if it has a fill
> VN> pointer, or if it is adjustable). In that sense, Lisp's empty list
> VN> is not an object, while an empty vector is.
> VN>
> VN> (I have probably screwed up the terminology somewhat, but I hope at
>
> MD> Yes: you yourself have already pointed out that NIL is an immutable
> MD> object. In what sense is Lisp's empty list not an object?
>
> In an intuitive sense which to my shame I find hard to explain...
>
> MD> Perhaps you
> MD> meant that Lisp's empty list is not a mutable object, if you are
> MD> speaking of the above context?
>
> It's more than that---it is a special object that is `the tag of
> nothing' (`To be able to tag Nothing! Why, it's as much as an
> ordinary object system can do to tag real objects!').

Throwing the term ``Nothing'' around like this is very dangerous.

``Nothing'' as I understand it is the negation of the existential
quantifier over some statement. ``Nothing can save a BASIC
programmer.'' translates to ``It is not the case that there exists
something which can save a BASIC programmer.''

The usage of ``nothing'' as a noun in the phrase ``tag of nothing'' is
logically incorrect, but a mistake that is easily made due to the
cavalier usage of the word ``nothing'' in the English language. [1]

Back to definitions:

``empty list n. -- the list containing no elements'' -- CLHS (Glossary)

``The only object of type null is nil, which represents the empty list
and can also be notated ().'' -- CLHS (System Class NULL)

This is not to be confused with the type `nil' which is the type with no
members.

As you can see, the empty list is not only something, it is the member
of a type too!

>
> Maybe the DELETE example explains it best. As everyone learns
> sooner or later, (DELETE FOO BAR) is wrong; one must say
> (SETQ BAR (DELETE FOO BAR)). The non-essential reason for this is
> that DELETE might not actually work destructively, or modify the
> conses in the way one expects; the essential reason, which holds
> even if DELETE is constrained to do the `natural' destructive
> thing, is that the result might be NIL. This is of course related

Lists are constructed from one or more objects, disregarding their
contents. Arrays in themselves are one object (bound to many others,
usually).

> to the `call by value of reference' can of worms...

There is no ``can of worms'' here. Call-by-value semantics are very
well established in the programming languages community.

>
> (In a language, or a library, where a list object is represented by
> something like a structure defined by (DEFSTRUCT LIST-OBJECT HEAD),
> destructive deletion would not have the above issue, and the empty
> list would be the equivalent of #S(LIST-OBJECT :HEAD NIL).)

This is correct, but does not pertain to my original assertion, which is
that the empty list is an object in Common Lisp.

The Hyperspec provides a definition of object (``any Lisp datum'') which
is fairly clear on this matter. I am merely speculating, but I think
your confusion lies in that you feel that some layer of abstraction must
necessarily exist between a sequence object and its constituent parts,
while Common Lisp does not agree. (typep nil 'sequence) ==> T.


[1] Carnap, Rudolf. ``The elimination of metaphysics through logical
analysis of language.''

(There are some examples of truly horrid abuses of the word ``nothing''
in this article)

Vassil Nikolov

unread,
Oct 26, 2002, 12:49:19 PM10/26/02
to
On 26 Oct 2002 10:06:37 +0300, Kalle Olavi Niemitalo <k...@iki.fi> said:

Vassil Nikolov <vnik...@poboxes.com> writes:
VN> As it was kindly pointed out to me, the above is incorrect and
VN> should be (INTERN "NIL" (FIND-PACKAGE "CL")). My bad.

KON> The second parameter is a package designator, so this can also be
KON> written (INTERN "NIL" "CL").

True, of course, but I would still write it with the call to
FIND-PACKAGE since part of my intent was to make the mappings from
names (as strings) to the relevant objects explicit. (Otherwise, I
would have just written `the symbol NIL', rather than `the value of
(INTERN ...).')

Vassil Nikolov

unread,
Oct 26, 2002, 1:12:53 PM10/26/02
to
On 26 Oct 2002 10:43:12 +0300, Kalle Olavi Niemitalo <k...@iki.fi> said:

Vassil Nikolov <vnik...@poboxes.com> writes:
VN> True, technically the value of NIL is an object (the symbol
VN> which is the value of (INTERN "CL:NIL")), but not `conceptually.'
VN> (And that object is (to be treated as) immutable.)

KON> According to CLHS 11.1.2.1.2.1, it can be lexically bound as a
KON> function or macro: (FLET ((NIL ())) (NIL)). [...]

Doing that does not transgress on the immutability of NIL. When
you have lexical bindings, the symbol that names the binding serves
merely as a key in the lexical environment. The effect of the
above FLET form, modulo implementation details, is to push the
value of (CONS 'NIL #'(LAMBDA ())) onto the (functional) lexical
environment of the body---no modifications of NIL involved.


KON> I don't see any restriction against changing the property list
KON> either.

Yes, this would be a modification, and that is why I inserted that
`is to be treated as,' moreover that it would be rather rare to
have a good reason to change NIL's property list (especially for
something different from debugging purposes).

Vassil Nikolov

unread,
Oct 26, 2002, 4:26:34 PM10/26/02
to
On Sat, 26 Oct 2002 08:27:37 -0400, Matthew Danish <mda...@andrew.cmu.edu> said:

[...]


MD> Perhaps you
MD> meant that Lisp's empty list is not a mutable object, if you are
MD> speaking of the above context?

VN> It's more than that---it is a special object that is `the tag of
VN> nothing' (`To be able to tag Nothing! Why, it's as much as an
VN> ordinary object system can do to tag real objects!').

MD> Throwing the term ``Nothing'' around like this is very dangerous.

Well, I thought that the quotation marks, and the paraphrase from
Lewis Carroll, made it unnecessary to explicitly mark the above
paragraph as one that should be taken with a grain of salt.

MD> ``Nothing'' as I understand it is the negation of the existential
MD> quantifier over some statement. ``Nothing can save a BASIC
MD> programmer.'' translates to ``It is not the case that there exists
MD> something which can save a BASIC programmer.''

The obvious Carrollian response of `Nothing must be very powerful,
then!' would be another example of cavalier usage of that word, I
suppose...

MD> The usage of ``nothing'' as a noun in the phrase ``tag of nothing'' is
MD> logically incorrect, but a mistake that is easily made due to the
MD> cavalier usage of the word ``nothing'' in the English language. [1]

I cannot comment on word usage in the English language, and besides
I don't know to what extent English is special in this respect.

Besides, `nil' _means_ `nothing,' after all.

MD> Back to definitions:

MD> ``empty list n. -- the list containing no elements'' -- CLHS (Glossary)

MD> ``The only object of type null is nil, which represents the empty list
MD> and can also be notated ().'' -- CLHS (System Class NULL)

MD> This is not to be confused with the type `nil' which is the type with no
MD> members.

MD> As you can see, the empty list is not only something, it is the member
MD> of a type too!

It would have been very strange if it were something which was
_not_ a member of any type...

In any case, I am not saying that NIL is not an object; what I am
saying is that it is a very special object, and the programmer
should not---at least usually---think of it as an object except in
a technical sense.


VN> Maybe the DELETE example explains it best. As everyone learns
VN> sooner or later, (DELETE FOO BAR) is wrong; one must say
VN> (SETQ BAR (DELETE FOO BAR)). The non-essential reason for this is
VN> that DELETE might not actually work destructively, or modify the
VN> conses in the way one expects; the essential reason, which holds
VN> even if DELETE is constrained to do the `natural' destructive
VN> thing, is that the result might be NIL. This is of course related

MD> Lists are constructed from one or more objects, disregarding their
MD> contents. Arrays in themselves are one object (bound to many others,
MD> usually).

So, does that mean that the example is bad? And this particular
example does not refer to arrays (it talks about conses, and also
DELETE won't return NIL if the sequence argument is an array).

VN> to the `call by value of reference' can of worms...

MD> There is no ``can of worms'' here. Call-by-value semantics are very
MD> well established in the programming languages community.

`Can of worms' referred---too obscurely---to the possibility of a
lengthy discussion whether Lisp argument passing is call-by-value
or not.

VN> (In a language, or a library, where a list object is represented by
VN> something like a structure defined by (DEFSTRUCT LIST-OBJECT HEAD),
VN> destructive deletion would not have the above issue, and the empty
VN> list would be the equivalent of #S(LIST-OBJECT :HEAD NIL).)

MD> This is correct, but does not pertain to my original assertion, which is
MD> that the empty list is an object in Common Lisp.

Well, I find a distinction between `is' and `represented by' here
(as the language definition says, the empty list _is represented
by_ NIL). In other words, NIL to me is a symbol^1, rather than a
list that is adorned with a print name, a value slot, a function
slot, and a package.
_________
^1 which is chosen as the value of the cdr of the last cons in each
proper list, and thus represents the empty list, and also chosen
to represent the false boolean value


MD> The Hyperspec provides a definition of object (``any Lisp datum'') which
MD> is fairly clear on this matter.

True; I was referring to languages where not every datum is an
object (or what they often call an `instance').

MD> I am merely speculating, but I think
MD> your confusion lies in that you feel that some layer of abstraction must
MD> necessarily exist between a sequence object and its constituent parts,
MD> while Common Lisp does not agree. (typep nil 'sequence) ==> T.

That is not _my_ feeling. That is my understanding of the feeling
of the designers of many libraries dealing with
lists/sequences/collections/etc. I wanted to show how the Lisp way
differs from those.

---Vassil.

Kaz Kylheku

unread,
Oct 28, 2002, 7:03:48 PM10/28/02
to
lo...@emf.emf.net (Tom Lord) wrote in message news:<urjgj9c...@corp.supernews.com>...

> The epiphany was this: the "liberal" use of nil (as false, as end of
> list, as a nil-returning argument to CAR and CDR) is damn convenient.

Note that in comp.lang.scheme, this is considered flamebait, even
though its truth is obvious in comp.lang.lisp. It's best to leave the
Schemers to their logical purity, and keep them away from CAR NIL
knowledge. ;)

> I made the decision to take advantage of `(car nil) => nil' and so
> forth in this program. The result was that the code accomplished
> more, with less work. I wound up with algorithms that were perfectly
> transparent, when read presuming that various values were not nil --
> but that also worked with nil.

The Schemer credo is that because (car nil) blows up, it helps in the
discovery of bugs in list manipulation code. I don't understand how,
but each to his own.

Sander Vesik

unread,
Oct 28, 2002, 9:18:17 PM10/28/02
to
In comp.lang.scheme Kaz Kylheku <k...@ashi.footprints.net> wrote:
> The Schemer credo is that because (car nil) blows up, it helps in the
> discovery of bugs in list manipulation code. I don't understand how,
> but each to his own.

well, imho its not so much that but the fact that '() is not
a pair - and car / cdr are defined as operating on pairs and
hence there is no reason to expect car/cdr to operate on '()

Otherwise you would have to define '() as the immutable pair
which both "car" and "cdr" slots pointed to itself - imho not
nice at all.

--
Sander

+++ Out of cheese error +++

ozan s yigit

unread,
Oct 28, 2002, 11:41:24 PM10/28/02
to
Kaz Kylheku:

| Tom Lord:


| > The epiphany was this: the "liberal" use of nil (as false, as end of
| > list, as a nil-returning argument to CAR and CDR) is damn convenient.
|
| Note that in comp.lang.scheme, this is considered flamebait, even
| though its truth is obvious in comp.lang.lisp. It's best to leave the
| Schemers to their logical purity, and keep them away from CAR NIL
| knowledge. ;)

it is worth noting that other members of the lisp family have also
kept away from the knotty convenience of (car nil). ISLISP comes to
mind... (and perhaps EULISP too, but i don't have feel running
right now)

oz
--
a nought, an ought, a knot, a not easily perceived distinction. -- t. duff

Paul F. Dietz

unread,
Oct 29, 2002, 9:06:37 AM10/29/02
to
Kaz Kylheku wrote:

> It's best to leave the Schemers to their logical purity,
> and keep them away from CAR NIL knowledge. ;)

Oof! :)

Paul

Joe Marshall

unread,
Oct 29, 2002, 9:50:55 AM10/29/02
to
ozan s yigit <o...@blue.cs.yorku.ca> writes:

> Kaz Kylheku:
>
> | Tom Lord:
> | > The epiphany was this: the "liberal" use of nil (as false, as end of
> | > list, as a nil-returning argument to CAR and CDR) is damn convenient.
> |
> | Note that in comp.lang.scheme, this is considered flamebait, even
> | though its truth is obvious in comp.lang.lisp. It's best to leave the
> | Schemers to their logical purity, and keep them away from CAR NIL
> | knowledge. ;)
>
> it is worth noting that other members of the lisp family have also
> kept away from the knotty convenience of (car nil). ISLISP comes to
> mind... (and perhaps EULISP too, but i don't have feel running
> right now)

I believe (but I could be wrong) that (car nil) => nil originally
comes from Interlisp and that MacLisp would generate an error.

Kaz Kylheku

unread,
Oct 29, 2002, 2:00:09 PM10/29/02
to
Sander Vesik <san...@haldjas.folklore.ee> wrote in message news:<10358579...@haldjas.folklore.ee>...

> In comp.lang.scheme Kaz Kylheku <k...@ashi.footprints.net> wrote:
> > The Schemer credo is that because (car nil) blows up, it helps in the
> > discovery of bugs in list manipulation code. I don't understand how,
> > but each to his own.
>
> well, imho its not so much that but the fact that '() is not
> a pair - and car / cdr are defined as operating on pairs and
> hence there is no reason to expect car/cdr to operate on '()

There is no reason to expect + to operate on mixtures of integers,
rationals *and* floating points, either, or for PRINT to operate on
everything.

> Otherwise you would have to define '() as the immutable pair
> which both "car" and "cdr" slots pointed to itself - imho not
> nice at all.

Or, what is worse, you might have to adjust your thinking and accept
the idea that the properties of a pair object are not defined by the
inputs and outputs of the CAR and CDR functions. That something can be
passed to CAR does not make it a pair. Similarly, that something can
be added with an integer does not make it an integer, or that
something can be printed does not make it a string of text.

Sander Vesik

unread,
Oct 29, 2002, 7:35:50 PM10/29/02
to
In comp.lang.scheme Kaz Kylheku <k...@ashi.footprints.net> wrote:
> Sander Vesik <san...@haldjas.folklore.ee> wrote in message news:<10358579...@haldjas.folklore.ee>...
>> In comp.lang.scheme Kaz Kylheku <k...@ashi.footprints.net> wrote:
>> > The Schemer credo is that because (car nil) blows up, it helps in the
>> > discovery of bugs in list manipulation code. I don't understand how,
>> > but each to his own.
>>
>> well, imho its not so much that but the fact that '() is not
>> a pair - and car / cdr are defined as operating on pairs and
>> hence there is no reason to expect car/cdr to operate on '()
>
> There is no reason to expect + to operate on mixtures of integers,
> rationals *and* floating points, either, or for PRINT to operate on
> everything.

There is *a* reason to expect it to operate on numbers (as defined
by number?) - if this was not so, having a full numerical tree
would become a lot less meaningful. I would agree if + was defined
in terms of integers - except it isn't.

>
>> Otherwise you would have to define '() as the immutable pair
>> which both "car" and "cdr" slots pointed to itself - imho not
>> nice at all.
>
> Or, what is worse, you might have to adjust your thinking and accept
> the idea that the properties of a pair object are not defined by the
> inputs and outputs of the CAR and CDR functions. That something can be
> passed to CAR does not make it a pair. Similarly, that something can
> be added with an integer does not make it an integer, or that
> something can be printed does not make it a string of text.

R^5RS:
procedure: (car pair)

Returns the contents of the car field of pair.

+ is a function defined to take parameters of type number, car (and cdr)
are defined to take a parameter (and not three parameters or ten or ...)
of type pair (and not string or ...)

Strictly going by the text of R5RS its more correct to take the car of
a string than a car of '() and the first is not explicitly notes as
being an error.

Vlad S.

unread,
Oct 29, 2002, 10:27:02 PM10/29/02
to
> Note that in comp.lang.scheme, this is considered flamebait, even
> though its truth is obvious in comp.lang.lisp. It's best to leave the
> Schemers to their logical purity, and keep them away from CAR NIL
> knowledge. ;)

> The Schemer credo is that because (car nil) blows up, it helps in the


> discovery of bugs in list manipulation code. I don't understand how,
> but each to his own.

I think this is because of the standard Scheme null? predicate. This
is the prefered way to test for an empty list (I don't really know
what advantages it has over (eq? x '()) - maybe interpreter speed
tricks?) - because of this, the rationale is you shouldn't ever need
to take the car/cdr of the null list, and if you are, you likely
missed the end-case conditional and are going to get stuck in an
infinite loop thanks to mr. tail recursion.

There are also a couple of bastard half-predicate, half-list
list-extraction procedures (memq and friends) that return a boolean
false if they don't find what they're looking for - although this
actually strengthens NIL's case because it would be more general and
consistent.

William D Clinger

unread,
Oct 29, 2002, 11:09:54 PM10/29/02
to
[I have deleted comp.lang.smalltalk from the list of crossposts.]

Joe Marshall wrote:
> I believe (but I could be wrong) that (car nil) => nil originally
> comes from Interlisp and that MacLisp would generate an error.

You're right [1], but MacLisp had adopted the Interlisp
behavior by the time I began to use it circa 1975.

Will

[1] Guy Steele and Richard Gabriel. The evolution of Lisp.
In proceedings of the History of Programming Languages
conference, April 1993, pages 231-270.

Vassil Nikolov

unread,
Oct 30, 2002, 1:18:10 AM10/30/02
to

[following up to comp.lang.lisp only]

On 29 Oct 2002 19:27:02 -0800, voodo...@hotmail.com (Vlad S.) said:

[...]
VS> is the prefered way to test for an empty list (I don't really know
VS> what advantages it has over (eq? x '()) - maybe interpreter speed
VS> tricks?)

One advantage is the ability to express intent clearly. This is
the main benefit, for example, of having both NOT and NULL, which
are semantically equivalent.

Another advantage is that having a comprehensive selection of
one-argument functions makes mapping operations less verbose
(otherwise we would either have to define them or use anonymous
functions just for `arglist reduction').

As to speed advantages, they are not necessarily restricted to the
interpreter, as the obvious example of ENDP shows.

Janis Dzerins

unread,
Oct 30, 2002, 2:32:35 AM10/30/02
to
Vassil Nikolov <vnik...@poboxes.com> writes:

> [following up to comp.lang.lisp only]
>
> On 29 Oct 2002 19:27:02 -0800, voodo...@hotmail.com (Vlad S.) said:
>
> [...]
> VS> is the prefered way to test for an empty list (I don't really know
> VS> what advantages it has over (eq? x '()) - maybe interpreter speed
> VS> tricks?)
>
> One advantage is the ability to express intent clearly. This is
> the main benefit, for example, of having both NOT and NULL, which
> are semantically equivalent.

I think you missed Vlad's point a bit, first by following up to
comp.lang.lisp. He was talking abount Scheme. It is Common Lisp
where you can do a certain thing in more than one way, and choose the
one that communicates your intent most accurately. In Scheme it is a
bit upside-down -- you should have only one way do a certain thing, so
everybody else can know what is your intent.

But having null? in Scheme makes me wonder a bit why it is there, if
you can, as shown above, use eq?. Is it not a redundancy that, if
taken out, would make Scheme even smaller (and hence more beautiful)?

I may sound a little sarcastic, but I'm really curious.

--
Janis Dzerins

If million people say a stupid thing, it's still a stupid thing.

Dorai Sitaram

unread,
Oct 30, 2002, 9:58:57 AM10/30/02
to
In article <twkvg3k...@gulbis.latnet.lv>,

Janis Dzerins <jo...@latnet.lv> wrote:
>
>I think you missed Vlad's point a bit, first by following up to
>comp.lang.lisp. He was talking abount Scheme. It is Common Lisp
>where you can do a certain thing in more than one way, and choose the
>one that communicates your intent most accurately. In Scheme it is a
>bit upside-down -- you should have only one way do a certain thing, so
>everybody else can know what is your intent.
>
>But having null? in Scheme makes me wonder a bit why it is there, if
>you can, as shown above, use eq?. Is it not a redundancy that, if
>taken out, would make Scheme even smaller (and hence more beautiful)?
>
>I may sound a little sarcastic, but I'm really curious.

If that's the standard of redundancy you want to hold
Scheme to, Scheme will "fail" easily. null? is
hardly the sole example of such failure. Cond, case;
do; let, let*, letrec; list; append, reverse; and, or,
not; memq, memv, member; assq, assv, assoc; for-each,
map; are all obtainable from the remaining. Scheme
isn't about rooting out superficial redundancy. It
isn't even about avoiding nomenclatural redundancy (eg,
not vs null?). It is about avoiding multiple core
mechanisms -- like, say, tossing out an dedicated
iterative mechanism in favor of requiring TCE.

Dorai Sitaram

unread,
Oct 30, 2002, 10:02:55 AM10/30/02
to
I wrote
>
>[Scheme]

>isn't even about avoiding nomenclatural redundancy (eg,
>not vs null?).

I guess I'm too much of a Common Lisper after
all. (not and null? are of course quantifiably
different things in Scheme.)

Kaz Kylheku

unread,
Oct 30, 2002, 11:53:36 AM10/30/02
to
Sander Vesik <san...@haldjas.folklore.ee> wrote in message news:<10359381...@haldjas.folklore.ee>...

> In comp.lang.scheme Kaz Kylheku <k...@ashi.footprints.net> wrote:
> > Sander Vesik <san...@haldjas.folklore.ee> wrote in message news:<10358579...@haldjas.folklore.ee>...
> >> In comp.lang.scheme Kaz Kylheku <k...@ashi.footprints.net> wrote:
> >> > The Schemer credo is that because (car nil) blows up, it helps in the
> >> > discovery of bugs in list manipulation code. I don't understand how,
> >> > but each to his own.
> >>
> >> well, imho its not so much that but the fact that '() is not
> >> a pair - and car / cdr are defined as operating on pairs and
> >> hence there is no reason to expect car/cdr to operate on '()
> >
> > There is no reason to expect + to operate on mixtures of integers,
> > rationals *and* floating points, either, or for PRINT to operate on
> > everything.
>
> There is *a* reason to expect it to operate on numbers (as defined
> by number?) - if this was not so, having a full numerical tree
> would become a lot less meaningful. I would agree if + was defined
> in terms of integers - except it isn't.

The + function can be defined in whatever terms you want it to be.
There is indeed a good reason why it is generic to different kinds of
numbers and their combinations. It would be terribly inconvenient to
have it be otherwise.

The B language which preceded C had separate operators for floating
point. They had a # prefix, as in #+ #- #* #/ . That idiocy was
dropped.

> >> Otherwise you would have to define '() as the immutable pair
> >> which both "car" and "cdr" slots pointed to itself - imho not
> >> nice at all.
> >
> > Or, what is worse, you might have to adjust your thinking and accept
> > the idea that the properties of a pair object are not defined by the
> > inputs and outputs of the CAR and CDR functions. That something can be
> > passed to CAR does not make it a pair. Similarly, that something can
> > be added with an integer does not make it an integer, or that
> > something can be printed does not make it a string of text.
>
> R^5RS:
> procedure: (car pair)
>
> Returns the contents of the car field of pair.
>
> + is a function defined to take parameters of type number, car (and cdr)
> are defined to take a parameter (and not three parameters or ten or ...)
> of type pair (and not string or ...)

In Scheme yes; but you see other languages have a CAR function too.

(car nil), or in Scheme terms (car '()), is exactly like (sqrt -1).
You can restrict the domain to real numbers, and throw an error. Or
you can extend the domain to the complex plane and return the
imaginary value i.

The Lisp version of CAR extends the domain from conses to lists, which
include nil in the domain value, and introduces the rule that you can
access the CAR and CDR (also known as FIRST and REST) of an empty
list, producing NIL. There is nothing wrong with this extension of the
list algebra.

People objected to imaginary numbers too when those were discovered;
that's why they are called imaginary. The naysayers eventually had to
cave in, because imaginary numbers turned out to be incredibly
convenient, leading to straightforward computations and
representations where contortions existed previously, for the sake of
avoiding the computation of the square root of a negative number.

In Lisp, we have an imaginary CAR field of the NIL value. It does the
same thing as imaginary numbers: it takes some contortions out of
expressions operating on lists, which exist only for the sake of
avoiding the invocation of CAR or FIRST on an empty list.

Imagine that!



> Strictly going by the text of R5RS its more correct to take the car of
> a string than a car of '() and the first is not explicitly notes as
> being an error.

If you go strictly by the text of R5RS, then you can't think
critically about the design decisions imposed by that text; you are
within the box.

Sander Vesik

unread,
Oct 30, 2002, 1:21:33 PM10/30/02
to
In comp.lang.scheme Kaz Kylheku <k...@ashi.footprints.net> wrote:
>> There is *a* reason to expect it to operate on numbers (as defined
>> by number?) - if this was not so, having a full numerical tree
>> would become a lot less meaningful. I would agree if + was defined
>> in terms of integers - except it isn't.
>
> The + function can be defined in whatever terms you want it to be.
> There is indeed a good reason why it is generic to different kinds of
> numbers and their combinations. It would be terribly inconvenient to
> have it be otherwise.
>
> The B language which preceded C had separate operators for floating
> point. They had a # prefix, as in #+ #- #* #/ . That idiocy was
> dropped.

Ultimately, the machine that the code runs on will have different
operators for integers and floating point, so depending on what
level you want to program, having the operators be distinct is
nothing odd.

>
>> >> Otherwise you would have to define '() as the immutable pair
>> >> which both "car" and "cdr" slots pointed to itself - imho not
>> >> nice at all.
>> >
>> > Or, what is worse, you might have to adjust your thinking and accept
>> > the idea that the properties of a pair object are not defined by the
>> > inputs and outputs of the CAR and CDR functions. That something can be
>> > passed to CAR does not make it a pair. Similarly, that something can
>> > be added with an integer does not make it an integer, or that
>> > something can be printed does not make it a string of text.
>>
>> R^5RS:
>> procedure: (car pair)
>>
>> Returns the contents of the car field of pair.
>>
>> + is a function defined to take parameters of type number, car (and cdr)
>> are defined to take a parameter (and not three parameters or ten or ...)
>> of type pair (and not string or ...)
>
> In Scheme yes; but you see other languages have a CAR function too.
>
> (car nil), or in Scheme terms (car '()), is exactly like (sqrt -1).
> You can restrict the domain to real numbers, and throw an error. Or
> you can extend the domain to the complex plane and return the
> imaginary value i.

It is not exactly like (sqrt -1) it is exactly like having the car
of a string return the first character.

>
> The Lisp version of CAR extends the domain from conses to lists, which
> include nil in the domain value, and introduces the rule that you can
> access the CAR and CDR (also known as FIRST and REST) of an empty
> list, producing NIL. There is nothing wrong with this extension of the
> list algebra.

see, the problem is that for this to be true or relevant you would need
to have a distinct list type (and not just a bunch of cons cells which
happened to link to each other). And consequently you are passing
judgment on what the base type should do based on something cobbled up
from the base types, a bunch of assumptions and a constant.

>
> People objected to imaginary numbers too when those were discovered;
> that's why they are called imaginary. The naysayers eventually had to
> cave in, because imaginary numbers turned out to be incredibly
> convenient, leading to straightforward computations and
> representations where contortions existed previously, for the sake of
> avoiding the computation of the square root of a negative number.
>
> In Lisp, we have an imaginary CAR field of the NIL value. It does the
> same thing as imaginary numbers: it takes some contortions out of
> expressions operating on lists, which exist only for the sake of
> avoiding the invocation of CAR or FIRST on an empty list.

Why, of course, and by being able to take the car of everything that
can possibly be broken apart and returning the object itself if you
can't will let you "take out of contortions of handling any object
as if it was a list". Its still a very bad idea though.

>
> Imagine that!
>
>> Strictly going by the text of R5RS its more correct to take the car of
>> a string than a car of '() and the first is not explicitly notes as
>> being an error.
>
> If you go strictly by the text of R5RS, then you can't think
> critically about the design decisions imposed by that text; you are
> within the box.

Why of course - then again, this is merely a lame thread trying to find
justifications from other languages to changing scheme. The decision
of limiting car and cdr strictly to operating on pairs is good regardless
of any practices of other languages to the contrary.

Anton van Straaten

unread,
Oct 30, 2002, 1:28:25 PM10/30/02
to
Kaz Kylheku wrote:
> The Lisp version of CAR extends the domain from conses to lists, which
> include nil in the domain value, and introduces the rule that you can
> access the CAR and CDR (also known as FIRST and REST) of an empty
> list, producing NIL. There is nothing wrong with this extension of the
> list algebra.
>
> People objected to imaginary numbers too when those were discovered;
> that's why they are called imaginary. The naysayers eventually had to
> cave in, because imaginary numbers turned out to be incredibly
> convenient, leading to straightforward computations and
> representations where contortions existed previously, for the sake of
> avoiding the computation of the square root of a negative number.
>
> In Lisp, we have an imaginary CAR field of the NIL value. It does the
> same thing as imaginary numbers: it takes some contortions out of
> expressions operating on lists, which exist only for the sake of
> avoiding the invocation of CAR or FIRST on an empty list.

Why do you think languages like ML and Haskell chose not to use this
approach? Do you think the same reasons might apply to Scheme's choice?

That's a somewhat rhetorical question. I see quite a close connection.

Anton

Erann Gat

unread,
Oct 30, 2002, 1:57:27 PM10/30/02
to
In article <10358579...@haldjas.folklore.ee>, Sander Vesik
<san...@haldjas.folklore.ee> wrote:

> Otherwise you would have to define '() as the immutable pair
> which both "car" and "cdr" slots pointed to itself - imho not
> nice at all.

Why? I always thought that approach was rather elegant myself.

E.

Arthur Lemmens

unread,
Oct 30, 2002, 2:57:01 PM10/30/02
to

Kaz Kylheku wrote:

> In Lisp, we have an imaginary CAR field of the NIL value. It does the
> same thing as imaginary numbers: it takes some contortions out of
> expressions operating on lists

For a nice example of the consequences of not allowing (CAR NIL) and
distinguishing between NIL and false, see 'A SHORT BALLAD DEDICATED TO
THE GROWTH OF PROGRAMS' by Ashwin Ram. The first link I found is at
http://www.apl.jhu.edu/~hall/lisp/Scheme-Ballad.text.

Arthur Lemmens

Sander Vesik

unread,
Oct 30, 2002, 3:40:41 PM10/30/02
to

Its also a piece of pretty shoddy poetry in which the author also
manages to demonstrate his taste for bad programming. Not that
(cdr (assq key a-list)) actually would have solved the posed problem,
as it at most solves the second half...

>
> Arthur Lemmens

Sander Vesik

unread,
Oct 30, 2002, 3:50:21 PM10/30/02
to

Well, depends on whetever you want to treat '() as a simple constant
or a recursive structure.

>
> E.

Erik Naggum

unread,
Oct 30, 2002, 4:19:02 PM10/30/02
to
* Sander Vesik <san...@haldjas.folklore.ee>

| Well, depends on whetever you want to treat '() as a simple constant
| or a recursive structure.

Why do those have to be exclusive options? In Common Lisp it is both,
according as how you look at it. There is never any ambiguity unless you
wish to look at nil with the eyes of Pablo Picasso.

--
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

Tim Bradshaw

unread,
Oct 30, 2002, 8:50:20 PM10/30/02
to
* Sander Vesik wrote:

> Well, depends on whetever you want to treat '() as a simple constant
> or a recursive structure.

It can, of course, be both - a constant cons cell whose car and cdr
point to itself.

--tim

Dorai Sitaram

unread,
Oct 31, 2002, 8:28:53 AM10/31/02
to

No, it cannot be a constant /cons/ cell, because
we must -- even in CL -- absolutely distinguish between
() and

(let ((c (cons 'placeholder 'placeholder)))
(setf (car c) c)
(setf (cdr c) c)
c)

lest the meaningful activity of finding the last
cdr become ill-defined.

And indeed CL, like Scheme, does distinguish
between the two.

Tim Bradshaw

unread,
Oct 31, 2002, 8:58:48 AM10/31/02
to
* Dorai Sitaram wrote:

> No, it cannot be a constant /cons/ cell, because
> we must -- even in CL -- absolutely distinguish between
> () and

It can be a constant cons cell, so long as the system knows the value
of that constant. You can't fabricate a copy of it, because you can't
get that copy to be the same identical object. In other words, it
can't *only* be a cons whose car & cdr point back to itself, it also
has to be a particular such cell (perhaps one that exists at a
particular address, say).

> lest the meaningful activity of finding the last
> cdr become ill-defined.

Finding the last cdr involves just walking down the cdr chain until
you get to an object which is EQ to NIL, not simply to a cons which
happens to point back to itself.

--tim

Dorai Sitaram

unread,
Oct 31, 2002, 9:54:28 AM10/31/02
to

Yeah, you're right. (And I meant to say last pair of
course, not last cdr, because there are already
pairs in CL that don't have a last cdr, but still
have a last pair.)

Extending your proposal by just a smidg, I wonder
what would be the downside to simply identifying any
old cons whose car & cdr point to itself to be _an_
empty list.

There wouldn't be just one empty list anymore. Two
empty lists need not be EQ, EQL, or even EQUAL.
But that's OK, isn't it, as long we have NULL, which
now becomes a more substantial predicate, rather than
one that determines if its arg is EQ to a particular
symbol?

Tim Bradshaw

unread,
Oct 31, 2002, 10:05:55 AM10/31/02
to
* Dorai Sitaram wrote:

> Extending your proposal by just a smidg, I wonder
> what would be the downside to simply identifying any
> old cons whose car & cdr point to itself to be _an_
> empty list.

> There wouldn't be just one empty list anymore. Two
> empty lists need not be EQ, EQL, or even EQUAL.
> But that's OK, isn't it, as long we have NULL, which
> now becomes a more substantial predicate, rather than
> one that determines if its arg is EQ to a particular
> symbol?

I think that the difference is probably that (a) it's nice to be able
to say that NIL is unique, and (b) there are probably substantial
efficiency gains. Lots of things that can now be implemented with a
single instruction (compare against known value) need at least
several.

One thing I wonder about is type. I'm not an implementor, but I sort
of assume a reasonable approach would be rather than having a special
typecode for NULL (which eats a code you could use for something else
in every object in the world), it's actually just an ordinary cons (or
whatever it is), and the typesystem does some fast (single
instruction) check for `is this thing actually NIL?'. In fact, in any
system where NIL is a distinct type (is '() a distinct type in
Scheme?), using your proposal would be kind of weird: firstly the act
of setting the car & cdr of a cons to point back to the object would
change its type (hmm...), and secondly the type check would be
nontrivial. I guess giving up the special type would be the right
approach here.

I'd like to know what implementations do, actually.

--tim


Frode Vatvedt Fjeld

unread,
Oct 31, 2002, 11:07:37 AM10/31/02
to
Tim Bradshaw <t...@cley.com> writes:

> I'd like to know what implementations do, actually.

Implementations need to take at least the following operations into
account: symbolp, null, consp, listp, and the symbol and list
accessors (car and cdr).

If you don't assign a tag to the null type, and let's say you give it
the cons tag, you have to explicitly check for the nil value in
symbolp (include nil), consp (exclude nil), and all the symbol
accessors. This can be a substantial penalty.

What's typically done, I believe, is that null is assigned a tag such
that it is congruent with the cons tag or symbol tag, modulo a simple
operation. I.e that

(= (logand <null-tag> <x>) <cons-tag>)

and

(= (logand <null-tag> <y>) <symbol-tag>)

That was a terrible explanation. An example is probably much
better. Assume three bits are assigned to type-tags.

cons-tag: #b010
symbol-tag: #b100
null-tag: #b110

Now, the type-predicate operations above can be implemented like this:

(symbolp <foo>): (= #b100 (logand (tag <foo>) #b101))
(listp <foo>): (= #b010 (logand (tag <foo>) #b011))
(consp <foo>): (= #b010 (tag <foo>))

These operations can typically be implemented quite efficiently in
machine-code, certainly so in x86.

Additionaly, it is important that the null-tag is congruent with the
cons-tag modulo 4 (on a 32-bit architecture), such that car and cdr
won't need a special case for nil (otherwise (car nil) and (cdr nil)
would become non-aligned memory accesses). Ideally, the same
relationship should be true for null-tag and the symbol-tag, but
that's impossible if you're restricted to 3 tag-bits. So you still
need to special-case nil in the symbol accessors.

I think there are even more reasons (than improved symbolp and consp)
to prefer a separate null-tag, but I can't think of what it is right
now.

--
Frode Vatvedt Fjeld

Thomas Bushnell, BSG

unread,
Oct 31, 2002, 3:47:50 PM10/31/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> Extending your proposal by just a smidg, I wonder
> what would be the downside to simply identifying any
> old cons whose car & cdr point to itself to be _an_
> empty list.

The following two things should be distinguished:

The list with no elements.
All circular lists with one element.

The pair whose car and cdr are itself is a special case of the latter,
it's a circular list with one element, which element is the list
itself.

Thomas

Kaz Kylheku

unread,
Oct 31, 2002, 4:09:03 PM10/31/02
to
Sander Vesik <san...@haldjas.folklore.ee> wrote in message news:<10360110...@haldjas.folklore.ee>...

No it doesn't. It depends on what output you want from CAR in response
to what inputs, to obtain some desired level of convenience.

Common Lisp has (car nil) => nil without at all defining nil to be
some recursive structure.

Continuing with an earlier analogy, when mathematicians decided that
(sqrt -1) made sense, they did not need to redefine the integer -1 as
the area of some square whose length is (sqrt -1).

Thomas Bushnell, BSG

unread,
Oct 31, 2002, 4:15:22 PM10/31/02
to
k...@ashi.footprints.net (Kaz Kylheku) writes:

> No it doesn't. It depends on what output you want from CAR in response
> to what inputs, to obtain some desired level of convenience.
>
> Common Lisp has (car nil) => nil without at all defining nil to be
> some recursive structure.

But the structure just is whatever car and cdr return.

I don't care what the *implementation* of nil is. It's the
*semantics* which are recursive here.

Dorai Sitaram

unread,
Oct 31, 2002, 5:44:15 PM10/31/02
to
In article <87hef2u...@becket.becket.net>,

I am unable to see why not distinguishing an [sic]
empty list and a circular list whose car is itself
is any more of a problem than not distinguishing
the empty list and a particular symbol?

Lists are fictions atop dotted pairs anyway -- anything
could be the piece of grit called the empty list around
the language, oyster-like, builds its lists. Choosing
a pair whose car and cdr are itself has the merit of
not requiring a special and/or arbitrary element,
but also of having empty lists themselves be pairs, so
we don't have the phenomenon of the empty list being
the one list that is not a pair.

William D Clinger

unread,
Oct 31, 2002, 10:12:17 PM10/31/02
to
Tim Bradshaw asked about the representation of NIL and ():

> I'd like to know what implementations do, actually.

This message was cross-posted to both comp.lang.lisp and comp.lang.scheme.

The tradeoffs are different in Common Lisp and in Scheme. In Scheme, the
empty list is just one of several miscellaneous objects that are usually
represented by a non-pointer bit pattern that can be synthesized as an
immediate operand. (Other miscellaneous objects include #f, #t, and
the end-of-file object(s).) This makes the NULL? predicate into a
single machine instruction, and does not make the PAIR? predicate or
(safe versions of) the CAR and CDR operations any slower.

In Common Lisp, an immediate representation for NIL makes NULL fast
without making PAIRP any slower, but CAR and CDR are likely to become
slower if they have to add extra code to handle the NIL case. Thus
NIL is more likely to be represented as a cons. To prevent NULL from
having to fetch the canonical value of NIL from memory, NIL is often
represented as a cons in low memory, so it both looks like a cons and
can also be synthesized as an immediate operation. As Frode Vatvedt
Fjeld explained, various tricks can be played to prevent ENDP, CONSP,
and SYMBOLP from becoming much slower: usually only one instruction
slower than they would be with Scheme's semantics.

Will

Adam Warner

unread,
Nov 1, 2002, 12:34:36 AM11/1/02
to
Hi Kaz Kylheku,

>> >> Otherwise you would have to define '() as the immutable pair which
>> >> both "car" and "cdr" slots pointed to itself - imho not nice at all.
>> >
>> > Why? I always thought that approach was rather elegant myself.
>>
>> Well, depends on whetever you want to treat '() as a simple constant or
>> a recursive structure.
>
> No it doesn't. It depends on what output you want from CAR in response
> to what inputs, to obtain some desired level of convenience.
>
> Common Lisp has (car nil) => nil without at all defining nil to be some
> recursive structure.
>
> Continuing with an earlier analogy, when mathematicians decided that
> (sqrt -1) made sense, they did not need to redefine the integer -1 as
> the area of some square whose length is (sqrt -1).

Another good example is #'concatenate 'string. This treats nil as an empty
string even though nil is not of type string: (stringp nil) ==> nil

I would find #'concatenate 'string slightly more convenient if it also
coerced characters to strings.

Regards,
Adam

Christophe Rhodes

unread,
Nov 1, 2002, 4:11:52 AM11/1/02
to
[ cll only ]

"Adam Warner" <use...@consulting.net.nz> writes:

> Hi Kaz Kylheku,


>
> > Continuing with an earlier analogy, when mathematicians decided that
> > (sqrt -1) made sense, they did not need to redefine the integer -1 as
> > the area of some square whose length is (sqrt -1).
>
> Another good example is #'concatenate 'string. This treats nil as an empty
> string even though nil is not of type string: (stringp nil) ==> nil

No it doesn't. It treats nil as an empty sequence, which it is, as it
is a list of no elements.

(concatenate 'string "a" nil "b") -> "ab"
(concatenate 'string "a" '(#\b #\c) "d") -> "abcd"

Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)

Duane Rettig

unread,
Nov 1, 2002, 5:00:01 AM11/1/02
to
ces...@qnci.net (William D Clinger) writes:

> Tim Bradshaw asked about the representation of NIL and ():
> > I'd like to know what implementations do, actually.
>
> This message was cross-posted to both comp.lang.lisp and comp.lang.scheme.

[ ... ]

> In Common Lisp, an immediate representation for NIL makes NULL fast
> without making PAIRP any slower, but CAR and CDR are likely to become
> slower if they have to add extra code to handle the NIL case. Thus
> NIL is more likely to be represented as a cons. To prevent NULL from
> having to fetch the canonical value of NIL from memory, NIL is often
> represented as a cons in low memory, so it both looks like a cons and
> can also be synthesized as an immediate operation. As Frode Vatvedt
> Fjeld explained, various tricks can be played to prevent ENDP, CONSP,
> and SYMBOLP from becoming much slower: usually only one instruction
> slower than they would be with Scheme's semantics.

Why one instruction slower? What assumptions are you making?

--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182

William D Clinger

unread,
Nov 1, 2002, 11:12:05 AM11/1/02
to
I wrote:
> As Frode Vatvedt
> Fjeld explained, various tricks can be played to prevent ENDP, CONSP
> and SYMBOLP from becoming much slower: usually only one instruction
> slower than they would be with Scheme's semantics.

Duane Rettig asked:


> Why one instruction slower? What assumptions are you making?

With the tag bits in Fjeld's example, on most architectures, ENDP and
CONSP would be just as fast as with Scheme's semantics, but SYMBOLP
would be one instruction slower. SYMBOLP would still be much faster
than it is in Larceny, so I obviously don't think one instruction is
very significant here.

As you know, there are lots of other clever representations, each
with its own advantages and disadvantages, so it's hard to generalize
about this sort of thing.

Will

Duane Rettig

unread,
Nov 1, 2002, 3:00:01 PM11/1/02
to
ces...@qnci.net (William D Clinger) writes:

> I wrote:
> > As Frode Vatvedt
> > Fjeld explained, various tricks can be played to prevent ENDP, CONSP
> > and SYMBOLP from becoming much slower: usually only one instruction
> > slower than they would be with Scheme's semantics.
>
> Duane Rettig asked:
> > Why one instruction slower? What assumptions are you making?
>
> With the tag bits in Fjeld's example, on most architectures, ENDP and
> CONSP would be just as fast as with Scheme's semantics, but SYMBOLP
> would be one instruction slower.

Not at all. If you take Frode's sample tagging as cons = #b010,
symbol = #b100, and nil = #b110, and if you consider imaginary low-level
"l" operators as functions which operate on the bit values of their
second arguments (rather than logand and =, which might be confused for
operations on each lisp object's _value_), then

(consp <foo>) => (l= #b010 (llogand #b011 <foo>))
(symbolp <foo>) => (l= #b100 (llogand #b101 <foo>))

each of which is two instructions.

Of course, there are faster ways of doing one or the other of these
operations, and on machines for which misaligned accesses are trapped,
the chosen access can be done with no instructions at all (i.e., if
cons access is chosen, then car/cdr can be done with a single instruction
with no testing beforehand).

> SYMBOLP would still be much faster
> than it is in Larceny, so I obviously don't think one instruction is
> very significant here.

Agreed.

> As you know, there are lots of other clever representations, each
> with its own advantages and disadvantages, so it's hard to generalize
> about this sort of thing.

I completely agree, and that is why I questioned the assumption in
your own generalization, which is not necessarily correct.

Adam Warner

unread,
Nov 1, 2002, 4:48:09 PM11/1/02
to
Hi Christophe Rhodes,

>> Another good example is #'concatenate 'string. This treats nil as an
>> empty string even though nil is not of type string: (stringp nil) ==>
>> nil
>
> No it doesn't. It treats nil as an empty sequence, which it is, as it
> is a list of no elements.
>
> (concatenate 'string "a" nil "b") -> "ab"
> (concatenate 'string "a" '(#\b #\c) "d") -> "abcd"

Thanks for fixing this misconception Christophe and Paul. I'm also pleased
to learn another way to include characters in a string concatenation
without having to call the string function: (string #\a) => "a"

Regards,
Adam

William D Clinger

unread,
Nov 1, 2002, 7:07:06 PM11/1/02
to
Duane Rettig wrote:
> Of course, there are faster ways of doing one or the other of these
> operations, and on machines for which misaligned accesses are trapped,
> the chosen access can be done with no instructions at all (i.e., if
> cons access is chosen, then car/cdr can be done with a single instruction
> with no testing beforehand).

As in Allegro Common Lisp on the SPARC, for example. Larceny uses the
same representation, and the only reason a CAR or CDR takes more than
one instruction in Larceny is that we wanted to avoid writing any trap
handlers.

> > As you know, there are lots of other clever representations, each
> > with its own advantages and disadvantages, so it's hard to generalize
> > about this sort of thing.
>
> I completely agree, and that is why I questioned the assumption in
> your own generalization, which is not necessarily correct.

I sit corrected. Thank you.

Will

Daniel Barlow

unread,
Nov 4, 2002, 1:21:34 PM11/4/02
to
Tim Bradshaw <t...@cley.com> writes:

> One thing I wonder about is type. I'm not an implementor, but I sort
> of assume a reasonable approach would be rather than having a special
> typecode for NULL (which eats a code you could use for something else

[...]


> I'd like to know what implementations do, actually.

This has been discussed before (on comp.lang.lisp), actually. In
amongst the meta-level "how's my politeness? Call 0800 22 55 33"
discussion, you can sieve a reasonable amount of information about NIL
handling in SBCL and Allegro CL from the archive at Google Groups

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=4it5po15f.fsf%40beta.franz.com&rnum=1&prev=/groups%3Fq%3Drettig%2Bnil%2Btag%2Bbarlow%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D4it5po15f.fsf%2540beta.franz.com%26rnum%3D1


-dan

--

http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources

Harri J Haataja

unread,
Nov 8, 2002, 7:58:15 PM11/8/02
to
Christopher C. Stacy wrote:
>>>>>> On 23 Oct 2002 14:03:03 -0700, Rich Demers ("Rich") writes:
> > Personally, I have been looking hard at APL (one of the most
> > powerful
> Yeah, APL was the language I loved before I discovered Lisp! Common
> Lisp has REDUCE; also check out the SERIES package by Dick Waters.

> The thing about APL, though, is that a lot of its beauty is in the
> syntax. Someone said, "APL is like a diamond, Lisp is like a ball of
> mud.", the point being that Lisp is capable of retaining its Lispish
> beauty while still absorbing other ideas, but APL's crystal lattice
> shatters when you try to add things to it.

The quote in my collection says:

"APL is a flawless diamond, perfect, symmetrical, an irreducible whole.
But add anything to it, and it's ruined. LISP is a bucket of mud; add
anything to it, and it's still a bucket of mud."

Also there:

You hear a gunshot, and there's a hole in your foot, but you don't
remember enough linear algebra to understand what happened.
-- Shooting yourself in the foot: APL

You spend so much time playing with the graphics and windowing system
that your boss shoots you in the foot, takes away your workstation,
and makes you develop in COBOL on a character terminal.
-- Shooting yourself in the foot: Smalltalk

Don't seem to have one for lisp or scheme.

--
: Bandwidth is no longer as expensive, so that's no excuse
: anymore.
It's not a matter of bandwidth any more, it's a matter of manners.
-- Robert A. Uhl and Dave Brown, on .sigs, in the Monastery

Donald Fisk

unread,
Nov 9, 2002, 2:18:47 PM11/9/02
to
Harri J Haataja wrote:

> You hear a gunshot, and there's a hole in your foot, but you don't
> remember enough linear algebra to understand what happened.
> -- Shooting yourself in the foot: APL
>
> You spend so much time playing with the graphics and windowing system
> that your boss shoots you in the foot, takes away your workstation,
> and makes you develop in COBOL on a character terminal.
> -- Shooting yourself in the foot: Smalltalk
>
> Don't seem to have one for lisp or scheme.

You shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds..

is the canonical Lisp version. The Scheme version is the same
with the addition

...but none of the other appendages are aware of this happening.

Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.

Steven T Abell

unread,
Nov 11, 2002, 10:37:16 AM11/11/02
to
> The epiphany was this: the "liberal" use of nil (as false, as end of
> list, as a nil-returning argument to CAR and CDR) is damn convenient.
> I made the decision to take advantage of `(car nil) => nil' and so
> forth in this program. The result was that the code accomplished
> more, with less work. I wound up with algorithms that were perfectly
> transparent, when read presuming that various values were not nil --
> but that also worked with nil. You could read the algorithm first,
> presuming not-nil, and get the gist. Then you could ask "what happens
> if such-and-such value is nil" and, much more often than not, the
> Right Answer simply fell out of the same algorithm. Gosh the RnRS
> authors are full of hot air in this area :-)

There is a similar stunt in Smalltalk
with an object that is like nil (is in fact subclass of UndefinedObject)
but accepts *any* message and quietly returns itself.
You can get an implementation of this from my website: look for "void".
This thing reduces many fairly complex algorithms to triviality
for the same reason as expressed above.

Steve
--
Steven T Abell
Software Designer
http://www.brising.com

In software, nothing is more concrete than a good abstraction.

It is loading more messages.
0 new messages