Roadmap

[mkhan45]

To start out with, we want

• [X] Basic expression eval
• [X] Tuples
• [X] Pattern matching variable bindings
• [X] Lambdas
• [X] Basic CLI/REPL
• [x] Lists
• [X] Match expression (a9981e148f586e)
• [X] _ pattern #12
• [X] Match guards #14
• [X] Comments #7
• [X] Block expressions #7
• [x] Maps #19
• [X] Tail Call Optimization #10
• [X] Strings #33
• [x] Atoms #27
• [X] Good error messages (mostly fixed by 391eea8, though better ones would be nice)

Eventually it would be cool to have:

• [ ] An AST optimization pass
  • [x] Function inlining
  • [x] Convert atoms to ints #27
  • [x] Convert idents to ints (should be a ~25% perf boost) (ad4b298e333b)
  • [ ] Inline simple assignments to an existing variable, or assignments which are only used once
• [x] A pipe operator (b011436)
  • [X] Function Captures
• [ ] A module/import system with multiple file support
• [x] A web server module in the stdlib
• [ ] Records/named tuples
• [ ] Macros
• [ ] Named/optional arguments?

[mkhan45]

named/optional arguments seem unnecessary since we can just use a map as an argument with pattern matching, but maybe there could be some syntax sugar

[mkhan45]

We also need proper error messages, to start out we'd have to revamp the scanner so that we can pass line number and maybe column information to the parser

[mkhan45]

records/named tuples might also be unneeded with maps

[mkhan45]

I've considered it don't think we should have variadic lambdas anymore. They're significantly slower than just having multiple functions unless we implement it as syntax sugar, which has other problems. Since we have a match expression already it also seems a bit excessive and doesn't work well with the let name = fn(args) => expr syntax

[WilliamRagstad]

We also want the interactive REPL to not crash when an error occurs, but keep the previous state.

[mkhan45]

I've made #22 for that

[mkhan45]

currying might cause hard to debug errors, since error reporting is pretty minimal right now

[mkhan45]

Inlining functions at preprocess time might be impossible since little is known about the functions called. However, it might be possible at runtime on a block by block basis

edit: alternatively, we could add an inline keyword

could also mark a function body as inlineable at definition time, and then actually in-line it at call time

[mkhan45]

it might be possible to make a non tail recursive function tail recursive via ast transformation to use an accumulator in simple cases or by adding a stack accumulator in more complicated ones

edit: https://en.wikipedia.org/wiki/Continuation-passing_style