CL macros and such ... [Re: [Q] CCodeGenerator and inlining]]

agree at carltonfields.com agree at carltonfields.com
Fri Jan 21 23:07:46 UTC 2000


> There _is_ a way to nail down a lot of Smalltalk and even do a lot of
> static inlining at compilation time (though you would > normally only want
> to do this for application delivery or embedded systems). > This is to use
> a "closed world" model of compilation. Basically you make the > assumption
> that all of the current code is final and the values of most of the
> global, class, and pool variables will not change and start crunching.

I think the point made by others is that, in Smalltalk, this is almost never a reasonable assumption. Late binding is a fundamental feature of Smalltalk.

It is true that we can always change a language to be more like others, but then we should quite directly confront the question: what are the specific advantages; what are the specific costs?  Let's put those on the table and make a decision.  Smalltalk is not CL, neither are C++.  There are certainly advantages to each, but when developing language hybrids, we should make sure that what we are doing is not to simply write in one language using the syntactic sugar of another -- so doing, we can lose the best features of each.

Let's not speak in generalities, and allusions to advantages "known" by others -- let's get down to specifics.  What can't we presently do in Squeak that can be done in CL?  What is proposed to enhance the language?  What are the costs related to making the change?  Does the benefit outweigh the costs?

Obviously, the step of weighing is highly subjective, but the rest of the analysis is not.  Let's get down to brass tacks, otherwise we are just devolving into another abstract and probably unproductive language jihad.





More information about the Squeak-dev mailing list