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 <[email protected]> wrote: > > 2017-10-03 17:39 GMT+02:00 Denis Kudriashov <[email protected]>: > >> 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 <[email protected]>: >> >>> On 3 October 2017 at 14:07, Guillermo Polito <[email protected]> >>> 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 <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> > On 29 Sep 2017, at 08:54, Pavel Krivanek <[email protected]> >>>>> 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 <[email protected]> >>>>> 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 >>>> <http://www.cnrs.fr>* >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >>> >>> -- >>> 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
