String Interpolation

Why not having an opal plugin?

The opal plugin may read strings in the form:

"lalala {some expression} lololo"

and replace at compile time that by:

"lalala {1} lololo" format { some expression }

The thing to think about is what is the delimiter for {some expression}.

 - a too used one may break lots of existing code.

 - and we should escape it

On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <[hidden email]> wrote:

> On 29 Sep 2017, at 08:54, Pavel Krivanek <[hidden email]> wrote:
>
> This solution will not work for environments without sources too where names like t1, t2 are used for temporary variables.

That is true.

I often wonder why we can't keep at least the variables names, it would not be that expensive. There was this problem with FFI that needed source code access as well. It would also help the debugger and make the decompiler more powerful.

> Anyway, nice idea.
>
> -- Pavel
>
> Dne čtvrtek 28. září 2017 Sven Van Caekenberghe <[hidden email]> napsal(a):
> Hi,
>
> I got into a little office discussion about string interpolation as it is done in different programming languages.
>
> In Pharo we have String>>#format: which is pretty nice. It works as follows:
>
> | x y |
> x := 123.
> y := #foo.
> 'x={1} and y={2}' format: { x. y }.
>
> It is also possible to use a dictionary with keys, like this:
>
> | x y |
> x := 123.
> y := #foo.
> 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary.
>
> But this is not true string interpolation as described in [ https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to write the value generating expressions directly inside the strings.
>
> Since in Pharo we add features not by extending the syntax but by adding messages I wondered if it could be done for string interpolation. The goal is to make the following work:
>
> | x y |
> x := 123.
> y := #foo.
> 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' interpolate.
>
>  => 'It seems x equals 123 and y equals foo while Pi is still 3.141592653589793'
>
> Here is the implementation I came up with:
>
> String>>#interpolate
>   "Format the receiver by interpolating the evaluation of expressions
>   in between curly brackets in the context of the sender as in the following 3 oneline examples.
>   'Today is {Date today}' interpolate.
>   | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate.
>   'In {#strings} you can escape \{ by prefixing it with \\' interpolate."
>
>   | senderContext |
>   senderContext := thisContext sender.
>   ^ self class new: self size streamContents: [ :out | | stream |
>       stream := self readStream.
>       [ stream atEnd ] whileFalse: [ | currentChar |
>         (currentChar := stream next) == ${
>           ifTrue: [ | expression result |
>             expression := stream upTo: $}.
>             result := Compiler new
>               evaluate: expression in: senderContext to: nil notifying: nil ifFail: [ ^ nil ] logged: false.
>             out nextPutAll: result asString ]
>           ifFalse: [
>             currentChar == $\
>               ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] ]
>               ifFalse: [ out nextPut: currentChar ] ] ] ]
>
> It is a hack that could certainly be improved. And there is of course an obvious security problem.
>
> Thoughts ?
>
> Sven
>
>

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Hi.

While idea looks cool it will require a lot of tool support. Senders, var/class references, rename refactorings should be aware of it

2017-10-03 17:29 GMT+02:00 Damien Pollet <[hidden email]>:

On 3 October 2017 at 14:07, Guillermo Polito <[hidden email]> wrote:

Why not having an opal plugin?

The opal plugin may read strings in the form:

"lalala {some expression} lololo"

and replace at compile time that by:

"lalala {1} lololo" format { some expression }

If we're going to extend the compiler, we might as avoid parsing at runtime by desugaring more like:

String streamContents: [:str |

    str

        nextPutAll: 'lalala ';

        nextPutAll: (some expression) printString;

        nextPutAll: ' lololo' ]

The thing to think about is what is the delimiter for {some expression}.

 - a too used one may break lots of existing code.

…or we could change the string quotes to mean "dynamic string in which interpolations can be used" and keep single quotes for literal strings only.

 - and we should escape it

indeed

 

On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <[hidden email]> wrote:

> On 29 Sep 2017, at 08:54, Pavel Krivanek <[hidden email]> wrote:
>
> This solution will not work for environments without sources too where names like t1, t2 are used for temporary variables.

That is true.

I often wonder why we can't keep at least the variables names, it would not be that expensive. There was this problem with FFI that needed source code access as well. It would also help the debugger and make the decompiler more powerful.

