- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] AST Everywhere, Reflectivity

by Marcus Denker

On May 20, 2013, at 6:52 PM, Paul Davidowitz <pdavidow(a)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. You write *Tools* and you *change* the language using this. Normal programmers should not use it for anything. Marcus

May 20, 2013

Re: [Pharo-dev] AST Everywhere, Reflectivity

by 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?

May 20, 2013

Re: [Pharo-dev] AST Everywhere, Reflectivity

by Marcus Denker

On May 20, 2013, at 6:43 PM, Frank Shearar <frank.shearar(a)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 #futureSend:at:args. FutureNode to performs the necessary > transformation through the usual emitCodeForFoo:value: messages. > (Warning: I have limited knowledge of the inner workings of the > Compiler, and so anything I say here might be nonsensical.) Wowâ¦ I would have never implemented it like this. I even would argue that it is conceptually wrong. The AST has a one-to-one mapping to the grammar. What is a message send is a MessageNode, this is even true for ifTrue:, so why would one not keep it like that? Optimizations have to be done on another level. Destroying the AST while generating code is not a good idea! Marcus

May 20, 2013

Re: [Pharo-dev] AST Everywhere, Reflectivity

by Frank Shearar

On 20 May 2013 17:26, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 20, 2013, at 6:16 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 20 May 2013 16:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On May 20, 2013, at 4:44 PM, Paul Davidowitz <pdavidow(a)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 developments? Thanks, >>> >>> >>> Right now, the compiler uses it's own AST, Syntax highlighting uses a very minimal >>> token stream (and it's own parser), the refactoring engine has one, too. >>> And then there is Bytecode which is used by the Debugger, for example. >>> >>> As a first step we plan to use the Refactoring AST for everything >>> (Compiler, Refactoring, Syntax highlighting ) >> >> I keep forgetting to ask - does the Refactoring AST have an equivalent >> of Squeak's FutureNode? > > No. > >> (It's not semantically necessary to have one >> to support futures; it's a performance enhancer.) >> > > Now that sound *very* odd. An AST Node is by definition something > that is a grammatical element of the language. > If you write down the grammar of Smalltalk, there is no "Future" there, > so in the AST there is none modeled, either. > > No, I know nothing about the Future implementation in Squeakâ¦ but > a Future node in the AST sounds extremely strange. 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 #futureSend:at:args. FutureNode to performs the necessary transformation through the usual emitCodeForFoo:value: messages. (Warning: I have limited knowledge of the inner workings of the Compiler, and so anything I say here might be nonsensical.) frank > Marcus

May 20, 2013

Re: [Pharo-dev] Scrolling without clicking in lists

by Benjamin

Mine too ! I opened an issue for that yesterday: https://pharo.fogbugz.com/default.asp?10670 Ben On May 20, 2013, at 6:17 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > In 2.0 you can scroll (using a scroll wheel or the track pad 2-finger swipe) in any list (of a browser for example) just by moving the mouse pointer over it, _without_ clicking in it, thus _without_ moving the focus. > > In 3.0 this seems to be broken: no matter where you are with the mouse pointer, you scroll the view with focus. > > As far as I can tell, this is not how it should be, and it brakes my workflow ;-) > > Sven

May 20, 2013

Re: [Pharo-dev] Scrolling without clicking in lists

by Marcus Denker

On May 20, 2013, at 6:17 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > In 2.0 you can scroll (using a scroll wheel or the track pad 2-finger swipe) in any list (of a browser for example) just by moving the mouse pointer over it, _without_ clicking in it, thus _without_ moving the focus. > > In 3.0 this seems to be broken: no matter where you are with the mouse pointer, you scroll the view with focus. > Maybe a side effect of some cleanups in this? 10557 ArrowUp and arrowDown not working in keycaps https://pharo.fogbugz.com/f/cases/10557 ? Marcus

May 20, 2013

Re: [Pharo-dev] AST Everywhere, Reflectivity

by Marcus Denker

On May 20, 2013, at 6:16 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 20 May 2013 16:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On May 20, 2013, at 4:44 PM, Paul Davidowitz <pdavidow(a)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 developments? Thanks, >> >> >> Right now, the compiler uses it's own AST, Syntax highlighting uses a very minimal >> token stream (and it's own parser), the refactoring engine has one, too. >> And then there is Bytecode which is used by the Debugger, for example. >> >> As a first step we plan to use the Refactoring AST for everything >> (Compiler, Refactoring, Syntax highlighting ) > > I keep forgetting to ask - does the Refactoring AST have an equivalent > of Squeak's FutureNode? No. > (It's not semantically necessary to have one > to support futures; it's a performance enhancer.) > Now that sound *very* odd. An AST Node is by definition something that is a grammatical element of the language. If you write down the grammar of Smalltalk, there is no "Future" there, so in the AST there is none modeled, either. No, I know nothing about the Future implementation in Squeakâ¦ but a Future node in the AST sounds extremely strange. Marcus

May 20, 2013

Re: [Pharo-dev] Printing of BlockClosures

by Sven Van Caekenberghe

On 20 May 2013, at 18:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 20, 2013, at 6:10 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi, >> >> One of the things that always positively surprised me about Smalltalk was the fact that BlockClosures are printing showing their actual source code, you don't get that in many languages. >> >> But now this seems to be gone, maybe temporarily, from 3.0 >> >> [ :n | n + 1 ] => [â¦] >> >> Was this intentional ? >> > Yes, the old compiler does it with lots of horrible code with decompilationâ¦ so I removed it for now, the new compiler > can do it very nicely. > > I will add it back for when Opal is running soon. > > Marcus OK, I suspected something like that. Sven

May 20, 2013

Scrolling without clicking in lists

by Sven Van Caekenberghe

Hi, In 2.0 you can scroll (using a scroll wheel or the track pad 2-finger swipe) in any list (of a browser for example) just by moving the mouse pointer over it, _without_ clicking in it, thus _without_ moving the focus. In 3.0 this seems to be broken: no matter where you are with the mouse pointer, you scroll the view with focus. As far as I can tell, this is not how it should be, and it brakes my workflow ;-) Sven

May 20, 2013

Re: [Pharo-dev] AST Everywhere, Reflectivity

by Frank Shearar

On 20 May 2013 16:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 20, 2013, at 4:44 PM, Paul Davidowitz <pdavidow(a)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 developments? Thanks, > > > Right now, the compiler uses it's own AST, Syntax highlighting uses a very minimal > token stream (and it's own parser), the refactoring engine has one, too. > And then there is Bytecode which is used by the Debugger, for example. > > As a first step we plan to use the Refactoring AST for everything > (Compiler, Refactoring, Syntax highlighting ) I keep forgetting to ask - does the Refactoring AST have an equivalent of Squeak's FutureNode? (It's not semantically necessary to have one to support futures; it's a performance enhancer.) frank

May 20, 2013