[squeak-dev] The Trunk: Compiler-eem.480.mcz

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Wed Nov 23 10:41:42 UTC 2022


Hi Marcel,


> Nah, this is just a tooling change, not a syntactical one.


Yes, but the compiler is one of the main tools (maybe *the* main tool?) for learning about Smalltalk syntax. If we encode certain idioms/patterns in it, users may learn them as a syntactical part of the language, may they not?


> Yes, I would like to have this info skipped for #isNil as well. Note that one should not use  #ifNotNilDo: anymore.


So build a comprehensive list of "nil-aware selectors"? I don't know ... What would be about #notNil? #isEmptyOrNil? What if Etoys also added a #test:ifNil:ifNotNil: besides the existing #test:ifTrue:ifFalse:? By encoding such information in the compiler, we make the language design less flexible. I feel reminded of the recent debate on keyboard shortcuts for ifFalse:/ifTrue: in the SmalltalkEditor. :-)


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 23. November 2022 11:24:51
An: squeak-dev
Betreff: Re: [squeak-dev] The Trunk: Compiler-eem.480.mcz

Hi Christoph --

>  IMHO, it unnecessarily complicates the simple Smalltalk syntax.  [...]

Nah, this is just a tooling change, not a syntactical one.

Yes, I would like to have this info skipped for #isNil as well. Note that one should not use  #ifNotNilDo: anymore.

Best,
Marcel

Am 23.11.2022 11:00:43 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:

Hi Eliot, hi all,


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.


Consider the following examples:


| a b c d e f g h |
a ifNil: [a := 1].
c := b.
c ifNil: [c := 3].
#(1 2 3) sorted: d.
e := 5.
(e isNil or: [f isNil]) ifTrue: [e := f := 6].
g perform: #ifNotNil: with: [b := g].
h ifNotNilDo: [h := 8].


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".)

This behavior leads to a mental model that disambiguates between null and undefined similar to JavaScript which I never have found helpful.

Also, with this change, the compiler leaks the default value of any temporary variable, which we previously were able to hide at least partially.

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.


Looking forward to your opinion!


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von commits at source.squeak.org <commits at source.squeak.org>
Gesendet: Mittwoch, 23. November 2022 04:10:30
An: squeak-dev at lists.squeakfoundation.org; packages at lists.squeakfoundation.org
Betreff: [squeak-dev] The Trunk: Compiler-eem.480.mcz

Eliot Miranda uploaded a new version of Compiler to project The Trunk:
http://source.squeak.org/trunk/Compiler-eem.480.mcz

==================== Summary ====================

Name: Compiler-eem.480
Author: eem
Time: 22 November 2022, 7:10:27.324796 pm
UUID: 3e5ba19e-c44a-4390-9004-de1246736cbc
Ancestors: Compiler-eem.479

Do not warn of an uninitialized temporary if it is being sent ifNil: or ifNotNil:.

=============== Diff against Compiler-eem.479 ===============

Item was changed:
  ----- Method: Parser>>primaryExpression (in category 'expression types') -----
  primaryExpression
         hereType == #word
                 ifTrue:
                         [parseNode := self variable.
+                        (parseNode isUndefTemp
+                         and: [(#('ifNil:' 'ifNotNil:') includes: here) not
+                         and: [self interactive]])
+                                ifTrue:
+                                        [self queryUndefined].
-                        (parseNode isUndefTemp and: [self interactive])
-                                ifTrue: [self queryUndefined].
                         parseNode nowHasRef.
                         ^ true].
         hereType == #leftBracket
                 ifTrue:
                         [self advance.
                         self blockExpression.
                         ^true].
         hereType == #leftBrace
                 ifTrue:
                         [self braceExpression.
                         ^true].
         hereType == #leftParenthesis
                 ifTrue:
                         [self advance.
                         self expression ifFalse: [^self expected: 'expression'].
                         (self match: #rightParenthesis)
                                 ifFalse: [^self expected: 'right parenthesis'].
                         ^true].
         (hereType == #string or: [hereType == #number or: [hereType == #literal or: [hereType == #character]]])
                 ifTrue:
                         [parseNode := encoder encodeLiteral: self advance.
                         ^true].
         (here == #- and: [tokenType == #number and: [1 + hereEnd = mark]])
                 ifTrue:
                         [self advance.
                         parseNode := encoder encodeLiteral: self advance negated.
                         ^true].
         ^false!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20221123/d260736e/attachment.html>


More information about the Squeak-dev mailing list