Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request - keep comments in generated code #26

Open
Quentie opened this issue Jun 27, 2022 · 6 comments
Open

Feature Request - keep comments in generated code #26

Quentie opened this issue Jun 27, 2022 · 6 comments

Comments

@Quentie
Copy link

Quentie commented Jun 27, 2022

Thanks @LingDong- for your nice little language!
The generated code is really clean and very close to the wax code.

I think it would be really nice if we had the option to keep the comments from wax code in the generated target code.

Not sure if everybody would like this. Maybe an optional compiler flag like --keepComments or a second syntax for comments that should be kept could be introduced?

@jacoblister
Copy link

jacoblister commented Jul 14, 2022

Hi @Quentie,

This project has sparked quite a bit of interest for me, and I've got a separate implementation going, which can target JavaScript, C++ currently. It's really scratched an itch for me in terms of having a super lightweight language definition that's easy to parse and process, and can target multiple transpilation languages.

It does a fair bit, including some basic DOM integration to allow writing HTML/SVG content into a browser window. Error handling's not so great at the moment, does have a good test suite though.

If there's interest, I can put it in a public git repo. Just having a look at how I'm handing comments - currently I strip them to make the code generation phase easier, but I do have a wax language target which can process wax in/wax out for reformatting purposes - and that leaves comments intact, so it can be done.

@mationai
Copy link

@jacoblister Would love to see it

@jacoblister
Copy link

@fuzzthink - I've added a clone of my wax language implementation at https://github.com/jacoblister/rewax

It's pretty rough, but it should build - on Linux at least, or in VSCode with Docker. There is a .devcontainer in the project to setup an Ubuntu docker container in VSCode. Mostly it needs the node environment to bootstrap it for this.

git clone https://github.com/jacoblister/rewax
cd rewax
make test

will run all the test cases. For example:

./wax build --target=js test/prog_fib.wax
./wax build --target=cpp test/prog_fib.wax

will generate the currently implemented javascript and c++ targets

If you're really lucky, svg dom bindings at.

cd vdom/example
make
./svg (linux build)
or
./serve.sh (javascript version, at http://localhost:8080/example.svg

Cheers

@Quentie
Copy link
Author

Quentie commented Jul 18, 2022

Hi @jacoblister this is looking good.

@jacoblister
Copy link

jacoblister commented Jul 18, 2022

Yeh it's working pretty well.

The approach I've taken is to do a straight syntax translation as much as possible, and have the target language do the heavy lifting in terms of symbol resolution/type conversion etc. As such, the implementation can be very simple (the initial prototype I did was <1000 lines of code).

Ultimately I'd really like to get this running as just in time compiler, and generating native machine code on the fly - but this would involve implementing a symbol table, and a type conversion system. With only a dozen or so language elements in the core language spec, the actually machine code generation part should be quite simple though. There's a partial implementation in the file 'symbol.wax', but I wouldn't recommend looking at it - it's horrible. The JS and C++ targets don't use it, there is a C language target which does, but it's only partially implemented.

The C target is partially implemented, and doesn't support dynamic memory allocation. I'm able to generate C code from this and compile it with the TinyCC compiler on the fly https://bellard.org/tcc/. For the JavaScript target, eval() can do this. I'm using this generated code for audio DSP, which doesn't need a lot of language features.

@jacoblister
Copy link

jacoblister commented Jul 18, 2022

Just to mention a few extra language features too, check the test_extended directory.

I've deliberately not wanted to add much, as having a core language spec that's so simple is the real attraction, but first class functions are must have to my mind - being able assign a function to a variable, and pass to and return from another function.

Conveniently that didn't involve changing the language spec at all, and they fit in quite nicely

func.wax demonstrates this. This feature is used to register event handlers in the DOM api.

there's also an attempt at GoLang style interfaces using this in 'interfaces.wax' building on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants