/
CHANGELOG
34 lines (28 loc) · 3.9 KB
/
CHANGELOG
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
1/27/2020
(Work done on the syntax improvements below also included updates to the documentation.)
- Update the tests and bootstrapped files to use the new `[]`-based syntax (from last week).
- Add support for `deriving` clauses in `data` declarations.
- Add support for `deriving` clauses in `newtype` declarations.
- Fix a bug where `newtype` declarations would transpile invalidly when the wrapped type did not need to be wrapped in parentheses (i.e. was just a type name).
- Add support for multiline comments.
- Add support for multline strings.
- Add support for operator sections.
- Add support for `@`-patterns.
- Make Haskell-operator-symbols be valid as macro names (e.g. `|` is now valid as a macro name).
- Add support for guards in function definitions.
1/20/2020
Tabling the Polysemy issue for now (until transitivity can hopefullybe implemented library-side).
- Use lists where appropriate in syntactic forms: Wherever lists of things are used in syntactic forms, e.g. bindings in `let <bindings> <body>`, we now wrap them with `[]` instead of `()`. This makes the structure of the command a bit clearer, and also allows for more flexibility. Specifically, this will pave the way for a `[]`-delimited list at the end of a `data` form to be the list of typeclasses to derive (since otherwise, we'd have to 1) have a different `data` form, 2) wrap the data constructors in a parenthesized list (which would add a lot of syntactic noise), or 3) add some sort of `deriving` keyword).
12/8/2019
- Finish migrating bootstrapping-critical functionality to Cabal 3.
12/1/2019
- [WIP] I now believe the issue from last week is a bug in Polysemy after all (involving polysemy-research/polysemy#114 and existential types). Regardless, I've spent way too much time on this issue, so I've tried to bake in the fact that `Sem.Reader ExpansionId` must be the first item in `openEffs`. This... also doesn't work, and I'm not sure why. It's likely my mistake, but reasoning about this (and pinpointing errors) is very difficult (for me, at least). See stash 46f7170d3106d46dad25c67e1b88fa5dd1cb4431. Next week, I am going to try to, instead of only prepending `firstEff` to `openEffs` in the constraint, also do so in the result type effects list.
- [WIP] Began migrating to Cabal 3. Migrating the basic infrastructure itself was trivially easy (much more so than I had expected), but I forgot about what this would mean for Axel's usage of Stack under-the-hood! Specifically, since Axel relies on projects using Stack, it's not able to compile itself anymore. I don't think it'll be particularly difficult to replace the Stack dependency with one on Cabal (in e.g. the project generation code), but it'll probably be time-consuming.
11/25/2019
- [WIP] Still working on the issue from last week. However, there's a good chance it's actually not a bug in Polysemy after all (but I'm continuing the conversation with @isovector to try to fully understand what's going wrong).
- Researched how to integrate the PureScript compiler. I'm having difficulty getting `purescript` to install via Stack(age). Now that Cabal 3.0.0 has been released, it might finally be time to switch to Cabal for good.
11/17/2019
- [WIP] Continued work from last week. While wiring everything up, Polysemy became very, very unhappy. I spent some time trying to figure out what I was doing wrong, but with no luck. Eventually, I ended up removing `Sem.Reader (Backend backendEffs)` altogether in favor of just passing `Backend backendEffs` around as a parameter. I've since been running into what I think is a variation of https://github.com/polysemy-research/polysemy/issues/280 (which I opened yesterday after finding an MVCE).
I'm not too great with typeclass-fu, so this is taking a bit longer than I had anticipated (unfortunately).
11/10/2019
- [WIP] Break out Haskell-specific code in `Axel.Macros` into a `Backend` interface. Adapt `Axel.File` to use this new system.