About an eiapa compiler

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

About an eiapa compiler

Nicolas Petton
Hi,

Herby, I like your page. The idea is indeed very nice, and I think that
with the semantic analysis, we could make it happen.

Some thoughts about it:

- AST annotations will allow us to do it easily
- We could make a different IR that *is* the output of the eiapa
  compiler, directly translatable to JS with a JSStream

Are you willing to work on that? If so, we could discuss on IRC and
maybe do some pair programming sessions together?

Cheers,
Nico

--
Nicolas Petton
http://nicolas-petton.fr

--
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.
Reply | Threaded
Open this post in threaded view
|

Re: About an eiapa compiler

Herby Vojčík


Nicolas Petton wrote:
> Hi,
>
> Herby, I like your page. The idea is indeed very nice, and I think that
> with the semantic analysis, we could make it happen.

It's not yet finished, there should came the hard part about blocks and inlining. Block are pushing this idea to its boundary and only work with some special hacks, but fortunately, it's all that is left (everything else is already covered).

> Some thoughts about it:
>
> - AST annotations will allow us to do it easily

Well, I'd be aware. AST annotations can help, but the dynamics of it may be lost in the process (the same way as actual static, pre-compiled $-variables are). There can be chain of aliasing variables assigned to each other, so single Node annotation seems not enough to me (though I don't know what you see there is possible).

When I thought of the implementation, it seemed to me that dynamically growing and shrinking AST tree is the possible answer - wrapping subexpression as a right side to the dynam
ically-created AssignmentNode (annotated as 'virtual'), removing it when embedding non-value, removing the 'virtual' annotation when materialized - something in that direction. But maybe when one analyzes it deeper, shortcuts can be found.

> - We could make a different IR that *is* the output of the eiapa
>    compiler, directly translatable to JS with a JSStream

Yes, I thought of possibility to have such instructions, more or less every one being MOV with virtual targets. The thing that I mentioned at the end is interesting question - if it is possible to delay commits completely, thus creating just the stream of MOVs in the first phase, then maybe include inlining information that changes some MOVSEND into MOVINLINE, and then finally doing the commits and related materializations.

> Are you willing to work on that? If so, we could discuss on IRC and
> maybe do some pair programming sessions together?

Willingness there is, but the time is not, at the moment, I will see i
n some time depending how the actual project I work on will go.

> Cheers,
> Nico

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.