I don't get this. Heres Fibonacci[1] in only 74 lines of YAML, or how about some kind of football CLI program[2] in only ~600 lines of YAML. I've got no idea why anyone would use this, or why the hell YAML was chosen to represent the AST.

Edit: Not to crap over the authors project, it seems to produce quite neat output[3][4], it's just writing 600 lines of unreadable YAML to generate a ~32 line Python program seems a bit pointless.

1. https://github.com/alehander42/pseudo/blob/master/examples/f...

2. https://github.com/alehander42/pseudo/blob/master/examples/f...

3. https://github.com/alehander42/pseudo/blob/master/examples/f...

4. https://github.com/alehander42/pseudo/blob/master/examples/f...

You apparently missed the original.py files in each of those directories.

Here is fib: https://github.com/alehander42/pseudo/blob/master/examples/f...

There is also fib.py, which seems to be the Python output of the original.py input. The other examples are better to look at in this regard.

I believe the yaml file is either an intermediary or just another output format.

See also README.me: https://github.com/alehander42/pseudo/tree/master/examples/f...

> Pseudo AST

> Generated from original.py using pseudo-python

Yep, you're not supposed to write the yaml yourself, it's just a compilation target and an intermediate format.

Why YAML then? Well it's still nice to be able to read it easily in that early phase of the project and it's fairly well supported in most popular languages(and a little bit more compact than JSON).

I would guess the idea is to create some intermediate representation to transpile between languages. The yaml is then probably not meant to be read or written manually.

This could be used in software modelling tools that use a more declarative style, which then creates that IR, which then compiles to some real world language.

I'm not saying this is a good idea, just trying to guess the intention ;) 15 years ago somebody would have used XML and created an even more verbose OMG standard based on such an idea.

I'm pretty sure that there is a XML based intermediary and associated OMG standard. But I value my sanity so I'm not going to go look it up.

Also this reminds me of the Haskell AST in "JSON format" that is available as one of the Pandoc output formats.

Coq can be translated to Ocaml and Haskell: https://coq.inria.fr/faq#htoc181

Ocaml can be translated back to Coq: https://github.com/clarus/coq-of-ocaml

I really like this and think it could be very useful. You're really on a roll, alehander42, with pseudo and hivemind both on the HN front page the same weekend.

Regarding pseudo, could you explain a little about your testing strategy? How rigorous are you able to be in verifying that your code generators are generating code that compiles/runs properly and outputs the correct data?

And do you have plans for targeting other languages (C or PHP maybe)?

Oh yes, my plans for v0.3 include adding support for at least 2-3 of Java, Swift, PHP, Perl and C.

My goal with the first 5 was to choose several very different languages in order to prepare Pseudo to deal with all of them efficiently instead of skewing it to be e.g. best for dynamic ones. That's why it's a lot less work now to add support for other languages, because most of the time one can bootstrap their tests and generators from already implemented ones.

Testing: Currently there is a suite covering almost all functions of pseudo's standard library and most of the AST nodes. However it was basically a by-product of TDD(I was surprised how well TDD works for that kind of project). Now, when I am closer to a more stable 0.3 version, I'll probably:

* Generate a lot more examples in Python

* Generate Pseudo AST nodes from them, check for incorrect ones and use them as a test suite for Pseudo-Python (because I've only tested Pseudo until now)

* Reuse the already proven correct AST examples in Pseudo's suite and apply the same strategy to test for the target language input

* Add tests that run and check the result files in their target language to the current travis ci infrastructure (it would be easy to target several supported versions of each of them that way)

Totally awesome! I was just about to make exactly this tomorrow, now I don't need to.

My problem is that I would like to generate wrappers for an API, in a variety of popular languages. I could just implement each wrapper separately by hand, but maintaining them as the API changes would be obnoxiously difficult.

It looks awesome! I really like the idé to write once and compile to everything. However I do not have much experience in this field. How does this differ from the current popular approaches, example Haxe? When should I use this and when should I use Haxe?

Thank you.

The goal of Pseudo is to create idiomatic and readable code in the target language, it should look exactly as a human wrote it in order to be useful for bootstrapping codebases in other languages or maintaining code in several languages(basically for cases when developers would continue working on the generated code)

Haxe's output isn't alien or too-machine-translated-like, but it's not optimized for that goal too.

Pseudo's intermediate format is `pseudo AST`, and it's supposed to be a target for various tools: compilers, parser generators etc. That would make it even possible to convert between different languages for the same codebase(I don't recommend it, but it can be useful). As far as I am aware, Haxe isn't meant to be a compiler target.

Pseudo makes it a lot easier to add support for a new language or a library. It's written in Python and it uses a very declarative/template-like approach: https://github.com/alehander42/pseudo/blob/master/pseudo/gen...

And, according to Haxe docs: > These are the technical skills you must achieve to create a compilation target for Haxe: > ... > Learn Ocaml > Understand Haxe compiler sources

It will try to support a lot more languages, including functional languages(it does already support Go and Ruby, which aren't supported byHaxe).

Beware that Pseudo is still in early stages. If you think you have an use case, I will be happy to discuss it, but it's still unstable and experimental.

This could be a useful tool when learning a new language, if the output really is idiomatic pretty code. You could convert some familiar code in one language to another language you want to learn.