2015-06-15 10:07 GMT+02:00 Ben Coman <btc@openinworld.com>:
whoops. please excuse my previous clicktoofast.

On Mon, Jun 15, 2015 at 3:51 PM, Cl��ment Bera <bera.clement@gmail.com> wrote:
> Hey all,
>
> Holger Freyther, I didn't know about ##() and once in GNU Smalltalk, but
> that was definitely what I was trying to experiment with.
>
> As Thierry mentioned, these elements come from C/C++ where you have macros
> that are very useful when writing high performance code so your code can be
> both flexible and very efficient.
>
> Ben you're right, normal users should not be confused by those features or
> new syntax elements. For CValue, I added class-side of the classes using it:
>
> MyClass>>#compiler
> | comp |
> comp := super compiler.
> comp compilationContext semanticAnalyzerClass: NeoCompiler.
> ^ comp
>
> I think the solution for this problem is to do another Opal compilation
> options for precompilation. This way, if you want to use your compiler
> extension, you have either to:
> - override #compiler class side for a hierachy of classes granularity
> - add a pragma such as <compilationOptions: + optionPrecompilation> for a
> per method granularity

To make it more explicit, possibly consider requiring the special
selector to be mentioned in the pragma.
�� �� <precompile: #once>�� or�� ��<precompile: #Cvalue>

Now I wonder how this precompiled code might look or operate within a debugger?
cheers -ben

Debugger works fine don't worry.
It either ignores the Cvalue block if precompiled or highlights the inner statements of the blocks if not precompiled while debugging the outer context.
As my code edits the AST and that the AST is kept in a cache there might be some issues with the tools though, but nothing hard to solve.

As Guille said, I think this is interesting experiment, and you can use it and hack it if you want, but I am not sure it should be part of the base image.



>
> then in the methods affected by the compiler extension, you can either use a
> different parser with new syntax elements such as ##() or use new special
> selectors such as #once or #Cvalue.
>
>
> 2015-06-15 7:13 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
>>
>> Hi Ben,
>>
>>
>> Le 15/06/2015 01:09, Ben Coman a ��crit :
>>>
>>> On Mon, Jun 15, 2015 at 2:34 AM, Thierry Goubier
>>> <thierry.goubier@gmail.com> wrote:
>>>>
>>>> Le 14/06/2015 18:39, Holger Freyther a ��crit :
>>>>>
>>>>>
>>>>>
>>>>>> On 13 Jun 2015, at 14:39, Cl��ment Bera <bera.clement@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Dear Clement,
>>>>>
>>>>>> This is an interesting problem. There is currently no simple way of
>>>>>> executing a message at compile-time instead of at runtime in Pharo,
>>>>>> which is
>>>>>> useful to have settings but no runtime overhead.
>>>>>>
>>>>>> I did a simple extension for opal compiler for this purpose, adding
>>>>>> the
>>>>>> message Cvalue, which is compiled by Opal either to its receiver's
>>>>>> block
>>>>>> value or the result of its value depending on the result of
>>>>>> #allowPrecompilation sent to its class using AST manipulation before
>>>>>> the
>>>>>> semantic analysis.
>>>>>
>>>>>
>>>>>
>>>>> are you aware of the compile time constants in GNU Smalltalk. The
>>>>> syntax
>>>>> that was
>>>>> picked is ##(EXPR). E.g. the below is an example for usage in GNU
>>>>> Smalltalk.
>>>>>
>>>>>
>>>>> someMethod
>>>>>�� �� �� �� �� ^##(Character value: 8)
>>>>>
>>>>> the compiler will create a CompiledMethod that holds a literal ($<8>)
>>>>> and
>>>>> will return
>>>>> it. In general I find that syntax quite nice.
>>>>
>>>>
>>>>
>>>> When porting SmaCC from the Dolphin version, I found that optimisation
>>>> in
>>>> many places, as well as methods returning once blocks:
>>>> ^ [ Dictionary new add: .... ] once.
>>>>
>>>> So, I'd say that Cvalue is the same as once :)
>>>>
>>>
>>> Does #once evaluate at compile time?
>>> Or the first pass at run-time?
>>> The latter would have a different runtime overhead to CValue.
>>
>>
>> I don't know. It could even be at first run with a recompilation of the
>> method, to add another solution to the mix :)
>>
>>> There are probably valid arguments for not introducing new syntax
>>> (including cross-dialect compatibility), but for something that occurs
>>> at compile-time rather than run-time, I think I'd prefer syntax to a
>>> keyword.�� To reuse existing elements that are not compiled, that is
>>> either comment quotes or pragma angle brackets.�� Maybe combine pragma
>>> with an executable block...
>>>�� �� �� ��<[ doThis at compileTime ]>
>>
>>
>> #define and friends it is :) In short, a dedicated syntax for compile
>> time... aka macros.
>>
>> Thierry
>>
>>
>