<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 28, 2010, at 11:59 AM, Jecel Assumpcao Jr. wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="background-color: rgb(255, 255, 255); position: static; z-index: auto; ">
<span style="display:none"> </span>
<div id="ygrp-text"><p>David Ungar wrote on Mon, 27 Dec 2010 18:50:51 -0800<br>
> On Dec 27, 2010, at 11:03 AM, Jecel Assumpcao Jr. wrote:<br>
> > [gripe - strings instead of objects for annotations]<br>
> <br>
> The string part was an easy implementation way to save space. Sure<br>
> storing objects would have been nicer.In fact they were changed back<br>
> and forth to objects in a way that was transparent. Annotations were<br>
> meant to be functional, so you could replace them but not change them<br>
> in place.That saves a lot of space. Remember that every slot in every<br>
> point object conceptually had its own annotation.<br>
<br>
Yeah, I didn't find a good alternative that would be reasonably space<br>
efficient. In the syntax, an annotation can span a number of slots. But<br>
in my designs I ended up just replicating the annotation for each slot<br>
separately (sharing when possible). Hmmmm.... just now I see that there<br>
is no reason to insist that maps be "flat". Just because the old object<br>
tree was replaced by annotation doesn't mean that the maps couldn't<br>
remain a tree. Then an annotation that only appears once in the source<br>
would only need to appear once in the runtime structure. Lookup<br>
performance is not as important in a compiler.<br></p></div></div></div></div></blockquote><div><br></div><div>yes</div><div><br></div><br><blockquote type="cite"><div style="background-color: rgb(255, 255, 255); position: static; z-index: auto; "><div id="ygrp-mlmsg" style="position:relative;"><div id="ygrp-msg" style="z-index: 1;"><div id="ygrp-text"><p>
<br>
> > [gripe - strings in the parameters of fail blocks]<br>
> Not sure what you mean here about Ole's extractor.<br>
<br>
It was easy for unrelated parts of the system to leak into the snapshot<br>
that was being extracted. One example is floating point for the<br>
factorial - there is one branch in the "power" function where the result<br>
could be a float (but it never is in this application) and so you get<br>
this huge overhead. The other place is string functionality: the<br>
factorial app just needs enough to print its results but due to code<br>
like<br></p></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><br><blockquote type="cite"><div style="background-color: rgb(255, 255, 255); position: static; z-index: auto; "><div id="ygrp-mlmsg" style="position:relative;"><div id="ygrp-msg" style="z-index: 1;"><div id="ygrp-text"><p>
<br>
+ a = ( |<br>
| asSmallInteger _IntAdd: a IfFail: [| :error. :name. |<br>
('badTypeError' == error) ifTrue: [<br>
" use double dispatching "<br>
a addSmallInteger: asSmallInteger ] False: [<br>
('overflowError' == error) ifTrue: [<br>
" retry after coercing to bigInts "<br>
asBigInteger + a asBigInteger ] False: [<br>
primitiveFailedError: error Name: name ]]]).<br>
<br>
you bring in stuff from String. Hmmmm..... this isn't nearly as bad as I<br>
remember since only '==' is being used. I thought there were lots of<br>
'beginsWith:' all over the place.<br></p></div></div></div></div></blockquote><div>At one point there may have been beginsWith:, and you could argue (and I would agree) that we would have been better off</div><div>making error objects to pass in to fail blocks. The issue there is *not* exceptions vs fail blocks, but rather</div><div>fail-blocks with string arguments vs fail-blocks with object arguments.</div><div><br></div><br><blockquote type="cite"><div style="background-color: rgb(255, 255, 255); position: static; z-index: auto; "><div id="ygrp-mlmsg" style="position:relative;"><div id="ygrp-msg" style="z-index: 1;"><div id="ygrp-text"><p>
<br>
> IMNSO, exceptions were a botch invented in languages without blocks <br>
> .I never liked the fact that control could invisibly branch off.For instance,<br>
> in a long method with exceptions, containing A; B; C;, you cannot count on<br>
> B being executed if A is executed. At least with fail blocks you can see<br>
> the branch in the return symbol in the block .I know that others like<br>
> exceptions. To me they are like iterators, both were workarounds for<br>
> languages without blocksthat became enshrined in our culture. I prefer<br>
> blocks. But that's just me.<br>
<br>
Actually, besides blocks you need non local returns to get the effect of<br>
exceptions and I think Self code is a great example of how to do this.<br>
But when I mentioned "exception objects instead of strings" I was just<br>
thinking of having something like<br></p></div></div></div></div></blockquote><div><br></div><div>Yes, of course. To me, "blocks" means blocks + block arguments + block locals + (what squeakers call closure semantics) + non-local return.</div><div>Sorry if that wasn't clear.</div><div><br></div><br><blockquote type="cite"><div style="background-color: rgb(255, 255, 255); position: static; z-index: auto; "><div id="ygrp-mlmsg" style="position:relative;"><div id="ygrp-msg" style="z-index: 1;"><div id="ygrp-text"><p>
<br>
traits errors = (| isBadType = false. isOverflow = false. .....<br>
|).<br>
badTypeError = (| parent* = traits errors. isBadType = true |).<br>
overflowError = (| parent* = traits errors. isOverflow = true<br>
|).<br>
<br>
This wouldn't really help in the '+' method above very much, but with a<br>
more complete hierarchy and some actual functionality in the error<br>
objects rather than them being simple tokens it could make a nice<br>
difference.<br></p></div></div></div></div></blockquote><div><br></div><div>Yup, these would be better to pass in to the fail blocks than strings.</div><br><blockquote type="cite"><div style="background-color: rgb(255, 255, 255); position: static; z-index: auto; "><div id="ygrp-mlmsg" style="position:relative;"><div id="ygrp-msg" style="z-index: 1;"><div id="ygrp-text"><p>
<br>
> > [tinySelf 0: special constant slot for object annotation]<br>
> That would allow object annotations to be accessed without reflection,<br>
> a change from what I considered tobe the appropriate base-level<br>
> semantics. It is simpler, though. It violates my preferred model of<br>
> object encapsulation.<br>
<br>
I agree, but in tinySelf 0 I had a bunch of "system slots" which you<br>
couldn't access by sending messages to their object but which showed up<br>
when talking to a mirror. The annotation slot was the only one I added -<br>
the rest (like the "hidden parent slots" in the block clones and block<br>
activations) were already part of the execution story for Self and I<br>
just reified them.<br></p></div></div></div></div></blockquote><div><br></div><div>So, slot types were always a tempting addition, but the problem was where to stop.</div><div>If some slots are hidden sometimes, why not have many kinds of hidden slots hidden at various times?</div><div>(This brings me right back to Us as a nice unification.)</div><div>And you still, as you said, have the problem of reifying slots; in other words the problem solved with slot annotations.</div><div><br></div><div>- David</div><div><br></div><br><blockquote type="cite"><div style="background-color: rgb(255, 255, 255); position: static; z-index: auto; "><div id="ygrp-mlmsg" style="position:relative;"><div id="ygrp-msg" style="z-index: 1;"><div id="ygrp-text"><p>
<br>
-- Jecel<br>
<br>
</p>
</div>
</div>
<!-- end group email -->
</blockquote></div><br></body></html>