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

[Jecel Assumpcao Jr]

> >[hated that first byte identified method "type"]
> 
> Well, for the evaluation function, you need to at least detect methods and
> blocks as one need to clone them and create an activation object.  How are
> these objects detected?  Currently, I'm checking whether a "self*" or a
> "(parent)*" slot exists, but that's also a hack.  I think, I'll introduce a
> flag in the map.

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

> >> (btw, whats the result of the empty block []?)
> >
> >It is just a block that when sent the 'value' message will
> >return the receiver of the method in which it lexically appears.
> 
> 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 wrote my parser from scratch, only using the grammar which was available.
> I've no fear of actually changing the grammar to improve it, if the
> language is still Selfish enough :-)

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.

> For example, I right now thinking about restricting the use of "*" to
> constant slots. Perhaps an unneeded restriction, but I think, it's easier
> to create Self system which is not only simulated in Smalltalk but which
> actually runs using the normal Smalltalk (Squeak) VM.

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.

> >I also found that the implicit self things really made the parser
> >a bit messy, but I like that enough that it is worth the hassle.
> 
> This actually is quite simple in my parser. When looking for a receiver, I
> expect either an identifier (which might be the special string "self" or
> not), a number, a string, a block or something with parenthesis. Everything
> else isn't accepted but nil is returned.
> 
> When finally creating a message send, a nil for the receiver expression is
> accepted as valid result. When looking for arguments, the nil is rejected
> and an error is issued.

Hmm - that is pretty good. Even if you do this in Self itself,
nil can never be receiver at parse time:

    nil printString

is parsed as

   selfSend 'nil'
   send 'printString'

so the nil will only appear on the stack at runtime.

> My problem was to detect resends.  When reading an identifier, the parser
> must scan the next token and if that's a period, the resendDot flag must be
> set. Otherwise, I'd to rewind and check for a normal message send.

My solution was way more ugly. I had to allow an N token lookahead
to get things to work. Just a bad hack - I first got things working
without the resend and then went back and tried to patch it to work.
The lexer had to have a two character lookahead, which I find rather
annoying.

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
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 once considered very seriously changing Squeak into a Self
implementation. With the Jitter "compiler", this would actually have
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).

-- Jecel


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