[self-interest] Re: more syntax madness and Ultimardrev

[Stefan Matthias Aust]

Jecel wrote:

>You could have several map subclasses and use that instead of a class.
>Blocks and Methods would do the right thing when you sent the exact
>same message to their map. If an object had a generic map instead,
>something different would happen. Checking for certain slots is a
>bad use of reflection (though both Self 4.0 and the current tinySelf
>use it. But tinySelf now uses Self 4.0 objects and maps - when it
>gets its own in the next version I will change to a more object oriented
>style).

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.  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.

>> Okay, so [] is really an abbreviation for [self].
>
>Oooops! I was very wrong, here. I just tested it and it seems that
>the empty block gets a new empty object installed as the "method"
>in the value slot. Sending the 'value' message to the block returns
>this empty object instead of the receiver of the lexical context.
>I'd better check these things the next time.

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?

>I wonder why they didn't use '::' for resends? They added a lot
>of Cisms to the language anyway, and it would be very familiar to
>C++ programmers. There would be no confusion with the normal ':'
>for keyword selectors and the '.' would have been left free for
>numbers and statement ends.

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.

>Having parent data slots (dynamic inheritance - DI) seemed like a good
>idea but was only used a in very simple example (tree nodes that
>change behavior if they are empty or not). The problem is that no
>current implementation handles this very well. I have a solution,
>but if you eliminate DI you won't miss much.

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?

>In another message you mentioned that it looked easier to port
>Ultimardrev to Squeak and mentioned some of the difficulties. I
>agree that ParcPlace Smalltalk probably changed enough, specially
>in the UI classes, to make things worse than Squeak. You might
>consider if all this effort will be worth it, though. Self 1.0

I gave up after the Squeak VM crashed the second time.  I always forget
that I cannot proceed after changing a methods.  This is really annoying. I
managed to file in all code and even made the SelfParser run that
SelfObject could initialize all globals. 

>was fun, but quite different from 4.0 in several aspects. Even
>if you don't get it running, I thought that looking that the sources
>of Ultimardrev might help give you some ideas.

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.

>I once considered very seriously changing Squeak into a Self
>implementation. With the Jitter "compiler", this would actually have

I'm very interested in this idea, too. Well, perhaps with a slightly
different emphasize.

>a performance very close to the current Squeak. And with a little
>care, it could be nearly 100% compatible with the Squeak Smalltalk
>code (see Mario Wolczko's GNU Smalltalk port to Self 4.0 for an
>example of what it possible).

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.


bye
--
Stefan Matthias Aust  //  Are you ready to discover the twilight zone?

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