[self-interest] Re: The initial Self World

Thu May 20 21:39:55 UTC 1999

One quick comment:
_AddSlots: ( | lobby = 0 _AsObject | )
(N.B.: the ObjectID of the lobby is not necessarily 0, remarkably if the first
expression you type returns an error. To find out the ObjectID of the lobby
type:
self
on the VM# prompt.)
and
_AddSlots: ( | lobby = self | )
can make the lobby selector visible in the empty world.
Also see my comments below.
Regards,
Douglas

jecel at lsi.usp.br wrote:

> > I somehow managed to get Self 4.0 to run on a SPARCstation here at my
> > workplace. Now I can understand better a lot of things that I knew in
> > theory, but couldn´t feel in practice.
>
> It is great to use this list to talk about using Self instead of
> just implementing it. While I found Self just what I had expected
> from reading about it, it seems that most people are very surprised
> by the difference between practive and theory.

That is, I guess, because most people aren´t used to the object-oriented style
of thinking and acting. I wasn´t, and I hadn´t got the slightest Smalltalk
background when I first heard of Self.

>
> > I am experimenting a little with the empty Self world, that is the bare
> > VM. I tried to do the following:
> > self _AddSlots: ( | prims = _PrimitiveList . credits = _Credits | )
>
> This would have worked just as well if you eliminated the initial
> "self" in the expression. When a receiver is missing in a Self
> expression, self is implied. There is a difference when this is
> used inside a method: "x: 2" will send "x:" to self but start the
> message lookup with the method's local slots, while "self x: 2"
> will also send "x:" to self but will look it up starting the with
> receiver's slots. Note that the message receiver is always a parent
> of the executing method (through the "self*" slot).

Perhaps that is because I was adding slots to the lobby, which coincidently is
the evaluation context of the VM# prompt (anything one types on the VM#
promptis evaluated as if it were a slot of the lobby, right? Or else, anything
one types on the VM# prompt turns into a message sent to the lobby).

>
>
> > This was successful and added the two slots to the lobby (strangely one
> > cannot access the lobby with the "lobby" selector, but with "self"
> > because the VM# prompt evaluation context is the lobby).
>
> This is because the "lobby" slot is only added to lobby when you
> file in "init.self" to create a non empty world.

I suspected. So the only reason we can get to the lobby is that it is
hardwired in the VM implementation as the evaluation context of the empty
world. Of course, there are some objects that are returned by some primitives
(like _PrimitiveList, for example, which returns a vector).

>
>
> > Unfortunately, what I wanted to do was to invoke the credits slot as a
> > method slot, so that it would print the credits. Instead, the result was
> > that it only kept the returned object (´Thanks!´) on the slot.
>
> You created a constant slot which has as its value the result of
> evaluating the expression "_Credits" in the context of the lobby.
> I found it strange that sending _Credits to the lobby just returned
> the string 'Thanks', but I tried it and you are right - it has a
> side effect of printing a lot of stuff on the terminal, but the
> result is just this short string.

Perhaps this is the reason why the credits are not returned into an object
that "the hand" can grab and manipulate. Only the Thanks! string is an object.

>
>
> > Then I
> > tried another idea:
> > self _AddSlots: ( | prims = _PrimitiveList . credits = [ _Credits ] | )
> > Yes, a block. Perhaps I could invoke the primitive with "self credits
> > value".
> > Unfortunately it didn´t work. It only complained about non-lifo blocks
> > invocation after the block´s enclosing scope has returned.
>
> This is a limitation that Self has but Smalltalk doesn't. After the
> expression that created a block has finished executing, you can no
> longer use that block because that doesn't make sense with a simple
> stack implementation. Smalltalk uses a linked list of context objects,
> this isn't a problem (except for the Smalltalk implementor ;-)
>
> Note that what Smalltalk does with non LIFO (last in, first out) blocks
> you can do in Self just as well by creating lots of anonymous little
> objects (something you can't do in Smalltalk).
>
> > Does anyone know a workaround to really INVOKING a primitive from a slot
> > of the lobby (or generically any object)?
>
> Please note that your problem has nothing to do with primitives. Try:
>
>   _AddSlots: ( | credits = ( _Credits ) | )
>
> Now credits is a constant slot that has a method that invokes the
> primitive as its value, instead of the result of invoking the primitive.
> You can type "self credits" or simply "credits" and get what you
> want.
>

Yeah, it works! So the difference between what I did and your suggestion is
that I assigned **the result of evaluating** _Credits to my constant credits
slot while you put the primitive **inside the code for an object**, so that
whenever you send a credits message to the lobby it will **execute** the
primitive again. Great! This is the kind of thing I would never understand
without running Self and doing the experiment myself.

>
> Please compare the following:
>
>    _AddSlots: ( | cvec = vector _Clone: 3 Filler: 9 | )
>
>    _AddSlots: ( | nvec = (vector _Clone: 3 Filler: 9) | )
>
>    cvec _At: 1 Put: 5
>
>    nvec _At: 1 Put: 5
>
> It sure looks like they are the same so far, doesn't it? But this
>
> VM# cvec
> <20>: ( | parent* = <1>. | object array: {9, 5, 9} )
> VM# nvec
> <22>: ( | parent* = <1>. | object array: {9, 9, 9} )
> VM#
>
> shows that there is a difference. nvec is a method which returns
> a new vector every time it is invoked, while cvec is a constant slot
> which returns the same vector every time it is invoked. I was going

> to do this without a primitive to show that it is a different issue,
> but in the empty world there are no non-primitive methods...
>
> -- Jecel
>
> ------------------------------------------------------------------------
> Tired of waiting for your stock quotes and charts to load?
> StockMaster is super-fast for quotes, charts, news, and portfolios.
> Markets don't wait, why should you?  http://clickhere.egroups.com/click/69
>
> eGroups.com home: http://www.egroups.com/group/self-interest
> http://www.egroups.com - Simplifying group communications

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/self-interest
http://www.egroups.com - Simplifying group communications