<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Christoph, Hi Marcel,</div></div><div><br></div><div class="gmail_default" style="font-size:small">apologies about the font size mismatches...</div><div class="gmail_default" style="font-size:small"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 23, 2022 at 2:25 AM Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="m_7665205952880539836__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr">
Hi Christoph --<div><br></div><div>> <span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"> </span><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">IMHO, it unnecessarily complicates the simple Smalltalk syntax.</span><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"> [...]</span></div><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">Nah, this is just a tooling change, not a syntactical one. </span></div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">+1</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="m_7665205952880539836__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">Yes, I would like to have this info skipped for #isNil as well. Note that o</span><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">ne should not use #ifNotNilDo: anymore.</span></div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Good idea. I'll include it.</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="m_7665205952880539836__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">Best,</span></div><div><span style="font-family:Calibri,Helvetica,sans-serif;font-size:16px">Marcel</span></div><div></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">
<p style="color:rgb(170,170,170);margin-top:10px">Am 23.11.2022 11:00:43 schrieb Thiede, Christoph <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de" target="_blank">christoph.thiede@student.hpi.uni-potsdam.de</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<div dir="ltr">
<div id="m_7665205952880539836x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p>Hi Eliot, hi all,</p>
<p><br>
</p>
<p>I'm skeptical about this change, as it creates or expands a special role of the selectors #ifNil:, #ifNotNil:, and their combinations. IMHO, it unnecessarily complicates the simple Smalltalk syntax. While I know and sometimes dislike these UndefinedVariable
notifications, too, I don't know whether differentiating them by the selector is the right strategy to improve this situation.</p></div></div></div></blockquote></div></blockquote><div class="gmail_default" style="font-size:small">Please indulge me. It's f***ing irritating to be told by the compiler that as temp var appears to be uninitialized when one is intentionally using the fact that temps are initialized to nil. And that temp vars are initialized to nil is a) essential knowledge and b) a good thing (no uninitialized local variables a la C, a sensible value to initialize a variable with).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">BTW, I find it more than sad (a little alarming in fact) that someSmalltalkers don't know that the value of several conditionals that take blocks is nil when the condition doesn't select the block. e.g. false ifTrue: [self anything] is nil. I see "expr ifNotNil: [...] ifNil: [nil]" and it strikes me as illiterate. I recently visited code written by a strong programmer who open coded a lot of point arithmetic, decomposing e.g. a * b into (a x * b x) @ (a y * b y). It's bad. It gradually degrades the code base in that it isn't always an exemplar of best practice, </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="m_7665205952880539836__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px"><div style="font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div id="m_7665205952880539836x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p><br>
</p>
<p>Consider the following examples:</p>
<p><br>
</p>
<p></p>
<div></div>
<div></div>
<div>| a b c d e f g h |</div>
<div>a ifNil: [a := 1].</div>
<div>c := b.</div>
<div>c ifNil: [c := 3].</div>
<div>#(1 2 3) sorted: d.</div>
<div>e := 5.</div>
<div>(e isNil or: [f isNil]) ifTrue: [e := f := 6].</div>
<div>g perform: #ifNotNil: with: [b := g].</div>
<div>h ifNotNilDo: [h := 8].</div>
<div></div>
<div></div>
<br>
<p></p>
<p>How would you explain to a naive Smalltalker which of these variables will be marked as undefined at this point and why? (Of course, you can explain it by pointing to the implementation, but I think that's a significantly less intuitive explanation than
just saying "you must declare any variable before using it".)</p></div></div></div></blockquote></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">No. It's a hard-and-fast rule that all temp vars are initialized to nil. And initializing a variable (to other than nil) is done by assigning it. In the above a through h are declared within the vertical bars.n They are initialized in the assignments. I want a warning for the usage of b in "c := b", "d" in "#(1 2 3) sorted: d", g in "g perform: #ifNotNil: with: [b := g]". I *don't* want to be told about a in "a ifNil: [a := 1]", c in "c ifNil: [c := 3]", or e & f in "(e isNil or: [f isNil]) ifTrue: [e := f := 6]". I never want to see "ifNotNilDo", ever ;-)</div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">(* note that a couple of years back we fixed a bad bug in the compiler where block local temps were not (re)initialized to nil on each iteration, leaking their values from previous iterations, breaking the "all temp vars are initialized to nil rule, and revealing implementation details in the compiler's inlining of to:[by:]do: forms) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="m_7665205952880539836__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px"><div style="font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div id="m_7665205952880539836x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p>This behavior leads to a mental model that disambiguates between null and undefined similar to JavaScript which I never have found helpful.</p></div></div></div></blockquote></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">I don't see how that applies. Smalltalk has no undefined. It has nil & zero, and these values are used to initialize any and all variables. This is not an artifact of the implementation. It is a fundamental part of the language design. It results in no dangling referents or uninitialized variables. The language used in Parser>>#queryUndefined is problematic. It should be "unassigned", not "undefined". There is nothing undefined about these variables. But they are indeed unassigned. In some cases (see my i=diomatic implementation of subsequences: and substrings) this can (and *should*) be used to advantage. And all Smalltalk programming courses should explain that variables are always initialized (either to nil or zero, & hence by extension 0.0, Character null, Color transparent, et al), and may need assignment before their referents get sent messages.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I see the same kind of sloppiness in people not knowing that conditionals that take blocks typically evaluate to nil when the condition doesn;t select the block. So always "expr ifNotNil: [...]", never "expr ifNotNil: [...] ifNil: [nil]", or "expr ifNotNil: [...] ifNil: []". I recently cleaned up code by as string programmer who had open coded point arithmetic (e.g. a * b written as (a x * b x) @ (a y * b y) ). This is really bad: it's exemplifying poor practice, it's verbose, it takes away at least as much understanding as it conveys, it leads to more difficult to manage code.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If we fail to teach the language properly we start on a slippery slope to duplication (which is an awful evil, leading to much increased maintennance effort, and brittleness), and rendering perfectly good, well thought-out idioms mysterious. It;'s not like Smalltalk has a lot of rules; the number, compared to C & C++ et al is tiny. And terseness has not just aesthetic benefit, but real practical benefit in terms of readability & maintainability.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="m_7665205952880539836__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px"><div style="font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div id="m_7665205952880539836x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p>Also, with this change, the compiler leaks the default value of any temporary variable, which we previously were able to hide at least partially.</p></div></div></div></blockquote></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">But that is a MISTAKE!! The language designers didn't arrange for temps to be initialized to nil just because that's the only default. They did it to ensure that there is no such thing as an uninitialized variable in Smalltalk. That's why nil ids an object, with a class, not just nil. That's why nil ~~ false. It's carefully thought out and not just some artifact of the implementation. And that rationale (read the blue book carefully) and its implications, should be taught/learned/known, and especially exemplified by the core code of Squeak trunk, and hence supported by the compiler.</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="m_7665205952880539836__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px"><div style="font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div id="m_7665205952880539836x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p>In many cases, I think explicitly setting a temporary variable to nil before it is initialized within some non-trivial conditional complex would be more explicit, thus more readable, and something which we should generally encourage programmers to do.</p></div></div></div></blockquote></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">I disagree. You're advocating for absurdities such as</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"> | colors |</div><div class="gmail_default" style="font-size:small"> colors :=- ColorArray new: 256.</div><div class="gmail_default" style="font-size:small"> colors atAllPut: Color transparent</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This is the kind of thinking that leads to cycling wearing American Football clothes. It won't keep you from being run over by a truck, but it'll make you so slow and reduce your peripheral vision so much, not to mention give you a false sense of security, that you'll be much more likely to be run over by a truck...</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="m_7665205952880539836__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px"><div style="font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div id="m_7665205952880539836x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p><span style="font-size:12pt">Looking forward to your opinion!</span><br></p></div></div></div></blockquote></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">:-) Hope I'm not too strident :-)</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="m_7665205952880539836__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px"><div style="font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div id="m_7665205952880539836x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p><span style="font-size:12pt">Best,</span><br></p>
<p>Christoph</p>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_7665205952880539836x_divRplyFwdMsg" dir="ltr"><span style="font-family:Calibri,sans-serif;color:rgb(0,0,0)"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von <a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> <<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>><br>
<b>Gesendet:</b> Mittwoch, 23. November 2022 04:10:30<br>
<b>An:</b> <a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a>; <a href="mailto:packages@lists.squeakfoundation.org" target="_blank">packages@lists.squeakfoundation.org</a><br>
<b>Betreff:</b> [squeak-dev] The Trunk: Compiler-eem.480.mcz</span>
<div> </div>
</div>
</div>
<span style="font-size:10pt"><span style="font-size:10pt">
<div>Eliot Miranda uploaded a new version of Compiler to project The Trunk:<br>
<a href="http://source.squeak.org/trunk/Compiler-eem.480.mcz" target="_blank">http://source.squeak.org/trunk/Compiler-eem.480.mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: Compiler-eem.480<br>
Author: eem<br>
Time: 22 November 2022, 7:10:27.324796 pm<br>
UUID: 3e5ba19e-c44a-4390-9004-de1246736cbc<br>
Ancestors: Compiler-eem.479<br>
<br>
Do not warn of an uninitialized temporary if it is being sent ifNil: or ifNotNil:.<br>
<br>
=============== Diff against Compiler-eem.479 ===============<br>
<br>
Item was changed:<br>
----- Method: Parser>>primaryExpression (in category 'expression types') -----<br>
primaryExpression <br>
hereType == #word <br>
ifTrue: <br>
[parseNode := self variable.<br>
+ (parseNode isUndefTemp<br>
+ and: [(#('ifNil:' 'ifNotNil:') includes: here) not<br>
+ and: [self interactive]])<br>
+ ifTrue:<br>
+ [self queryUndefined].<br>
- (parseNode isUndefTemp and: [self interactive])<br>
- ifTrue: [self queryUndefined].<br>
parseNode nowHasRef.<br>
^ true].<br>
hereType == #leftBracket<br>
ifTrue: <br>
[self advance.<br>
self blockExpression.<br>
^true].<br>
hereType == #leftBrace<br>
ifTrue: <br>
[self braceExpression.<br>
^true].<br>
hereType == #leftParenthesis<br>
ifTrue: <br>
[self advance.<br>
self expression ifFalse: [^self expected: 'expression'].<br>
(self match: #rightParenthesis)<br>
ifFalse: [^self expected: 'right parenthesis'].<br>
^true].<br>
(hereType == #string or: [hereType == #number or: [hereType == #literal or: [hereType == #character]]])<br>
ifTrue: <br>
[parseNode := encoder encodeLiteral: self advance.<br>
^true].<br>
(here == #- and: [tokenType == #number and: [1 + hereEnd = mark]])<br>
ifTrue: <br>
[self advance.<br>
parseNode := encoder encodeLiteral: self advance negated.<br>
^true].<br>
^false!<br>
<br>
<br>
</div>
</span></span>
</div></blockquote></div><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>