Compiler implementation plan about dhall-clj HOT 8 CLOSED

@Gabriel439 is the above somehow accurate? Am I missing any steps?

from dhall-clj.

The only steps missing are the ones not yet standardized (specifically semantic integrity checks). Other than that it looks complete to me

from dhall-clj.

Cool thanks! I didn't consider the semantic integrity checks, added to the list.

from dhall-clj.

Update: as of 878023f, we now parse all Dhall forms (except imports) from text into an Expr tree.
The Expr type itself is copied straight from the haskell implementation (ours is here).

Basically parsing happens like so:

• we generate a parser from the abnf with Instaparse
• run that on input
• convert the resulting "parse tree" to the Expr AST (code is here)

We have ~50 testcases for basic parsing here - we check that a parsed text form generates a certain AST.

from dhall-clj.

As of what to do next, I was thinking about skipping the imports for now (as some things like "semantic integrity checks" are not standard yet) and work on typechecking/normalizing/emit the "pure" subset of Dhall (so that the pipeline is in place and works).

from dhall-clj.

@Gabriel439 I'm implementing beta-normalize for function application, and I was wondering about your implementation of NaturalFold: do I have to differentiate between a strict unrolling and a lazy one or can I just use a single folding strategy? Is it like that for performance reasons?

from dhall-clj.

@f-f: It's purely an optimization and not required by the standard so if you want to do the single folding strategy that is definitely allowed.

Basically the standard allows you to do anything you want as long as the final result is the same. For example, Natural/even/Natural/odd would be very slow if you pedantically followed the reference implementation in the standard.

See: https://github.com/dhall-lang/dhall-lang/blob/master/standard/semantics.md#%CE%B2-normalization

Also, note that the semantics specifies several built-in types, functions and operators that conforming implementations must support. Implementations are encouraged to implement the following functions and operators in more efficient ways than the following reduction rules so long as the result of normalization is the same.

from dhall-clj.

@Gabriel439 cool, thanks.
As you said naively implementing the specification would be inefficient, so I figured the best path forward was to port your implementation (e.g. the even/odd stuff, or the build/fold fusion) but try to omit the small details (e.g. I don't need this lazy/strict differentiation yet, I'll set up profiling/benchmarks before trying to optimise anything).

I'll also reuse your tests for type check/normalisation/etc (and I guess it would be nice move them to the dhall-lang repo at some point, so they can be in sync with the spec)

from dhall-clj.