Just downloaded AST->88 NewCompiler->117 from SqueakMap
ClosureCompiler evaluate: '##' and co leads to Syntax errors.
#1 #$ #) etc are also rejected.
BUT ClosureCompiler evaluate: '#:'. answer an empty string HUH? MIGHT BE A BUG
ClosureCompiler evaluate: '#::'. #:SmaCCParserError: Token not expected ->:
'# a' is understood as #a (like VW). '#x:y:z' is understood as #x:y: z (send message z) like VW.
Of course it accepts more than 2 binary letters to form a binary symbol/message (already an old compiler feature, but not a st-80 nor VW one): ClosureCompiler evaluate: '#+++'. #'+++'
Interesting thing: ClosureCompiler does understand #|| and #-- This is not in the original st-80 but is a logical feature since also accept || and -- as regular binary messages.
So finally, only a bug now. And Symbol storeString still not in sync with Parser. This will cause decompiled code to be different from source code #'x:y:z' does print #x:y:z that is interpreted (#x:y:) z BUG. (see Scanner isLiteralSymbol: which was the real focus of my initial post before i ran into weird old compiler behaviour).
stephane ducasse a écrit :
did you try with the new compiler?
On 23 mai 07, at 01:47, nicolas cellier wrote:
Hello list,
Today's quizz: guess the results of these evaluations and how it prints
Easy to begin with: Compiler evaluate: '#++'. Yes Scanner class>>#isLiteralSymbol: not really consistent with what the parser is ready to understand. It even has some unreachable code in it.
Now what if: Compiler evaluate: '##'. Enjoy the variations, not all correct: Compiler evaluate: '#'. Compiler evaluate: '# "please" # "print" # "me"'. Compiler evaluate: '##()'. Compiler evaluate: '##)'. Compiler evaluate: '##('. Compiler evaluate: '##(##)'. Never heard about explicit number literal? Compiler evaluate: '#1'. Maybe the negative ones would work? Compiler evaluate: '#-1'. So try and explain this one: Compiler evaluate: '#--1'.
Hmm, better correcting the parser than trying to write its EBNF rules!
Nicolas