Smalltalk › Squeak › Squeak - Dev

Compiler detox

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Nicolas Cellier

Compiler detox

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

An Encoder can notify its requestor (a Parser!) of a bytecode limit or incorrect variable usage.

A Parser can notify itself of a syntax error.

But no one is ever going to notify a Compiler.

A Compiler is just a facade, it does not much work by itself...

A Compiler does not need to know about category.

A Compiler compiles, it does not classify.

The only usage of CompilationCue category right know is to display it in the SyntaxError window!

Better remove this feature, that's a bunch of simplifications in long parameter chains.

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.

Generally, we pass too many parameters to a Compiler.

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)

- or a receiver for evaluating some code (the class is then receiver class, no need to pass anything)

- or a context for evaluating code in a debugger (the receiver is then the context receiver, and the class is the receiver class)

Then we may pass an environment if not the default (for resolving global vars).
All these are in the CompilationCue.
And finally, a failBlock is most often provided.

Having messages for union of these cases does not sound the right thing to me.

Looking at usage, we see 1/3 of nil passed as parameters, which stinks.

I already shrinked the nil passing a bit, and removed a few methods, but I feel I did not go far enough.

The big ones:
-----------------

A possibility is to expose the CompilationCue (CompilationContext?).

The instance creation messages could hold the minimal requirements:

- source:class:

- source:receiver:

- source:context:

Same with sourceEditor: if it ever replace source, otherwise this could just be an instance side setter.

Then we could either add messages with the optional environment: parameters, or just let it be an instance setter too...

I'm not at all convinced about exposing the helper class, but maybe something like this:
. (Compiler forEvaluating: aString in: receiver) parseIfFail: failBlock

. (Compiler forEvaluating: aString in: receiver) compileIfFail: failBlock
. (Compiler forEvaluating: aString inContext: aContext) evaluateIfFail: failBlock

. (Compiler forCompiling: aString inClass: aClass) formatIfFail: 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).

Since Compiler is only a facade, we could have two facades instead, (Evaluator forSource: aString receiver: anObject) and (Compiler forSource: aString class: aClass).
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...

timrowledge

Re: Compiler detox

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.

Eliot Miranda-2

Re: Compiler detox

Hi Tim,

On Thu, Sep 19, 2013 at 7:27 PM, tim Rowledge <[hidden email]> wrote:

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 ;-)

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.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Error 13: Illegal brain function. Process terminated.

--
best,

Eliot

Nicolas Cellier

Re: Compiler detox

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...

It's a bit less clear with Decompiler which is not in a healthy state.
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]>

Hi Tim,

On Thu, Sep 19, 2013 at 7:27 PM, tim Rowledge <[hidden email]> wrote:

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 ;-)

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.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Error 13: Illegal brain function. Process terminated.

--
best,
Eliot