[RFC] `veery` lang transpiler to `wren` lang

[mhermier]

Hi,

I would like to talk about a new language veery that I've been thinking/working on for a while, and that started to be functional recently (but still need a lot of love).

Merging pieces from wren repl with wrenanalyzer (with some small fixes to both), I achieved to make a self hosted transpiler. While supporting the veery language is the main goal, the idea is to make a full featured compiler infrastructure (maintaining the transpilation, repl and ideally generating some executable files of some form). That way both language can benefit from that compilation infrastructure. I think that later I will support more languages but it is a low priority for now.

As of today, veery lang is a small deviation of wren:

• Added support for builtin operator === and !== (short hand for Object.same(_,_))
• Added support for a native character type using the usual C syntax 'a'.
• A very (very very) limited support for constant folding (aka remove the dead branch if (false) {} else {} to prove that AST transformation work). But I plan to add more changes so it does feel better to my taste.

The idea would be to have a unique tool like:

veery // launch a veery repl
veery --std=wren-0.4.0 // launch a wren repl compatible with the 0.4.0 syntax
veery analyze --std=wren-0.4.0 my_program.wren // improved version of wrenalyzer
veery compile --target=wren-0.4.0 my_program.veery -o my_program.wren
veery format my_program.veery // a source reformatter

Currently I have early stages veery-c(compiler) and veery(straight wren-repl) to prove everything work, until I try to merge both.

I'm currently thinking about how to distribute it. Currently the "bootstrap" compiler is in the same git tree as the rest of the libraries and utilities, and I am debating of splitting it...

I think it could be an interesting experiment, so users can more easily toy with the compiler/transpiler to implement their own syntax sugar changes, features and tools. (Thought it requires a little bit of effort in case of error since source line numbering are not preserved).

Comments ? Ideas ?

[PureFox48]

Although I know that you have strong views and many ideas on how you'd like to see Wren develop, I didn't know that you had plans for an entirely new language. I couldn't find a repo for it on Github though I imagine you'll be creating one in due course so people can play around with it.

Anyway, I gather that Veery's parser is creating AST structures rather than emitting code directly as Wren's VM does at present. With the help of bits from the Wren repl and wrenalyzer, that has enabled you to create a Veery to Wren transpiler and transpilers for other languages may be on the cards in future.

If there were a transpiler to C or C++ (say), then that would be an exciting development as we'd then only be a step away from having an AOT native code compiler for Veeery/Wren!

Of the three features you mention, I can't say I'm bothered about the first though I would welcome character literals being added to Wren itself - either as a new primitive type or just as an alias for the corresponding codepoint. The third is probably too difficult and not worth the effort.

Incidentally, I see that you're maintaining the ornithological connection as Veery is a type of thrush :)

[mhermier]

Although I know that you have strong views and many ideas on how you'd like to see Wren develop, I didn't know that you had plans for an entirely new language. I couldn't find a repo for it on Github though I imagine you'll be creating one in due course so people can play around with it.

For now, I'm looking to see how much traction the idea can have. For me, veery is more a playground where I can put some idea I have and remove some of the frustrations I have with wren. While I want to be its own thing, it also serve as a test place to back port some of them to wren

Anyway, I gather that Veery's parser is creating AST structures rather than emitting code directly as Wren's VM does at present. With the help of bits from the Wren repl and wrenalyzer, that has enabled you to create a Veery to Wren transpiler and transpilers for other languages may be on the cards in future.

If there were a transpiler to C or C++ (say), then that would be an exciting development as we'd then only be a step away from having an AOT native code compiler for Veeery/Wren!

This is one of the future goals, but I think the code must be consolidated a lot first.

It can also be used as a tool to automagically produce the module boiler plate in a standardized way.

Of the three features you mention, I can't say I'm bothered about the first though I would welcome character literals being added to Wren itself - either as a new primitive type or just as an alias for the corresponding codepoint. The third is probably too difficult and not worth the effort.

Right now, Character is a class (unique instance per code point optimization). It doesn't interact greatly with string and hashes. But it is easier to convert a string[i] to a Character, than managing the "madness" of:

https://github.com/wren-lang/wren-cli/blob/18553636618a4d33f10af9b5ab92da6431784a8c/src/module/repl.wren#L408-L467

Incidentally, I see that you're maintaining the ornithological connection as Veery is a type of thrush :)

Don't tell anyone it is a secret ;) In addition, I found it short and funny because it also read as very XD so it sounds like a good choice.

[PureFox48]

Don't tell anyone it is a secret ;) In addition, I found it short and funny because it also read as very XD so it sounds like a good choice.

Sorry if I've already let the cat out of the bag ;)

It is a good name and one that doesn't appear to have been used before for a programming language.