Core PureScript migration

[rolyp]

Root task to capture migration of the following components to PureScript:

• syntax and interpreter
• forward and backward slicing
• prelude

Still to do:

• flatten.fld
• lookup.fld
• mergeSort.fld
• typematch.fld (drop for now)
• rest of prelude.fld
  • floats
    • new Float form for Expr, Expl and Val
    • parse floats
    • support primitives that take/return Float
    • overload log at Int -> Float
    • overload / at Int + Float -> Int + Float -> Float
    • overload pow at Int + Float -> Int + Float -> Float
• graphics stuff:
  • graphical data types
  • graphics.fld module
  • openDatasetAs
  • background.fld
    • comparison operators need Float overload
  • grouped-bar-chart.fld
    • sum needs to curry (+)
    • Pattern mismatch: no branch for Viewport – distinguish missing branch from data type mismatch
    • Viewport is not a constructor of List – fix use of concat to concat2
  • line-chart.fld
    • Pattern mismatch: no branch for Nil – add (error-raising) Nil cases to lookup, head, tail
    • Can’t take head of empty list
      • tickEvery 5 produces -20
        • 2 * 10 ** m is Infinity – oops, ** for integers implemented as /
    • Join undefined – missing Str case for RawExpr
  • comparison operators need String overload
  • stacked-bar-chart.fld
• anonymous variables
  • allow identifiers to start with “_”
  • matching against a “_” pattern produces an empty substitution
  • fix up eval_fwd and eval_bwd rules
  • define join-like operation on variables such that x join “_” = x – problematic: will make variables in scope when it looks like they aren’t
  • roll out to prelude and examples
• “friendly” list syntax
  • infix (:)
    • new pattern parser which builds constructor patterns for infix operators
    • syntactically distinguish regular operators from infix constructors
    • expr_ parser: binaryOp should build a (partial) constructor if operator is infix constructor
    • BinaryApp rule for eval to work with constructors as well as primitives? – not needed till Backtick syntax for infix function names #305
    • (:) needs to have a value; use zipWith example

Done/dropped:

• yarn add –dev purescript spago
• VSCode integration
  • set output and source directories correctly
  • move spago.dhall to workspace root?
• add purescript-parsing dependency
• Test.Parse module with basic test that reads a file
• PureScript CI
• test passing with fluid/example/parser-wip.fld
  • test runner running alongside TypeScript tests
  • set up purescript-spec test framework
• syntax, evaluation and slicing rules for lambda functions
• mutual recursion
  • extend let rec syntax to list of mutually recursive functions
  • extend recursive closures accordingly
  • closeDefs to build environment extension for list of mutually recursive functions
  • closeDefs_fwd
  • fix up eval to apply closeDefs at each step
  • fix up eval_fwd
• arithmetic.fld
• compose.fld
  • with compose defined in same file
  • move compose to prelude.fld
  • migrate successfulParse, parseWithImports, openWithImports
  • migrate loadModule
    • module parser?
    • turn list of let definitions into an environment
• factorial.fld
• filter.fld
• foldr_sumSquares.fld
• length
  • lists
  • primitives loaded before prelude
• lexicalScoping.fld
  • fix up syntax
  • strings
  • support for unary primitives
  • consolidate partial binary applications with unary operations
  • intToStr
  • recursive let parsing (More consistent let/letrec syntax #229)
  • match..as
  • Boolean eliminators
  • Boolean constructors
  • syntax for equality and inequality operators
  • generalise primitives to allow return type Bool
• map.fld
• normalise.fld test case
  • Control.Lazy and explicit fixpoint for recursive grammar
  • keywords, identifiers
  • integers
  • simpleExpr
    • let
    • parenthesised expressions
    • pairs
  • appChain
  • addition – + gets parsed as part of integer literal?
  • multiplication with precedence higher than addition
  • integer division
    • use backtick div notation? – see Backtick syntax for infix function names #305
    • add div to prelude
  • fail if any text not consumed
• pattern-match.fld
• reverse.fld
• zipWith.fld

[rolyp]

@min-nguyen I’ll start implementing a new parser (in PureScript) that will accept our existing examples. I won’t bother building a syntax tree until the PureScript prototype starts coming together.

[min-nguyen]

Ooh okay, I thought I was doing that, sure. Is there anything for me to do in the meanwhile? As in, are the other tasks from #279 on standby for now?

[rolyp]

Sorry, I probably wasn’t clear. You can go ahead with #279 without a parser (i.e. without having a way of turning strings into syntax trees). You can just create syntax trees directly for testing purposes, e.g.:

Cons(Nat(5), Cons(Nat(6), Nil)))

will be a PureScript program whose value represents a Fluid expression (or in this case, value). The #279 task is to define all the datatypes for expressing examples like the above, and enough of an interpreter to evaluate them.

This “migrate parser” task is (conveniently) independent of what you’re doing. I’ll start just by writing a parser in PureScript that accepts all our existing Fluid examples (without creating a syntax tree for them). Then as the PureScript implementation comes together, and we have a rich enough language to represent the old Fluid examples, we can extend the new parser to build a parse tree in the new implementation.

Let me know if any of this doesn’t make sense...

[rolyp]

Here’s the old TypeScript number parser (from before the Nearley port):

// JSON grammar for numbers, https://tools.ietf.org/html/rfc7159.html#section-6.	
// I’m assuming (but haven’t checked that) DIGIT is defined as	
const DIGIT: Parser<string> = range(“0”, “9”)	
// decimal-point = %x2E       ; .	
const decimal_point = ch(“.”)	
// digit1-9 = %x31-39         ; 1-9	
const digit1to9: Parser<string> = range(“1”, “9”)	
// e = %x65 / %x45            ; e E	
const e: Parser<string> = choice([ch("e"), ch("E")])	
// minus = %x2D               ; -	
const minus: Parser<string> = ch(“-”)	
// plus = %x2B                ; +	
const plus: Parser<string> = ch(“+”)	
// zero = %x30                ; 0	
const zero: Parser<string> = ch(“0”)	
// exp = e [ minus / plus ] 1*DIGIT	
const exp: Parser<string> = withJoin(sequence([e, optional(choice([minus, plus]), () => ""), withJoin(repeat1(DIGIT))]))	
// frac = decimal-point 1*DIGIT	
const frac = withJoin(sequence([decimal_point, withJoin(repeat1(DIGIT))]))	
// int = zero / ( digit1-9 *DIGIT )	
const int: Parser<string> = choice([zero, withJoin(sequence([digit1to9, withJoin(repeat(DIGIT))]))])	
// number = [ minus ] int [ frac ] [ exp ]	
const numberʹ: Parser<string> = 	
   withJoin(sequence([optional(minus, () => ""), int, optional(frac, () => ""), optional(exp, () => "")])

[rolyp]

@min-nguyen I’ve made some progress on the parser. I’ve also played around with some ideas for using modules and imports to reduce our reliance on prefixing schemes like Expr-, Expl- and Val-. Have a look at say Eval.purs and see what you think - we could also do a similar thing with Elim- and Match-. I also wonder whether reverting to using an (anonymous) record type synonym instead of a datatype for ExplVal would further reduce the verbosity a bit.