Squik language features
phil at runtime-collective.com
Mon Apr 14 16:59:16 UTC 2003
Could you tell a newbie what the rational for all these changes is?
On Mon, 14 Apr 2003, Michael van der Gulik wrote:
> 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