[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