Path: utzoo!attcan!uunet!aplcen!samsung!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk Implementation Queries.
Message-ID: <80500081@p.cs.uiuc.edu>
Date: 2 Dec 89 17:38:36 GMT
References: <1121@<1989Nov30>
Lines: 51
Nf-ID: #R:<1989Nov30:1121:p.cs.uiuc.edu:80500081:000:2770
Nf-From: p.cs.uiuc.edu!johnson    Dec  1 15:09:00 1989


James Noble's questions about Smalltalk implementation are much
too interesting to make private, and there is not that much
traffic in comp.lang.smalltalk.

The little Smalltalk definition of cascades are definitely nonstandard
and, in my opinion, wrong.  They can be replaced easily by parenthesis.

Blocks are becoming more and more like Scheme closures.  It isn't hard
to make blocks fully reentrant and use standard static linkages.  I
think that block temporaries are a good idea.  They are especially
useful for parallel programming (though that probably isn't important
for many people).

Literals are a tough problem.  The only literals that real pose a problem
are array literals, because you can't change numbers or symbols and rarely
change strings.  In my opinion, Smalltalk would be greatly improved if
it were imposible to modify literals.  One way to do this is to make a
class LiteralArray that does not have the at:put: method.  This would be
a compromise between the current situation and copying literals every
time they appear in a program.

If I were you I would certainly put in multiple inheritance.  However,
I would not use the one described in [Borning].  Nobody really knows
the best way to do multiple inheritance, so if you are creative you
might invent something useful.  It is used so rarely that you would not
introduce much incompatibility problems by doing it differently.

The class library is another matter.  If you want to use other people's
programs then you will have to make your class library very close to
the standard.  Unfortunately, there is no real standard.  If all you
want is something with the same look and feel as Smalltalk then there
is no reason why you have to be compatible at the class level.  Any of
the classes could be redesigned if you are only interested in the
spirit of the language, none of them should be altered if you want your
systems to run other people's programs without a lot of hastle.  However,
it will be virtually impossible for you to be compatible unless you just
reuse the class libraries, so perhaps it is not even worth trying.

I think it would be very neat to add support for one-of-a-kind objects
and use this to try to make metaclasses easier to understand.  However,
if you aren't careful then your language will look just like Self.
Not that this is bad, it just won't be new.

Multiple global namespaces (a.k.a. packages) will be seen to be very
important in the future.  It is easy to implement this feature in
Smalltalk-80.  I had a student stick classes in pools as a several
week class project, and it worked out very well.  The pools then act
as the packages.  It probably wouldn't be hard to do something nicer.

Ralph Johnson -- University of Illinois at Urbana-Champaign