Rename desugar to generate

[JSAbrahams]

Relevant issues

Closes #273

Summary

We also restructure the project such that we now have a (1) parse, (2) check, and (3) generate stage. The parse stage has a (1.1) lex stage, which tokenizes input and (1.2) parse stage which parses input. The generate stage has a (3.1) desugar stage, which converts input to an interal representation close to Python code and (3.2) a stage which then converts this to a String representing Python source code.

The lex stage is now also hidden behind the parse interface. Parse takes a string and outputs an AST, as opposed to taking a vector of tokens. This is now produced on the inside.

This is also part of an effort to have some spec live alongside the code instead of some separate poorly maintained repo somewhere. Added README for:

• src (pipeline). This is implicitly also the readme for the pipeline dir.
• generate
• check
• parse

Credits to @casperboone for suggesting that convert be renamed to generate instead, which is more descriptive and more in line with standard compiler terminology.

[JSAbrahams]

Would be cool to include the mamba logo in each README at the top, to make it a bit more colourful.

[codecov[bot]]

Codecov Report

:exclamation: No coverage uploaded for pull request base (develop@a1690fa). Click here to learn what that means. The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop     #275   +/-   ##
==========================================
  Coverage           ?   83.77%           
==========================================
  Files              ?       99           
  Lines              ?     9589           
  Branches           ?        0           
==========================================
  Hits               ?     8033           
  Misses             ?     1556           
  Partials           ?        0           

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[JSAbrahams]

Since we're changing things up anyway, shouldn't we just rename desugar to convert, to make clear that we're converting the Mamba AST to python code. Internally this convert does do some desugaring, but it seems more logical going forward. It wouldn't conflict with the other open PR, and we can just rename this one to make clear that this is the most significant change, and the README's are a bonus of this PR then. (Truth be told I can't be bothered to split this up right now in two PR's)

[casperboone]

Since we're changing things up anyway, shouldn't we just rename desugar to convert, to make clear that we're converting the Mamba AST to python code. Internally this convert does do some desugaring, but it seems more logical going forward.

I agree that it should not be called a desugarer. If you’d like to stick to “standard” compiler pipeline terminology this would be the code generation step. So it may be an idea to call it code generate.

[JSAbrahams]

Since we're changing things up anyway, shouldn't we just rename desugar to convert, to make clear that we're converting the Mamba AST to python code. Internally this convert does do some desugaring, but it seems more logical going forward.

I agree that it should not be called a desugarer. If you’d like to stick to “standard” compiler pipeline terminology this would be the code generation step. So it may be an idea to call it code generate.

Hm good point generate would be even more be descriptive than convert, and bonus points for using "standard" terminology. (I'd been meaning to re-read up on this but life tends to get in the way.)

[JSAbrahams]

Well I don't feel like editing README's forever this week. But expanding on and fixing errors within them will be relatively low-hanging fruit for the coming weeks/months. Also, making iterative changes to README's within smaller PR's will make it easier to focus more on writing quality as we go on. It's not like we need to have perfect README's from day one, just an outline and an indication of where we want README's.