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. 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