> Anyway, nice idea.
>
> -- Pavel
>
> Dne čtvrtek 28. září 2017 Sven Van Caekenberghe <[hidden email]> napsal(a):
> Hi,
>
> I got into a little office discussion about string interpolation as it is done in different programming languages.
>
> In Pharo we have String>>#format: which is pretty nice. It works as follows:
>
> | x y |
> x := 123.
> y := #foo.
> 'x={1} and y={2}' format: { x. y }.
>
> It is also possible to use a dictionary with keys, like this:
>
> | x y |
> x := 123.
> y := #foo.
> 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary.
>
> But this is not true string interpolation as described in [ https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to write the value generating expressions directly inside the strings.
>
> Since in Pharo we add features not by extending the syntax but by adding messages I wondered if it could be done for string interpolation. The goal is to make the following work:
>
> | x y |
> x := 123.
> y := #foo.
> 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' interpolate.
>
>  => 'It seems x equals 123 and y equals foo while Pi is still 3.141592653589793'
>
> Here is the implementation I came up with:
>
> String>>#interpolate
>   "Format the receiver by interpolating the evaluation of expressions
>   in between curly brackets in the context of the sender as in the following 3 oneline examples.
>   'Today is {Date today}' interpolate.
>   | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate.
>   'In {#strings} you can escape \{ by prefixing it with \\' interpolate."
>
>   | senderContext |
>   senderContext := thisContext sender.
>   ^ self class new: self size streamContents: [ :out | | stream |
>       stream := self readStream.
>       [ stream atEnd ] whileFalse: [ | currentChar |
>         (currentChar := stream next) == ${
>           ifTrue: [ | expression result |
>             expression := stream upTo: $}.
>             result := Compiler new
>               evaluate: expression in: senderContext to: nil notifying: nil ifFail: [ ^ nil ] logged: false.
>             out nextPutAll: result asString ]
>           ifFalse: [
>             currentChar == $\
>               ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] ]
>               ifFalse: [ out nextPut: currentChar ] ] ] ]
>
> It is a hack that could certainly be improved. And there is of course an obvious security problem.
>
> Thoughts ?
>
> Sven
>
>

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Hi.

While idea looks cool it will require a lot of tool support. Senders, var/class references, rename refactorings should be aware of it

2017-10-03 17:29 GMT+02:00 Damien Pollet <[hidden email]>:

On 3 October 2017 at 14:07, Guillermo Polito <[hidden email]> wrote:

Why not having an opal plugin?

The opal plugin may read strings in the form:

"lalala {some expression} lololo"

and replace at compile time that by:

"lalala {1} lololo" format { some expression }

If we're going to extend the compiler, we might as avoid parsing at runtime by desugaring more like:

String streamContents: [:str |

    str

        nextPutAll: 'lalala ';

        nextPutAll: (some expression) printString;

        nextPutAll: ' lololo' ]

The thing to think about is what is the delimiter for {some expression}.

 - a too used one may break lots of existing code.

…or we could change the string quotes to mean "dynamic string in which interpolations can be used" and keep single quotes for literal strings only.

 - and we should escape it

indeed

 

On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <[hidden email]> wrote:

> On 29 Sep 2017, at 08:54, Pavel Krivanek <[hidden email]> wrote:
>
> This solution will not work for environments without sources too where names like t1, t2 are used for temporary variables.

That is true.

I often wonder why we can't keep at least the variables names, it would not be that expensive. There was this problem with FFI that needed source code access as well. It would also help the debugger and make the decompiler more powerful.

