Squik language features

Michael van der Gulik mikevdg at hetnet.nl
Mon Apr 14 07:40:17 UTC 2003

Hi Anthony.

Interesting idea. I have a few questions though:

* Will it be fast? Are you going to be compiling to machine code, or 
interpreting? Or both?

* Will it be secure / modular / sandboxed? You mention Namespaces; does 
that mean that the machine would be safe to run foreign code? Is this a 

Also, a more general question. There are no instance variables and you 
can only assign to them by doing #instVarAt:...
Now, this is a great idea, but will you be making "a := 2." shorthand 
for "myObject #instVarAt: 4 put: 2."?

What happens in Squeak? I see instVarAt:put: in class Object, so does 
that mean that ":=" get's turned into a "instVarAt:put:" by the 
compiler? Is ":=" considered to be a message? Much in the same way, is 
accessing an instance variable turned into an "instVarAt:" by the 
compiler? This behaviour would be very handy; you could do useful things 
like adding pre- and post- conditions to instance variable usage by 
overriding these methods.


p.s. congrats for getting into Georgia Tech!

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.
>The text below can also be found on
>Squik: A proposal for a next generation Smalltalk

More information about the Squeak-dev mailing list