[self-interest] have to get this off my heart

[ungar at mac.com]

Interesting, your description of slot alternatives.
Lisp was the limit: only two slots, no names.
So bad that folks had to invent static typing for it.

Slot types do see problematic to me, but we did have argument slots in Self.
Tough choices.

- David



On Dec 31, 2010, at 11:03 AM, Jecel Assumpcao Jr. wrote:

> David,
> 
> > If the result could be a float, then there isn't much hope for an automatic
> > extractor to know it couldn't be, unless I don't understand your example.
> 
> Sorry, I have two very different examples of how stuff could "leak".
> There really was no relation between the float problem and the string
> parsing so I shouldn't have mixed them like that.
> 
> > At one point there may have been beginsWith:, and you could argue (and
> > I would agree) that we would have been better off making error objects
> > to pass in to fail blocks. The issue there is *not* exceptions vs fail blocks,
> > but ratherfail-blocks with string arguments vs fail-blocks with object
> > arguments.
> 
> Once again, the problem was with my description. I wanted to say what
> you just said but "exceptions" slipped in when trying to make an analogy
> of how the set of objects to be used as parameters might be organized.
> Many OO languages have a hierarchy of error and warning objects and I
> was thinking of something like that. I didn't mean to bring any other
> aspect of exceptions into the discussion (right now I am implementing a
> Squeak VM and am finding them very troublesome...)
> 
> > Yes, of course. To me, "blocks" means blocks + block arguments + block
> > locals + (what squeakers call closure semantics) + non-local return. Sorry
> > if that wasn't clear.
> 
> You were clear, but I added the comment about non local returns just in
> case someone else following the discussion isn't aware of the importance
> of that aspect. In particular, this is something that is used very
> rarely in Smalltalk-80 compared to in Self.
> 
> > ["system slots" in tinySelf 0]
> > 
> > So, slot types were always a tempting addition, but the problem was
> > where to stop.If some slots are hidden sometimes, why not have many
> > kinds of hidden slots hidden at various times?(This brings me right back
> > to Us as a nice unification.)And you still, as you said, have the problem
> > of reifying slots; in other words the problem solved with slot annotations.
> 
> I tried several different designs going to both extremes (lots of
> implicit information vs explicit) and it isn't easy to find a good
> balance. Perhaps there isn't one, and each situation a different choice
> is the best.
> 
> Just as an example, in one version of tinySelf 0 (done before Self 3
> came out, so this didn't have annotations) each slot had three words in
> the map: the name, a value and a code pointer. The system just called
> the indicated code with the supplied value (along with the receiver).
> The code for a constant slot (shared by all constant slots in the
> system) just returned the value, while the code for a data slot indexed
> the receiver. The code for a method that hasn't been compiled yet was
> the interpreter itself (the value is the bytecodes) while if it has been
> compiled it was the native code (the value is still the bytecodes, but
> that is ignored).
> 
> This Forth-like version has almost everything implicit. You can create
> many new types of slots, but there is no good wait of doing stuff with
> them other than their default behavior. The other extreme was to have
> each slot be a full object, which is hardly efficient in terms of memory
> but does make everything very explicit.
> 
> -- Jecel
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20110103/a93d75f6/attachment.html>