[Prev][Next][Index][Thread]

Re: Sealed as Source Annotation

In article <slrn8n6f6b.d82.mkg@asimov.lanl.gov>, mkgardne@cs.uiuc.edu 
wrote:

> On Fri, 14 Jul 2000 12:31:06 +1200, Bruce Hoult <bruce@hoult.org> wrote:
> >You will know, but I expect most Java programmers won't, that a sealed 
> >class in Dylan *can* be extended, but only within the same compile unit.
> 
> Actually, I did not know this. As I said in my previous post, all I
> know about Dylan came from reading (in 1992) Apple's 1992 book "Dylan:
> an Object-Oriented Dynamic Language". (I have largely been a sporadic
> lurker to Dylan since around 1994.) In Apple's book, the only mention
> of sealing concerned sealing classes (pg 94):
> 
>   seal /class/ => /class/
> 
>     seal makes the /class/ read-only and, in addition, new subclasses
>     cannot be created from the /class/.
> 
> Thus marking a class as sealed *did* prevent one from subclassing. I
> should read the latest DRM for a more up to date understanding. ;-)

Yes, a lot has changed since then.  For example, sealing was originally 
an operation, while it is now a declaration.


> >In the case of Dylan, a large part of the reason for having "sealing" is 
> >to enable more static, faster, code to be generated.  In order to do 
> >this, the compiler needs to know about the sealing while it is compiling 
> >any code that uses that class.  The greatest effect tends to come while 
> >compiling code that is in the same compile unit as the class itself, 
> >which means that the sealing has to happen in either the source file 
> >containing the class, or else perhaps in the source file which contains 
> >the import/export information for that module.
> 
> I will concede that separate compilation along with internal
> annotations may yield better code optimization than without the
> annotations but I am, as of yet, still undecided about the need for
> separate compilation [1]

I think that separate compilation is *vastly* overused.  But it's still 
necessary, no matter *how* fast computers get.  Do you want to have to 
compile all of Windows/MacOS/Linux/??? every time you compile "hello 
world", just because you're using the console I/O calls?  Do you even 
want to have to recompile your SQL database every time you change a 
program that uses it?

For many smaller libraries, I tend to agree that the process of 
importing and linking and so forth can take as long as or longer than 
simply compiling it each time.  In fact this might not even be dependent 
on computer speed, as systems ranging from the original Dartmouth BASIC 
to the WATFOR and WATBOL (I think) compilers on the PDP-11 to Turbo 
Pascal on CP/M were all fast systems that didn't do separate 
compilation.  Hell, Turbo Pascal even "recompiled" the program in order 
to map an error location in the executable back to the source location!

> [2] The Concurrent Aggregates (CA) compiler of the Illinois Concert
> system <http://www-csag.ucsd.edu/projects/concert.html> used whole
> program analysis, concrete type inference, flow analysis, and call
> site specific class/methond cloning

This is something that is intended to be in Dylan.  I believe that 
Functional Developer implements a programmer-hinted version of method 
cloning, and the Gwydion Dylan folks have in the (recent) past been 
discussing the best way to approach it.

-- Bruce
Follow-Ups: References: