[self-interest] Squeak and Self (was: more syntax madness and Ultimardrev)

[Jecel Assumpcao Jr]

> Yes, but... well, I tried to immitate the implementation as described in
> the various papers and this can't have map classes, just simple chunks of
> map memory. 

Actually, one of the first words in a map is the C++ VTable - its
runtime type (class)!

> Therefore, I assumed there must be some undocumented map flags
> somewhere.  I don't want to build on OO technics where OO might not
> available - when creating a SELF VM out of Squeak, for example.

Squeak was OO the last time I checked ;-) but if you mean that you
want to use their Smalltalk to C translator, then you are right.

> I'm afraid, I like the "[self]"-idea better than replacing "[]" with
> "[(| |) _Clone]" (or even "[(| |)]".
> 
> But wait, what's the value of an empty method?  Can I define one?  I think,
> that's impossible, as a method object is only a method if and only if it
> holds some code.  Now when it's impossible to create an empty method, why
> should it be possible to create an empty block?

Good point. You can define an empty method, but then it is only a normal
object and not a method. Blocks look like methods, but they have a lot
more hidden stuff. Since Self allows most objects (including nil) to
understand the 'value' message, it wouldn't be such a hardship if empty
blocks were forbidden. But the way it is now is reasonable too.

> >[I wonder why they didn't use '::' for resends?]
> 
> Hm, "super::someMessage" could mean an undirected resend while
> "sma::someMessage" would resend someMessage to sma. "::" would become a new
> operator and it's the responsibility of the parser, to distinguish keywords
> from "::", which just needs a lookup buffer of 2.

Why can't the lexer handle this?

> >[DI is *very* rare]
> 
> This was my estimation.  Furthermore, if I allow direct resends to
> non-parent-slots, I've again get DI through the back door, haven't I?

You can't resend to non-parents, except by using some special
primitives. But in that case, your performance won't be very good
anyway, right?

> I browsed through the code and my first impression was (besides that I
> noticed that I don't know enough French to understand the comments) that
> the code needs refactoring.  I'd say you can reduce it to half the size.
> It would also a good idea to remove some 30 Globals which are added to
> Smalltalk and to separate UI and self system.

The French thing is a complication. It prompted me to eliminate
all Portuguese comments from my code a few years ago :-)

> You thought about simulating the old Squeak Smalltalk code on a new Self
> VM, didn't you?  I'd like to create a VM which can run both simultanly.
> I've no concrete idea yet how to do this, but it should be just an
> extension. The second step then would remove all Smalltalk-only stuff from
> the VM, hopefully reducing its complexity.

I would recompile old Squeak code to Self bytecodes. The Jitter
translator would generate the same threaded code as before, if all
went well. Here is the plan I came up with:

>1) subclass ObjectMemory and patch it so it deals with
>   Self style object and headers
>
>2) copy Compiler and patch it so it will parse Squeak
>   sources into Self objects and bytecodes (this
>   involves throwing out a lot of stuff, but see step 4)
>
>3) add a method to (1) so it will use (2) to convert
>   an existing Squeak image into Self format. Now we
>   generate a Selfish Squeak 1.31 image. An alternative
>   would be to use the SystemTracer, but I think that
>   might make me write a lot of code twice.
>
>4) subclass (1) by copying all the Jitter classes (if
>   this had been created as a decent framework, this
>   wouldn't be necessary. But it isn't a perfect world).
>   Modify the copied classes to translate from Self
>   bytecodes to thread code (this mostly means adding
>   back the code we threw out in step 2, but in very
>   different classes and execution time).
>
>5) translate (4) to C and compile it. We now would have
>   a Squeak that looks and works exactly like the original,
>   but is very different inside.
>
>6) copy Compiler yet again, and this time patch it to
>   translate from Self sources to Self bytecodes. Also
>   make a new inspector to deal with Self objects "natively".
>
>This can be released as a dual Self/Squeak system.
>
>7) fileIn and patch as much code from Self 4.0 as possible.
>   Patch Squeak morphs and stuff to allow more Self 4.0
>   code to be integrated into the system.
>
>This can be a second release, and be used as a very slow
>replacement for Self 4.0.

You can tell when this was from the reference to Squeak 1.31. The
need to copy the whole Jitter hierarchy to change it was particularly
bothersome, in my opinion. I don't normally miss multiple inheritance,
but this was a case when I did.

I never got very far into step 1, for I decided it would be nicer to
take the nearly working tinySelf1 and finish that instead. Good plan,
no I just have to do it :-)

But it would be great if someone were to create a Self/Squeak like
I described above.

Cheers,
-- Jecel


------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/self-interest
Free Web-based e-mail groups by eGroups.com