To be done

[aboeglin]

Features:

• Make inference work for recursive functions
• Pattern match List
• Pattern match String
• Error reporting and formatting : WIP
• Support Arrow args for ADTs ( data A = A (Num -> Num) )
• Record deconstruction ( Patterns )
• Record spread operator
• String literals character, replace double quotes with single quotes or back ticks ( preference seems to be for back ticks )
• Rename switch / case ( where / is ? )
• Wrap up compilation of patterns and check ADT types correctly in generated JS code ( using __buildCtorParam )
• Define and implement a first CLI : WIP
• Add operators && and ||, >, >=, <, =<, !
• Add missing operator: - ( unary ), ...
• Verify and complete places where returns are allowed within expressions
• Tuples solving/compiling
• Tuple pattern matching
• Tuple typing
• Update comments and use // instead of —
• Make curlies optional ( where, if, more ? )
• Add ternary expression grammar
• type aliases
• bundle compiler option that generates a single js output for browsers : WIP with rollup for now
• Prelude basics
• ADTs should also be exportable and importable ( Also that should go hand in hand with the point below on checking ADT usages )

Code:

• __buildCtorParam should be put in a separate .mjs file that is imported where needed and not directly embedded in the generated js.
• Rework InferError and either split errors ( Infer, Import, xyz ), or keep them unified but then rename them from InferError to simple Error ?
• We need to add some checks on ADT definitions and usage ( Mostly that names being used actually exist ( usage ), or that they don't ( definition ) )
• Improve tests and test a lot more scenarios
• Consider removing Records for Exp as we never have more than 2 or 3 args anyways
• Move pos and type information outside of Exp, so that Exp is cleaner and only concerned about the grammar
• Create a Typed and/or Located type that contains type or location information
• Update grammar so that a Typing, can be defined in two ways:

  •   // Must come right before the function definition, and we just make it a TypedExp Assignment (=) Abstraction x (x+1)
      inc :: Num -> Num
      inc = (x) => x + 1

  •   // Directly attached to an expression and we make it a TypedExp App (App (+) (1)) 4
      4 + 1 :: Num

  That way we can more easily connect the type annotation to the wrong function in case of mismatches and report more precise errors, and it would also make the AST clearer as for now in the case of functions we just assign the TypedExp to a var to be looked up in the env. We could then potentially also remove that entry in the Env ( envtypings :: Typings ).
• Production for TypedExp for abstractions is too confusing and won't work well the way it's done. So we need to split the type and the abstraction to make the grammar simpler, and make it a NamedTypedExp ( that assigns to a name instead of an Exp ), and make the match during desugaring step ( AST.Source -> AST.Canonical )

CI:

• Run tests before publishing a release !

Legal:

• Pick and add licence info

[brekk]

Partial and full work on two tasks here:

• String literals character, replace double quotes with single quotes or back ticks ( preference seems to be for back ticks )
• Started but haven't yet completed: Define and implement a first CLI

#14

[brekk]

I think we're not quite done with everything here, but soon we should cut it off and make new issues, as this issue is rather large.

[aboeglin]

Yeah, also some will probably never be done like returns in expressions. I think that's more an organic thing that will evolve. So we should select the bullets that have a known scope, and put them in their own issue and close this one then ?

[aboeglin]

@brekk
I would just close that for now and eventually take some of it like error reporting into specific tickets / issues ?

[brekk]

@aboeglin Sounds good to me.