notes.txt

The general change to the grammar looks like the following:

NEW:

options ::= { <id> = <id> (, <id> = <id>)* }

plugins ::= <id> [<options>] (, <id> [<options>])*

MODIFIED:

exp     ::= ...
          | [ .<id>: <tyident> [<options>]]

typdesc ::= ...
          | <typdesc> [ [.deriving <plugins>] ]

datdesc ::= ...
          | <datdesc> [ [.deriving <plugins>] ]

gonna need one for datatype replication too... ugh

dec     ::= ...
          | TYPE <typbinds> [ [.deriving <plugins> ] ]
          | DATATYPE <datbinds> [<withtypee>] [ [.deriving <plugins>] ]

gonna need one for datatype replication here too


- [x] add parsing support for [.deriving] on typdescs, datdescs, typedecs, datdecs
- [ ] add parsing support for [.deriving] on datrepls
- [X] add parsing support for [.show: ...] expressions
- [X] revamp `transform` structure
      NOTE: maybe not possible... `transform` needs to work at a higher
      granularity, since decs may be expanded into more than just one dec.
      For now, hardcoded on `spec` and `dec`.
- [X] add codegen for show
- [X] add codegen for eq
- [X] add codegen for ord
- [X] add codegen for map
- [X] add parsing support for NJ-extensions (or-patterns, functor sugar)
- [X] add ability to derive all files in an SML project from CM
- [X] add error messages

- The parser we're using (from mlc) was never intended for altering source text.
  - This parser was meant to be used for a compiler, meaning that it strips down
    some of the literal syntactic information for equivalent semantic information.
  - In particular, something like `op+ (1, 2)` is represented the same as `1 + 2`.
  - This means that recovering the original program is impossible.
  - As such, we're constrained so that `deriving` should work "invisibly", and not
    show anything that it generates. Granted, this is how OCaml's works too, so
    maybe it's fine.
- currently, we're zeroing out location data with absurd because code insertion
  fucks literally everything up
  - it's possible that we can alter the tokens to be more friendly by making
    tokens work "relationally", and store offsets from nearby tokens, as opposed
    to exact data
- It would be nice if derive expressions gave error messages for improper usage.
  - For instance, you could have an error for:
    1) invalid number of tyargs (e.g. `[.show: (int, int) option]`)
    2) nonexistent types (e.g. `[.show: type_which_doesnt_exist]`)
  - The first way is dependent on knowing the arity of type constructors at
    parse time, which is perhaps impossible without very significant overhaul.
  - The second way is to have an extra `Ederive` variant, and push back derive
    expression rewriting to transform time. This will also necessitate that
    `Context`s store modular scope information.