> Anyway, nice idea.
>
> -- Pavel
>
> Dne čtvrtek 28. září 2017 Sven Van Caekenberghe <[hidden email]> napsal(a):
> Hi,
>
> I got into a little office discussion about string interpolation as it is done in different programming languages.
>
> In Pharo we have String>>#format: which is pretty nice. It works as follows:
>
> | x y |
> x := 123.
> y := #foo.
> 'x={1} and y={2}' format: { x. y }.
>
> It is also possible to use a dictionary with keys, like this:
>
> | x y |
> x := 123.
> y := #foo.
> 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary.
>
> But this is not true string interpolation as described in [ https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to write the value generating expressions directly inside the strings.
>
> Since in Pharo we add features not by extending the syntax but by adding messages I wondered if it could be done for string interpolation. The goal is to make the following work:
>
> | x y |
> x := 123.
> y := #foo.
> 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' interpolate.
>
>  => 'It seems x equals 123 and y equals foo while Pi is still 3.141592653589793'
>
> Here is the implementation I came up with:
>
> String>>#interpolate
>   "Format the receiver by interpolating the evaluation of expressions
>   in between curly brackets in the context of the sender as in the following 3 oneline examples.
>   'Today is {Date today}' interpolate.
>   | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate.
>   'In {#strings} you can escape \{ by prefixing it with \\' interpolate."
>
>   | senderContext |
>   senderContext := thisContext sender.
>   ^ self class new: self size streamContents: [ :out | | stream |
>       stream := self readStream.
>       [ stream atEnd ] whileFalse: [ | currentChar |
>         (currentChar := stream next) == ${
>           ifTrue: [ | expression result |
>             expression := stream upTo: $}.
>             result := Compiler new
>               evaluate: expression in: senderContext to: nil notifying: nil ifFail: [ ^ nil ] logged: false.
>             out nextPutAll: result asString ]
>           ifFalse: [
>             currentChar == $\
>               ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] ]
>               ifFalse: [ out nextPut: currentChar ] ] ] ]
>
> It is a hack that could certainly be improved. And there is of course an obvious security problem.
>
> Thoughts ?
>
> Sven
>
>

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

if the compiler plugin correctly models such special syntax with special AST nodes, that could be even possible without much effort

On Tue, Oct 3, 2017 at 5:42 PM, Denis Kudriashov <[hidden email]> wrote:

2017-10-03 17:39 GMT+02:00 Denis Kudriashov <[hidden email]>:

Hi.

While idea looks cool it will require a lot of tool support. Senders, var/class references, rename refactorings should be aware of it

And I forgot debugger. It should be possible to step over "interpolated expressions"

 

2017-10-03 17:29 GMT+02:00 Damien Pollet <[hidden email]>:

On 3 October 2017 at 14:07, Guillermo Polito <[hidden email]> wrote:

Why not having an opal plugin?

The opal plugin may read strings in the form:

"lalala {some expression} lololo"

and replace at compile time that by:

"lalala {1} lololo" format { some expression }

If we're going to extend the compiler, we might as avoid parsing at runtime by desugaring more like:

String streamContents: [:str |

    str

        nextPutAll: 'lalala ';

        nextPutAll: (some expression) printString;

        nextPutAll: ' lololo' ]

The thing to think about is what is the delimiter for {some expression}.

 - a too used one may break lots of existing code.

…or we could change the string quotes to mean "dynamic string in which interpolations can be used" and keep single quotes for literal strings only.

 - and we should escape it

indeed

 

On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <[hidden email]> wrote:

> On 29 Sep 2017, at 08:54, Pavel Krivanek <[hidden email]> wrote:
>
> This solution will not work for environments without sources too where names like t1, t2 are used for temporary variables.

That is true.

I often wonder why we can't keep at least the variables names, it would not be that expensive. There was this problem with FFI that needed source code access as well. It would also help the debugger and make the decompiler more powerful.

