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