Hi anthony

I like the idea after there are definitive point I do not like but this 
is normal ;)
I think that we should have an architecture in place to let us play 
with the ideas
anyway. That's why we should form a group of people cleaning and making 
Squeak the right vehicule
for our dreams.

Stef

On Monday, April 14, 2003, at 09:10 AM, Anthony Hannan wrote:

> Hello fellow Squeakers,
>
> Below is a set of language features that I would like to see in a new
> language evolved from Squeak.  I call it Squik.  Many of these ideas
> have been discussed on this list before in one form or another,
> including private instance variables recently.  But I think as a whole
> this set of features makes for a nice modular and flexible language.  I
> plan on making this my next project, so I am very interested in getting
> your input first.  I know there are related projects: Class boxes,
> Traits, and Exupery compiler.  Maybe we should collaborate.
>
> Cheers,
> Anthony
>
> The text below can also be found on
> http://minnow.cc.gatech.edu/squeak/Squik.
>
> Squik: A proposal for a next generation Smalltalk
>
> Startup
>
> A Squik image file, like a Squeak image file, holds a heap of objects.
> The first object is a ImageHeader object whose first field points to a
> suspended context. The Squik boot program just loads a named squik 
> image
> file into memory and resumes its suspended context.
>
> No VM
>
> The boot program is not a VM; there is no VM. Any machine code needed 
> is
> implemented in library modules (dlls) that are loaded as objects when
> needed. For example, Interpreter is an object that responds to messages
> by calling the named function in its library module. These library
> messages replace primitive syntax.
>
> Interpreter is really the only object that requires machine code
> implementation. All other traditional VM behavior like the garbage
> collector can be implemented in the image. Raw pointer manipulation 
> must
> be added to the bytecode set, but only privleged classes will have
> access to them (Low-Level Operations are described later).
>
> No Instance Variables
>
> There are no instance variables. Instance fields can only be accessed
> via #instVarAt: and #instVarAt:put:. Of course, accessor methods may be
> implemented for convenience.
>
> No Global or Pool Variables
>
> There are no global or pool variables, only class variables. A global
> such as Array would be a class variable of ProtoObject, accessible to
> all subclass methods. Class variables can not be assigned to directly,
> they must be set using classVarAt:put:.
>
> Implicit Temporary Variable Declaration
>
> Temps are the only variables we can directly assign to. This allows us
> to interpret the first assignment to a temporary as its declaration as
> well. This eliminates the need for the temp var declaration list.
>
> Factories
>
> In Squeak, metaclasses serve both as behaviors and factories. In Squik,
> factories are separate from their instance behavior. Class variables
> reference other class factories, not the classes themselves. "Class"
> methods are implemented on the factories, which are arranged in a
> hierarchy that mirrors their corresponding classes. So, "Object" 
> returns
> a factory. "Object new" returns an instance. "Object instanceClass"
> return the class of Object instances. And "Object class" returns its
> class, ObjectFactory, a subclass of Factory and an instance of Class.
> There are no more metaclasses.
>
> Namespaces and Bound Selectors
>
> A class can only send messages of other class interfaces that are
> visible to it. An interface of a class is the set of its selectors that
> are new to the class and not inherited from any superclass. An 
> interface
> is visible to a class iff the class has the interface's factory in one
> of its class variables or inherited class variables. For example, a
> class A can send the message #do: to an object only if A has or 
> inherits
> a class variable that contains the Collection factory. For messages 
> sent
> to self, interfaces of its own class hierarchy are also visible.
>
> Selectors are more than just symbols. A Selector points back to the
> interface that it is a part of. The compiler binds message sends to the
> selector found in a visible interface. If more than one interface
> contains the same selector name than the compiler pops up the choice to
> the programmer. The programmer usually knows which interface he is
> targeting. The interface chosen is prefixed to the message, such as
> "block blockClosure.value".
>
> Multiple Inheritance
>
> To support polymorphism of bound selectors, mulitple inheritance has to
> be allowed. For example, if a subclass of Foo wants to simulate block
> behavior it will have to inherit from BlockClosure as well. Message
> conflicts are avoided since prefixes must be used in ambiguous
> situations. Also, since there are no instance variables, subclasses can
> reimplement accessors as it sees fit.
>
> If inst var fields are inherited from mulitple branches then some 
> fields
> must be repositioned in the subclass. The compiler will automatically
> override super methods that access fields directly (instVarAt:(put:))
> with copies containing the correct field positions in the subclass.
>
> Using Namespaces for Privacy
>
> As stated before a class can only send messages of interfaces visible 
> to
> it. To hide "private" methods from other classes, you can put them in a
> new subclass that is not visible to outside classes. The new subclass
> would only be visible to the original factory object so it can create
> instances of it. For example, SetPriv could be a new subclass of Set.
> Only SetFactory, the class of the Set factory, would hold SetPriv in a
> class variable so it can create instances of it in response to "Set
> new".
>
> Low-Level Operations
>
> The compiler translates messages sent to RawOp to special bytecodes 
> that
> directly manipulate data (no message sends). For example, to read the
> header word of an object A, you would write "header := RawOp longAt: 
> A".
> header would contain raw data which should never be the receiver of a
> message. It should only be used in arguments to other RawOp messages.
>
> The RawOp object and interface would only be visible to the garbage
> collector and other low level classes.
>
>
Prof. Dr. Stéphane DUCASSE
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do 
different? ...  especially if,
  by doing something different, today might not be your last day on 
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html