On Mon, Jun 15, 2015 at 2:34 AM, Thierry Goubier
<thierry.goub...@gmail.com> wrote:
> Le 14/06/2015 18:39, Holger Freyther a écrit :
>>
>>
>>> On 13 Jun 2015, at 14:39, Clément Bera <bera.clem...@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.
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 ]>
Marcus said:
> I am a bit sceptical to have meta links show up as syntax…
> I see two possibilities one could experiment with:
btw, Are meta links planned to show up as highlighting in code views?
btw2, I guess if debugging code is a meta link, it won't get filed out
or saved by Monticello. This would have a benefit to minimise adhoc
logging accidentally ending up in packages, but wouldn't suit a case
where the logging is meant to permanently remain spread throughout the
code ready for all to be enabled when needed. Otherwise you'd need
code in a separate location that installs the debugging metalinks,
which may be susceptible to getting out sync with the main code it
references.
cheers -ben
