There are more clean ups coming soon, when i'll figure out the right order to not break the update stream: The light ones: ------------------- Compiler>>notify:(at:) is (are) not required We also remove the inst. var. from CompilationCue, SyntaxError, SyntaxErrorNotification. I realized this when writing CompilationCue comments. Class comments are really usefull, not only for the clients, they also help the producer to introspect its own design. OK, we need some sort of source code, and (or?) the TextEditor if interactive (requestor). Then the compilation context should simply be:- either a class for compiling a method, (for resolving inst/class/shared variable names) All these are in the CompilationCue. And finally, a failBlock is most often provided. I already shrinked the nil passing a bit, and removed a few methods, but I feel I did not go far enough. A possibility is to expose the CompilationCue (CompilationContext?).The big ones: ----------------- . (Compiler forEvaluating: aString in: receiver) parseIfFail: failBlock . (Compiler forEvaluating: aString inContext: aContext) evaluateIfFail: failBlock This would have the merit to avoid the funny duplication of class-side and instance-side API. We could have specialized messages for interactive requestor (TextEditor or PragraphEditor for nostalghia): . (Compiler forEvaluatingInEditor: anEditor) ... It may sound more natural to write: . (Compiler forEvaluatingIn: receiver) parse: sourceString ifFail: failBlock But the sourceString and/or Editor has to be in the CompilationCue right now, and a single Compiler instance cannot easily compile two different strings as the error handling is written right now (we may try to change this too eventually). After all, we have compilerClass and evaluatorClass. Though it sounds a bit revolutionary right now given current Compiler usage in a trunk image (way too many refs)... Maybe I'll give a try to some of these ideas in the inbox... |
On 19-09-2013, at 6:20 PM, Nicolas Cellier <[hidden email]> wrote: > There are more clean ups coming soon, when i'll figure out the right order to not break the update stream: I'm not familiar enough with how the Compiler is structured these days but thank you for working on tidying it up. Suggestion; rather than specialised messages try a subclass of Compiler that deals with interactive use and another for batch use. Unless that is what it does already, in which case ignore me ;-) tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Error 13: Illegal brain function. Process terminated. |
Hi Tim,
On Thu, Sep 19, 2013 at 7:27 PM, tim Rowledge <[hidden email]> wrote:
One of the nice improvements is to ditch compilerClass, parserClass et al in favour of newCompiler, newParser, which can then allow exotic initialization etc. Compilation cues provide a much nicer way of providing input context to the compiler.
The BytecodeEncoder backend now insulates the compiler from bytecode encoding and hence supports multiple bytecode sets (in use here at Cadence and needing to be more generally released when time allows). I think these are the big improvements over recent years.
best, Eliot
|
Indeed, with newCompiler trick, there is normally no much need to subclass Compiler, thus no need to override compilerClass/evaluatorClass. Overriding parserClass is enough for playing with different syntax, encoder, etc... I mean that measured in neuron power, maintenance is really costly. Keep a good pile of sugar not to far from your computer if you want to dive into it :) 2013/9/20 Eliot Miranda <[hidden email]>
|
Free forum by Nabble | Edit this page |