On compiler architecture

> In response to not-so-optimized code actual compiler produces, I began
> to write down ideas of the intermediate compiler I produced some year
> ago here: https://gist.github.com/herby/7266982 (and which was used as
> starting idea for the actual one).
>
> It contains more dynamic aliasing system than the actual one, but alas I
> have only been able to write down the first boring part at the moment.
> The interesting part with early commits (see into it to know what it
> mean in this context :-) ) will appear later (hopefully tomorrow).
>
> I will be glad if you looked at it and found bugs or comment the ideas
> or possibility to use to enhance existing compiler. Thanks.
>
> Herby
>
> --
> You received this message because you are subscribed to the Google Groups
> "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/groups/opt_out.
>

> Thank you, Herby for posting the reference to your writeup a year ago
> https://gist.github.com/herby/7266982
>
> You mention three compilers just under the heading '
>
>
> I assume you mean
>
> 1)  The original (0.9.1) Amber compiler was written around the
> metaphor of “everything is an expression”.
>
> 2) The compiler in version 0.12 (= the current one) 'new multilayer
> OPAL-structured compiler '
>
>
> 3) A proposal for a next compiler
> '‘everything-is-a-postponed-assignment’ (eiapa)'
>
>
> Is this correct?
>
> --Hannes
>
> On 11/1/13, Herby Vojčík <[hidden email]> wrote:
>> In response to not-so-optimized code actual compiler produces, I began
>> to write down ideas of the intermediate compiler I produced some year
>> ago here: https://gist.github.com/herby/7266982 (and which was used as
>> starting idea for the actual one).
>>
>> It contains more dynamic aliasing system than the actual one, but alas I
>> have only been able to write down the first boring part at the moment.
>> The interesting part with early commits (see into it to know what it
>> mean in this context :-) ) will appear later (hopefully tomorrow).
>>
>> I will be glad if you looked at it and found bugs or comment the ideas
>> or possibility to use to enhance existing compiler. Thanks.
>>
>> Herby
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "amber-lang" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [hidden email].
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>

> Thank you, Herby for posting the reference to your writeup a year ago
> https://gist.github.com/herby/7266982
>
> You mention three compilers just under the heading '
>
>
> I assume you mean
>
> 1)  The original (0.9.1) Amber compiler was written around the
> metaphor of “everything is an expression”.
>
> 2) The compiler in version 0.12 (= the current one) 'new multilayer
> OPAL-structured compiler '
>
>
> 3) A proposal for a next compiler
> '‘everything-is-a-postponed-assignment’ (eiapa)'
>
>
> Is this correct?

> Hey,
>
> just wondering, with the JS specific output stream of the current compiler,
> if you would want to implement a dart backend for Amber, would it be
> possible to only add an extra IRDartTranslator (instead of IRJSTranslator),
> or would you need to edit the whole compiler ?
>
>
> 2013/11/2 Herby Vojčík <[hidden email]>
>
>>
>>
>> H. Hirzel wrote:
>>
>>> Thank you, Herby for posting the reference to your writeup a year ago
>>> https://gist.github.com/herby/7266982
>>>
>>> You mention three compilers just under the heading '
>>>
>>>
>>> I assume you mean
>>>
>>> 1)  The original (0.9.1) Amber compiler was written around the
>>> metaphor of “everything is an expression”.
>>>
>>> 2) The compiler in version 0.12 (= the current one) 'new multilayer
>>> OPAL-structured compiler '
>>>
>>>
>>> 3) A proposal for a next compiler
>>> '‘everything-is-a-postponed-assignment’ (eiapa)'
>>>
>>>
>>> Is this correct?
>>>
>>
>> Well, in a sort; in fact I believe the current one is fine except too
>> static aliasing logic, so it can be inspired by more late-bound aliasing
>> and on-demand burst output via commits, otherwise, it bring lot of good
>> things there (semantic analyzer; instructions phase; JS-specific output
>> stream).
>>
>>  --Hannes
>>>
>>
>> Herby
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "amber-lang" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [hidden email].
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/groups/opt_out.
>

>
>
> Herby Vojčík wrote:
>> It contains more dynamic aliasing system than the actual one, but alas I
>> have only been able to write down the first boring part at the moment.
>> The interesting part with early commits (see into it to know what it
>> mean in this context :-) ) will appear later (hopefully tomorrow).
>
> It is not as fast as it can be, but I got a few steps forward, and it
> already contains one tricky code example. You can see how it works with
> more complex examples and see it's advantages.
>
> What's more, during writing it and playing with current compiler, I
> found two bugs of the current compiler, one crash during compiling, one
> producing incorrect code.