On Wed, Mar 1, 2017 at 3:56 PM, Ben Coman <[email protected]> wrote:
>
> I'm not sure I'm thinking straight, but I wonder...
> Can you put Slots inside an Association?
>
> For example, could have two slots x and y,
> and then be able to do the following...
>
> (x -> y) substitute: (1 -> 2).
> self assert: x equals: 1.
> self assert: y equals: 2.
>
For this you can do it by manipulating the stack in #substitute: . Are x
and y temporary variables or instance variables ? You could look-up in the
context's sender method AST what they are and do something accordingly.
>
> So the association method #substitute:
> assigns into the relevant variables.
>
> And even better if you could do...
> (x -> y) := (1 -> 2).
> and...
> { x. y ) := #(1 2).
>
>
For this you need parser extensions as this is not valid Smalltalk.
For example, when you're hacking fast and want to return two values from a
> method without mucking around with creating an object for this, it might
> look like...
> myCalc
> ^#(1 2)
>
> but instead of...
> result := inst myCalc.
> x := result at: 1.
> y := result at: 2.
>
> you could do...
> { x . y } := inst myCalc.
>
You mean like tuples in Python ?
To cover all your use-cases, the best is to change the bytecode compilation
pipeline.
If you need to extend the Syntax, you need to use Opal with an extended
Parser (Typically a subclass of RBParser you write).
Then the easiest is to transform the AST from your extended parser (or the
default AST if you don't extend the syntax) to standard Smalltalk AST doing
what you want before the semantic analysis and feed it to Opal. You can do
something manually or something with RBParseTreeRewriter :-).
In the cases you show it is enough to generate what you want.
Ah yeah, modifying the syntax or modifying the expected behavior of a
syntax is often considered as a bad practice or evil.
>
> cheers -ben
>
