help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] [PATCH] stinst: Fix the scanner for compile time co


From: Paolo Bonzini
Subject: Re: [Help-smalltalk] [PATCH] stinst: Fix the scanner for compile time constants in literal arrays
Date: Sat, 21 Dec 2013 21:44:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Il 21/12/2013 18:50, Holger Hans Peter Freyther ha scritto:
> Okay, now it is question of getting the code compiled by STCompiler.
> 
>   STInST.RBParser parseExpression: #(##(1/2) 1)
> 
> will create a:
> 
>   RBLiteralNode
>     token: RBLiteralToken(
>               RBOptimizedToken RBNumberLiteralToken(1) RBLiteralToken(#/)
>               RBNumberLiteralToken(2) RBSpecialCharacterToken($)
>               RBNumberLiteralToken(1))
> 
> this means that the RBOptimizedNode is not created and not visited.
> So RBLiteralNode>>#value will call token realValue. We have some problems
> one way or another...
> 
> if we compress RBOptimizedToken ... to a RBOptimizedNode we would
> mix tokens and AST nodes.
> 
> if we add realValue to RBOptimizedToken we re-do things the compiler
> is doing?
> 
> What about creating a RBArrayLiteralNode that has a list RBLiteralNode?
> At the same time the RBOptimizedToken and things will be formatted
> as #{} thing.
> 
> Another thought would be to solve the compile time constants somehow
> else? E.g. do we really need code like this:
> 
>   #(##(| a | a := -2. 'before everything' printNl. a) 3)

Hmm... What if #scanLiteralArrayParts was removed altogether, and the
logic to read the literals and find boundaries moved to RBParser?    A
literal array's initial "#" can be represented by a RBLiteralArrayToken
that, like RBOptimizedToken, is just a placeholder for the starting
position of the array.

RBParser then can convert RBBinarySelectorToken to a literal, and so on.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]