<div dir="auto">IMO, it is usually fine to use the same selector with different meanings in different classes, its not always bad (IMO) and it makes code nicer to read and selectors easier to guess (for a new user). But when a subclass down the hierarchy redefines a message with a totally different meaning it is wrong (IMO). So the selectors we put in Object are kind of global, we cannot change the meaning of #printOn: or #= or #hash in one of our classes or things will break. That’s why it seems to me that its better to keep Object as small as possible and perhaps remove Object>>#value. I think we already talked about this tho, and we didnt remove it, was it because dependencies or events rely on it?</div><div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 14, 2024 at 19:24 Jaromir Matas via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hi, My understanding is that this: >> [Boris] The meaning of BlockClosure>>value and Association>>value have nothing in common! is the source of the confusion here; many definitions of #value are not "redefinitions" of Object>>value, they are often just simple accessors to instance variables called #value. Do the accessors "spoil the fun"? It's the kind of ("fake") polymorphism not available in most languages. Is it good or bad? And back to the original Mark's question (roughly) - why would it be bad to modify the compiler so that `cond ifTrue: a ifFalse: b` is treated the same way as `cond ifTrue: [a] ifFalse: [b]` i.e. optimized using bytecode jumps rather than sending #ifTrue:ifFalse: ? The divergence of b problem would disappear and we'd just have to be aware of the different semantics (#value send when used without [ ])... At any rate the current behavior of #ifTrue:ifFalse: feels inconsistent - depending on the "type" of arguments (or the syntactic form). A side-effect of "legitimizing" this approach would be one could start using (or "abusing"?) it like: a := Association key: 'one' value: 1. b := Association key: 'two' value: 2. x := cond ifTrue: a ifFalse: b and expecting x = 1 or x = 2. Too bad? Or one could assign blocks to a and b: a := [1]. b := [2] x := cond ifTrue: a ifFalse: b Is it bad to expect x = 1 or x = 2 ? I haven't noticed this inconsistency before Mark's question and I'm confused now - apologies in case the above doesn't make much sense :) Best, Jaromir On 14-Jun-24 11:16:28 AM, "Boris Shingarov via Cuis-dev" <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote: >> It is *expected* of blocks to understand *#value*. There is no concern; if >> you redefine *BlockClosure >> value*, the image will crash. > >Not sure what you mean here. The very first thing we do in PreSmalltalks >before we begin to build MachineArithmetic, libGDBs etc *is* we >redefine BlockClosure>>value (to auto-curry when invoked with the wrong >number of arguments). I am guessing what you mean is "redefine in a way >*incompatible* with the live system", but that's a characteristic of >how liveness is implemented in one particular Smalltalk, not of #value. > >> Right, it’s not a good idea to implement value in Object like this, it >> doesnt really generalize anything, I suggest we remove it. > >This, on the other hand, *will* break all hell, because now you are >doing computation in a category without products; and one immediate >consequence of that, is that Lawvere's elements-as-morphisms no longer >work. > >In more detail: > >A (Smalltalk) Object (which we might want to rename to Point or at least >SetElement if we were really radical) is a morphism from the product of >zero multiplicands to that (categorical) object. In other words, it is >an entity responding to 0-arg #value. So if I were on a radical course >to clean-up Object's protocol, #value and #yourself would be the two >messages I would keep. > >> x := cond ifTrue: a ifFalse: b. >> >> you might be in for a surprise > >Yes, exactly that. >So the problem with the above code is not that it's "twice slower" but >that it's simply not equivalent to the other one, due to order of >evaluation. On the one hand, in Smalltalk-80 there is no easy way to >tell whether a block/method is a function or a partial function or an >action; on the other hand, Smalltalk is applicative-order: so what if >say b diverges? Then > > 1 < 2 ifTrue: [a] ifFalse: [b] > >evaluates to ≅a, but > > 1 < 2 ifTrue: a ifFalse: b > >diverges. A similar trouble happens when b has a side effect. > >> a surprise if you happen to pass in a or b that implements value > >Hmm, yeah, that's an interesting one, let's see: > > x >= 0 ifTrue: a ifFalse: b (1) > >and let's assume x∈ℤ so x>=0 can't be anything other than a True >or a False (in unmodified Smalltalk-80 such as vanilla Cuis we don't >have unsaturated terms, so this works). So this endows ℤ with a >simple algebra of types: > > ℤ = ( (ℤ | [ :x | x>=0 ]) + (ℤ | [ :x | x<0 ) ) (2) > >so what we are doing in (1) is we are raising to the (2) degree, >and because (2) is a sum, (1) is a product of A×B (those are types >of a and b, even though Smalltalk-80 does not provide an explicit >notation for them). So we are just precomposing A>>value >and B>>value before the diagram for ifTrue:ifFalse:, and it HAS >to go from () to A / to B, and it can ONLY return self (per the >definition of "element"). Aha! So I would be inclined to guess >that we are just looking at plain bogus implementors of #value. >Let's look what we have in Cuis. Aha: Association>>value. Wow. >I can't think of a better example of what in a conversation some >time ago on this list we were calling "fake polymorphism". >The meaning of BlockClosure>>value and Association>>value have >nothing in common! > >... now this got me curious... what other interesting code lurks >among the implementors of #value... ha, MessageSend>>value >special-cases nil arguments vs empty arguments, this smells to >Lisp's generalized-false, and I wonder if we can normalize that? >Just for kicks and giggles, let's see where the special-case may be >used... oh, if I remove it, Cuis dies spectacularly opening a >million debuggers in WorldMorph>>runLocalStepMethods:... >would be interesting to probe how deep that rabbit hole goes... > >-- >Cuis-dev mailing list ><a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> ><a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> -- Cuis-dev mailing list <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div></div>