> Anyway, nice idea.
>
> -- Pavel
>
> Dne čtvrtek 28. září 2017 Sven Van Caekenberghe <[hidden email]> napsal(a):
> Hi,
>
> I got into a little office discussion about string interpolation as it is done in different programming languages.
>
> In Pharo we have String>>#format: which is pretty nice. It works as follows:
>
> | x y |
> x := 123.
> y := #foo.
> 'x={1} and y={2}' format: { x. y }.
>
> It is also possible to use a dictionary with keys, like this:
>
> | x y |
> x := 123.
> y := #foo.
> 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary.
>
> But this is not true string interpolation as described in [ https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to write the value generating expressions directly inside the strings.
>
> Since in Pharo we add features not by extending the syntax but by adding messages I wondered if it could be done for string interpolation. The goal is to make the following work:
>
> | x y |
> x := 123.
> y := #foo.
> 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' interpolate.
>
>  => 'It seems x equals 123 and y equals foo while Pi is still 3.141592653589793'
>
> Here is the implementation I came up with:
>
> String>>#interpolate
>   "Format the receiver by interpolating the evaluation of expressions
>   in between curly brackets in the context of the sender as in the following 3 oneline examples.
>   'Today is {Date today}' interpolate.
>   | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate.
>   'In {#strings} you can escape \{ by prefixing it with \\' interpolate."
>
>   | senderContext |
>   senderContext := thisContext sender.
>   ^ self class new: self size streamContents: [ :out | | stream |
>       stream := self readStream.
>       [ stream atEnd ] whileFalse: [ | currentChar |
>         (currentChar := stream next) == ${
>           ifTrue: [ | expression result |
>             expression := stream upTo: $}.
>             result := Compiler new
>               evaluate: expression in: senderContext to: nil notifying: nil ifFail: [ ^ nil ] logged: false.
>             out nextPutAll: result asString ]
>           ifFalse: [
>             currentChar == $\
>               ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] ]
>               ifFalse: [ out nextPut: currentChar ] ] ] ]
>
> It is a hack that could certainly be improved. And there is of course an obvious security problem.
>
> Thoughts ?
>
> Sven
>
>

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Igor Stasenko wrote
> IMO, best would be to make it via compiler plugin.

It seems there is always a tension between newbie-friendliness/purity and
max-performance/deployment. There are so many other things about a Smalltalk
image that are insecure and any compiler "tricks" are additional places to
hang up the sizable community that doesn't need that security or efficiency.
Would it be possible to implement it as Sven suggested and then provide a
compiler plugin as part of a deployment hardening process like we used to
have where e.g. tools are disabled, etc?

-----
Cheers,
Sean

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Hi Igor.

Did you see that we have now #asMethodConstant?

DateAndTime now asMethodConst

It is not compiled time but behaviour is very close to it. 

