Ancient walkback in compiler

47 views
Skip to first unread message

Marcus Wagner

unread,
Aug 14, 2025, 4:30:35 AMAug 14
to VAST Community Forum
Testing 14.1 I just came across another (ancient) bug in the compiler. Can be reproduced easy, open a class browser, try to create a new method, enter this two lines

test
(super) x

and try to save the code, that results in a walkback: EsBrackettedExpression does not understand binding, and the method cannot be saved.

Suggested quick fix: add to class EsBrackettedExpression this method

binding
^self contents binding
(I created an extension to EsParsing providing this).

There are other ways to fix this, e.g. to check if receiver is a EsVariableWithBinding
before calling binding, just like in constructs as here
self receiver class = EsVariableWithBinding and: [self receiver binding....
Conclusion: to avoid a debate about (superfluous) parenthesis I state that any expression might be decorated like this, until s.b. gives me a profound reason why super is so special that it may not be set under parenthesis. 
Of course, nobody will be write this intentionally, but generated code might, eg. while generacally generating an EsPrimary. 
Try to save any of these code fragments representing an EsPrimary
(super)
(nil) 
(self)
(true)
(false)
(aVariable) 
(ClassVariable)
(GlobalVariable)
(SystemExceptions::ExAll)
(5) 
('abcde')
(x = y)
(a bitAnd: b)
....
Only the case (super) creates a wb, all other examples can be written and saved.
-
M

Davide Grandi

unread,
Aug 15, 2025, 3:49:50 PMAug 15
to va-sma...@googlegroups.com
Hi, does the parser classes "descend" from a "canonical" grammar / parser ?
I mean LR, LL and so on. If so, a grammar rule
message := (super) <selector>
or one of its transformations, can suggest one of the "right" points of intervention.

Buona giornata / have a nice day,

    Davide Grandi
(sent from a mobile device: excuse brevity and typos)
--


-------- Messaggio originale --------
Da: 'Marcus Wagner' via VAST Community Forum <va-sma...@googlegroups.com>
Data: 14/08/25 10:30 (GMT+01:00)
A: VAST Community Forum <va-sma...@googlegroups.com>
Oggetto: Ancient walkback in compiler

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/06d20871-6a3a-4449-b1be-d33486e6c86fn%40googlegroups.com.

Marcus Wagner

unread,
Aug 16, 2025, 6:18:03 AMAug 16
to VAST Community Forum
Hi Davide,
my recherche towards 

"canonical grammar"
Informal grammar: the book, "Smalltalk, the language (Goldberg, Robson), 1989" provided graphic diagrams of the grammar in the inner envelop of the book. There super is (a reserved) identifier, thus an expression, a valid part of the bracketted expression.
Formal grammar: ANSI Standard 1998, provides EBNF rules, there super -> identifier -> primary -> expression -> ( expression ). 
So (super) is correct syntax and the current implementation correctly represents that.

"canonical parser"
As the code then was hidden (but similar to the current implementation) there are some indications that it the model was potentially generated with tool assistance, but not with a tool in the line of a LALR / LR generator family, perhaps LL help was involved.

And I repeat, handling the grammar is/was correct.   
Even if a tool provided the framework of the model, realising actions in grammar rules, that is/was written by hand. 
The model in EsParsing follows the standard and accepts even this case, however in drawing its conclusions (evaluation of attributes of the grammar) it fails: the WB stems from missing code in an unlikely constellation. 
It does not erroneously claiming an syntax error, it simply crashes to evaluate an attribute which was not propagated in all cases.
Thus providing the missing method (as suggested by me) closes the gap, saving code completes and the compiled method works correctly.

History: this code already failed exactly in the same way in  Visual Age 5.0 dated 1999.
The code then was hidden, the timestamp indicating code was created in 1996. 
It is likely that the code originates from OTI Envy ST, even before being overtaken by IBM.  
I did not go back further, eg. to look into Envy 3.0 (1993-4?) , the earliest version I have potential access to.
As I am cleaning up my archive I felt it is time to publish this before being lost.
-
Marcus

Davide Grandi

unread,
Aug 16, 2025, 9:51:37 AMAug 16
to va-sma...@googlegroups.com

Very clear, and ...
... thank-you very much for the warning !

    Davide

Reply all
Reply to author
Forward
0 new messages