Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-22 Thread Frank Shearar
Why does ifTrue: use a compile-time transformation? There are LOTS of places where the Compiler (I can't speak for Opal, but it's almost certainly true of Pharo's Compiler unless you've already rewritten the whole thing before Opal) does all manner of code transformations. As for why, and what

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-22 Thread Denis Kudriashov
2013/5/22 Frank Shearar frank.shea...@gmail.com Why does ifTrue: use a compile-time transformation? But what makes #future be similar to ifTrue case? What makes it so special? There are LOTS of places where the Compiler (I can't speak for Opal, but it's almost certainly true of Pharo's

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-22 Thread Marcus Denker
On May 22, 2013, at 11:23 AM, Denis Kudriashov dionisi...@gmail.com wrote: 2013/5/22 Frank Shearar frank.shea...@gmail.com Why does ifTrue: use a compile-time transformation? But what makes #future be similar to ifTrue case? What makes it so special? And why do we discuss this on this

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-22 Thread Denis Kudriashov
2013/5/22 Marcus Denker marcus.den...@inria.fr On May 22, 2013, at 11:23 AM, Denis Kudriashov dionisi...@gmail.com wrote: 2013/5/22 Frank Shearar frank.shea...@gmail.com Why does ifTrue: use a compile-time transformation? But what makes #future be similar to ifTrue case? What makes it

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-21 Thread Norbert Hartl
Wow, thanks for the detailed explanation. That is really interesting! Norbert Am 20.05.2013 um 17:57 schrieb Marcus Denker marcus.den...@inria.fr: On May 20, 2013, at 4:44 PM, Paul Davidowitz pdavi...@fastmail.fm wrote: I just started following this Dev mailing list, and I saw that 'AST

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-21 Thread Denis Kudriashov
Why Future required compiler changes? What problem to implement #future message as any other method? If it is about performance can you explain why basic implementation should have bad speed? And what benchmarks was used to verify it? 2013/5/22 David T. Lewis le...@mail.msen.com On Mon, May 20,

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-20 Thread Marcus Denker
On May 20, 2013, at 4:44 PM, Paul Davidowitz pdavi...@fastmail.fm wrote: I just started following this Dev mailing list, and I saw that 'AST Everywhere' and 'Reflectivity' were mentioned as very promising (I already know about Slots). Can someone in a nutshell please describe these

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-20 Thread Frank Shearar
On 20 May 2013 17:26, Marcus Denker marcus.den...@inria.fr wrote: On May 20, 2013, at 6:16 PM, Frank Shearar frank.shea...@gmail.com wrote: On 20 May 2013 16:57, Marcus Denker marcus.den...@inria.fr wrote: On May 20, 2013, at 4:44 PM, Paul Davidowitz pdavi...@fastmail.fm wrote: I just

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-20 Thread Marcus Denker
On May 20, 2013, at 6:43 PM, Frank Shearar frank.shea...@gmail.com wrote: It's a compile-time transformation of #future and #future: messages. Depending on whether or not the result is used (through some basic semantic analysis) the messages are transformed into #futureDo:at:args or

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-20 Thread Paul Davidowitz
All this sounds fascinating, but has any thought been given to ease of maintainability, understandability, and debuggability of software written using these features?

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-20 Thread Marcus Denker
On May 20, 2013, at 6:52 PM, Paul Davidowitz pdavi...@fastmail.fm wrote: All this sounds fascinating, but has any thought been given to ease of maintainability, understandability, and debuggability of software written using these features? You don't write software using these features.

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-20 Thread stephane ducasse
On May 20, 2013, at 6:15 PM, Frank Shearar frank.shea...@gmail.com wrote: On 20 May 2013 16:57, Marcus Denker marcus.den...@inria.fr wrote: On May 20, 2013, at 4:44 PM, Paul Davidowitz pdavi...@fastmail.fm wrote: I just started following this Dev mailing list, and I saw that 'AST

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-20 Thread Frank Shearar
On 20 May 2013 18:35, stephane ducasse stephane.duca...@free.fr wrote: On May 20, 2013, at 6:15 PM, Frank Shearar frank.shea...@gmail.com wrote: On 20 May 2013 16:57, Marcus Denker marcus.den...@inria.fr wrote: On May 20, 2013, at 4:44 PM, Paul Davidowitz pdavi...@fastmail.fm wrote: I just

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-20 Thread stephane ducasse
Hacking inside the compiler instead of extending it to support a good static way of declaring transformations is way to: - make the system more complex, less modular - hamper tools to use a good infrastructure - push hacks and hidden knowledge in all the layers.

Re: [Pharo-dev] AST Everywhere, Reflectivity

2013-05-20 Thread Frank Shearar
On 20 May 2013 19:17, Marcus Denker marcus.den...@inria.fr wrote: On May 20, 2013, at 8:13 PM, Frank Shearar frank.shea...@gmail.com wrote: Like with ifTrue:, whileTrue: and friends: you can still use futures in Squeak if you don't have FutureNode in your image, but things will just run