<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class="">how [does if(_)then(_)else(_)] distinguish between blocks & booleans. I said something like: "they see if theere's an ifTrueIfFalse method …”</blockquote><div class=""><br class=""></div><div class="">In minigrace, it’s worse than that. Not only is if(_)then(_)else(_) compiled inline, but the condition has to be the built-in class boolean, or inherit therefrom. If they aren’t, then we request them to apply themselves. We could in principle define if(_)then(_)else(_) in terms of ifTrue(_) and ifFalse(_), but I don’t want to do that because of the performance implications.</div><div class=""><br class=""></div><div class="">No one has yet filed a bug report saying that their re-implementation of Booleans didn’t work, so this is low on my list of priorities.</div><div class=""><br class=""></div><blockquote type="cite" class="">- method parameters should be mentioned in the spec (as "defs", i.e. unassignable). currently they aren’t<br class=""></blockquote><div class=""><br class=""></div>Yes, good catch. Who should add this?<div class=""><div class=""><br class=""></div><blockquote type="cite" class="">-- [[ ]] generics are "syntactic vinegar!!" (and the opposite of Gracefulness)<br class=""></blockquote><br class=""></div><div class="">Yes, indeed. I think that if your goal at the Grace Workshop was to discourage people from using Grace, you did a good job here. You could just as easily have used examples like this</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>max⟦Number⟧(x, y)</div><div class=""><br class=""></div><div class="">that would have looked good. If your emacs mode doesn’t yet replace [[ by ⟦ and ]] by ⟧ it should! </div><div class=""><br class=""></div><div class="">As I mentioned to you after the workshop, the way that Emerald dealt with type parameters was to distinguish syntactically (in the method definition) between explicit type parameters and implicit type parameters. This is from Emerald TR CRL 91-1</div><div class=""><br class=""></div><div class=""></div></body></html>