yeti to javascript compiler

[chrisichris]

Hi,

The last month I'v tried to hack together a yeti to JavaScript compiler. And well by surprise it somehow works. It is certainly still buggy but compiles (with a little help and nearly) all the examples and passes most of the test.yeti.

You can find it on github. https://github.com/chrisichris/yetiscript In the wiki there is a page on the differences to yeti otherwise it compiles normal yeti code.

All the hard work is already done in the yeti-code base by Madis, what I did is more or less just add another phase after the analyze phase and transfer Parser's Nodes to javascript, by copying what the YetiAnaylzer for (Java)Code does into a JSAnalyzer. I didn't want to touch the YetiAnalyzer too much to not break the typechecking so it still creates the (Java)Code (which is just not written to disk). This can certainly be removed and maybe the JSAnalyzer be integrated into the YetiAnaylzer - will see. Apart of this there is not much more (a bit JavaType changing and a bit in the parser - a new keyword script)

Best you read the differences doc in the wiki and hopefully try it out.

Chris

  

[Chris Cannam]

On Sun, Nov 9, 2014, at 12:17 PM, chrisichris wrote:
> You can find it on github. https://github.com/chrisichris/yetiscript In
> the wiki there is a page on the differences to yeti otherwise it compiles
> normal yeti code.

Interesting -- so this is indeed Yetiscript rather than Yeti, i.e. a
Yeti-syntax front end for Javascript semantics, rather than a
"Javascript-platform implementation of Yeti" as such? That seems a
sensibly pragmatic approach.

The lack of lazy lists would break quite a lot of my code and the way I
think about it, but apart from that the restrictions listed look
workable (if annoying, like the scoping thing).


Chris

[Madis]

On Sun, 9 Nov 2014, chrisichris wrote:

> Hi,
>
> The last month I'v tried to hack together a yeti to JavaScript compiler. And
> well by surprise it somehow works. It is certainly still buggy but compiles
> (with a little help and nearly) all the examples and passes most of the
> test.yeti.
> You can find it on github. https://github.com/chrisichris/yetiscript In the
> wiki there is a page on the differences to yeti otherwise it compiles normal
> yeti code.

It's nice. I actually originally envisioned multiple backends, but the
real implementation (and also language) became to dependent on JVM.

> All the hard work is already done in the yeti-code base by Madis, what I did
> is more or less just add another phase after the analyze phase and transfer
> Parser's Nodes to javascript, by copying what the YetiAnaylzer for
> (Java)Code does into a JSAnalyzer. I didn't want to touch the YetiAnalyzer
> too much to not break the typechecking so it still creates the (Java)Code
> (which is just not written to disk). This can certainly be removed and maybe
> the JSAnalyzer be integrated into the YetiAnaylzer - will see. Apart of this
> there is not much more (a bit JavaType changing and a bit in the parser - a
> new keyword script)

For now I think it's easier to maintain as fork. For most practical
purposes it's a separate language/dialect, as it doesn't have Java
exceptions and libraries, that most Yeti code uses somewhere directly.

I added the YetiScript link to Yeti home page.

[Christian Essl]

Thanks for the feedback.

Actually I am not sure about the lazy lists. Technical it is no problem to implement them. I mainly did it (for now) this way because it interfaces best with JS and native JS-arrays are fast (and of course it is no work to implemnet). Instead I thoguht to add an opaque sequence-type for lazy collections and as a wrapper for ES6 iterators but this would be no list just (next is sequence<'a>  Some 'a | None ()) . But I am not sure, feedback wellcome.

I think the scoping will remain like it is it makes the JS code much more readable and I personlly trie to avoid shadowing anyway - but also this is of course open to discussion.

Chris

--
You received this message because you are subscribed to the Google Groups "yeti-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yeti-lang+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christian Essl]

Thanks for adding to the homepage.

And thanks that you agree to have it as a fork. Should I add any extra credits to yeti in the readme or somewhere else? There are (smale) but significant enough changes to your source. It would be hard to keep both in one codebase.

  

--
You received this message because you are subscribed to the Google Groups "yeti-lang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to yeti-lang+unsubscribe@googlegroups.com.

[Madis]

On Fri, 14 Nov 2014, Christian Essl wrote:

> Thanks for adding to the homepage.
> And thanks that you agree to have it as a fork. Should I add any extra
> credits to yeti in the readme or somewhere else?

It has links to the Yeti home page, so it seems to give credit.

[Chris Cannam]

On Fri, Nov 14, 2014, at 03:15 PM, Christian Essl wrote:
> Actually I am not sure about the lazy lists. Technical it is no problem
> to implement them. I mainly did it (for now) this way because it interfaces
> best with JS and native JS-arrays are fast (and of course it is no work
> to implemnet).

Naively I'd have thought the Yeti type that corresponds to a Javascript
array would be... an array. What would be the pros and cons of mapping
arrays to arrays and (lazy) lists to a list type as you describe?


Chris

[chrisichris]

On Saturday, November 15, 2014 1:48:16 PM UTC+1, Chris Cannam wrote:

On Fri, Nov 14, 2014, at 03:15 PM, Christian Essl wrote:
> Actually I am not sure about the lazy lists. Technical it is no problem
> to implement them. I mainly did it (for now) this way because it interfaces
> best with JS and native JS-arrays are fast (and of course it is no work
> to implemnet).

Naively I'd have thought the Yeti type that corresponds to a Javascript
array would be... an array.

 It is - both lists and arrays are currently JS-arrays.  

What would be the pros and cons of mapping
arrays to arrays and (lazy) lists to a list type as you describe?

I have done now some rough performance tests and (to my surprise) linked-lists are a bit faster than array. (And of course they get faster and faster the more transformation you add). But both are very fast and there is not so much difference on V8 especially with the build in map/filter/reduce functions of V8. Just construction using (::) is much faste with linked-lists.

So performance wise there is not much difference other wise I have the following pros/cons 

pros - for having a differnt implementation for lists:

- closer to yeti

- as you say have two data-structures with different characteristics

- lazy lists (+ transformations)

- slightly more performant

- more save from accidental muatation - but not guranteed 

cons:

- have to cast when using with JS

- less clear semantics regarding sideeffects (ie when was/will be the mapping performed, is the result cached or is it reevaluated each time the value is accessed etc). Arrays are always immediate evaluated and just once.

- lazy lists are very dangerous for memory-leaks (as you have pointed out)

The last point (memory-leaks) is my main concern. I think in JS with all its events and async functions lazy-infinte-lists will be much more used than in 'traditional' JVM enviroments.  So I'd rather have a seperate sequence/iterator type for that instead of the :. operator to encourage use of that type instead of lazy lists.

  

Chris