The trick is that first time execution will replace full expression with the result as literal (the receiver of #asMethodConst). So at second time it will be just literal reading. 

2017-10-04 11:36 GMT+02:00 Igor Stasenko <[hidden email]>:

IMO, best would be to make it via compiler plugin.

Same, as i proposed for object literals,

a compiler could detect a pattern  <string literal> interpolate

and replace it  at compile time to produce/expand it into proper context-aware semantic, something like this:

{'a' . x . 'b' . y. 'c' .z } gather: #asString

That will allow to eliminate run-time security risk(due to #evaluate:), as well as run-time execution cost, 

and allows a nice and convenient and clean syntax.

Without compiler modification, it's hard to reach best security & performance & convenience ideals.

On 4 October 2017 at 11:06, Thierry Goubier <[hidden email]> wrote:

2017-10-04 9:50 GMT+02:00 Guillermo Polito <[hidden email]>:

if the compiler plugin correctly models such special syntax with special AST nodes, that could be even possible without much effort

Interesting. Would that imply that by having those special ast nodes, we would get the decompilation working for the debugger?

Thierry

 

On Tue, Oct 3, 2017 at 5:42 PM, Denis Kudriashov <[hidden email]> wrote:

2017-10-03 17:39 GMT+02:00 Denis Kudriashov <[hidden email]>:

Hi.

While idea looks cool it will require a lot of tool support. Senders, var/class references, rename refactorings should be aware of it

And I forgot debugger. It should be possible to step over "interpolated expressions"

 

2017-10-03 17:29 GMT+02:00 Damien Pollet <[hidden email]>:

On 3 October 2017 at 14:07, Guillermo Polito <[hidden email]> wrote:

Why not having an opal plugin?

The opal plugin may read strings in the form:

"lalala {some expression} lololo"

and replace at compile time that by:

"lalala {1} lololo" format { some expression }

If we're going to extend the compiler, we might as avoid parsing at runtime by desugaring more like:

String streamContents: [:str |

    str

        nextPutAll: 'lalala ';

        nextPutAll: (some expression) printString;

        nextPutAll: ' lololo' ]

The thing to think about is what is the delimiter for {some expression}.

 - a too used one may break lots of existing code.

…or we could change the string quotes to mean "dynamic string in which interpolations can be used" and keep single quotes for literal strings only.

 - and we should escape it

indeed

 

On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <[hidden email]> wrote:

> On 29 Sep 2017, at 08:54, Pavel Krivanek <[hidden email]> wrote:
>
> This solution will not work for environments without sources too where names like t1, t2 are used for temporary variables.

That is true.

I often wonder why we can't keep at least the variables names, it would not be that expensive. There was this problem with FFI that needed source code access as well. It would also help the debugger and make the decompiler more powerful.

> Anyway, nice idea.
>
> -- Pavel
>
> Dne čtvrtek 28. září 2017 Sven Van Caekenberghe <[hidden email]> napsal(a):
> Hi,
>
> I got into a little office discussion about string interpolation as it is done in different programming languages.
>
> In Pharo we have String>>#format: which is pretty nice. It works as follows:
>
> | x y |
> x := 123.
> y := #foo.
> 'x={1} and y={2}' format: { x. y }.
>
> It is also possible to use a dictionary with keys, like this:
>
> | x y |
> x := 123.
> y := #foo.
> 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary.
>
> But this is not true string interpolation as described in [ https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to write the value generating expressions directly inside the strings.
>
> Since in Pharo we add features not by extending the syntax but by adding messages I wondered if it could be done for string interpolation. The goal is to make the following work:
>
> | x y |
> x := 123.
> y := #foo.
> 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' interpolate.
>
>  => 'It seems x equals 123 and y equals foo while Pi is still 3.141592653589793'
>
> Here is the implementation I came up with:
>
> String>>#interpolate
>   "Format the receiver by interpolating the evaluation of expressions
>   in between curly brackets in the context of the sender as in the following 3 oneline examples.
>   'Today is {Date today}' interpolate.
>   | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate.
>   'In {#strings} you can escape \{ by prefixing it with \\' interpolate."
>
>   | senderContext |
>   senderContext := thisContext sender.
>   ^ self class new: self size streamContents: [ :out | | stream |
>       stream := self readStream.
>       [ stream atEnd ] whileFalse: [ | currentChar |
>         (currentChar := stream next) == ${
>           ifTrue: [ | expression result |
>             expression := stream upTo: $}.
>             result := Compiler new
>               evaluate: expression in: senderContext to: nil notifying: nil ifFail: [ ^ nil ] logged: false.
>             out nextPutAll: result asString ]
>           ifFalse: [
>             currentChar == $\
>               ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] ]
>               ifFalse: [ out nextPut: currentChar ] ] ] ]
>
> It is a hack that could certainly be improved. And there is of course an obvious security problem.
>
> Thoughts ?
>
> Sven
>
>

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

Best regards,
Igor Stasenko.

On 4 October 2017 at 17:27, Sean P. DeNigris <[hidden email]> wrote:

Igor Stasenko wrote
> IMO, best would be to make it via compiler plugin.

It seems there is always a tension between newbie-friendliness/purity and
max-performance/deployment. There are so many other things about a Smalltalk
image that are insecure and any compiler "tricks" are additional places to
hang up the sizable community that doesn't need that security or efficiency.
Would it be possible to implement it as Sven suggested and then provide a
compiler plugin as part of a deployment hardening process like we used to
have where e.g. tools are disabled, etc?

Of course, you can have both:
- the actual implementation of message as fallback when compiler plugin is not present

- the compiler plugin that does the magic, following same semantics 

-----
Cheers,
Sean

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

--

Best regards,
Igor Stasenko.

Hi Igor.

Did you see that we have now #asMethodConstant?

DateAndTime now asMethodConst

It is not compiled time but behaviour is very close to it. 

The trick is that first time execution will replace full expression with the result as literal (the receiver of #asMethodConst). So at second time it will be just literal reading. 

2017-10-04 6:46 GMT-03:00 Denis Kudriashov <[hidden email]>:

Hi Igor.

Did you see that we have now #asMethodConstant?

DateAndTime now asMethodConst

It is not compiled time but behaviour is very close to it. 

The trick is that first time execution will replace full expression with the result as literal (the receiver of #asMethodConst). So at second time it will be just literal reading. 

It is weird that a regular message send makes the returned value a method constant.

How is that cleaned up? Do I have to search for all the methods that contain such message send?

Dolphin had the ##() syntax, which basically creates a method constant, but it is evaluated right away.

So you could write the seconds in a day as ##(60*60*24), or, of course, any more complex expression. But the difference is that it is resolved at compile time.

However I don't see how this relates with the String interpolation :) 

Esteban A. Maringolo