search

effectfully / tiny-lang

BSD 3-Clause "New" or "Revised" License
6 stars 2 forks source link

Add a high-level language #12

Open effectfully opened 5 years ago

effectfully commented 5 years ago

It's not clear right now what it's going to like, but at the very least we'll need statically unrollable for loops. I.e. we are going to compile a language with for loops (and possibly other features) to the current field language that doesn't have them.

effectfully commented 5 years ago

We'll also need to decide how to share code. Are we going to extend the field language and add some type-level nonsense to distinguish between the stages? Or would a separate language be more suitable? But then we clearly don't want to write a separate parser and evaluator (which we'll need for compilation tests). Etc.

effectfully commented 5 years ago

Who did just say "final tagless"?

effectfully commented 5 years ago

Syntax for for loops:

for <variable> = <positive_integer> to <positive_integer> do begin
    <body>
end;

(finally I'm writing Pascal again). Each variable introduced in <body> is in scope after the loop.

Semantically we unroll the loop statically into a flat wall of <body>s.

For now it makes sense to amend the parser and not to amend the AST of the language. We can parse and immediately unroll.

We also need to be able to use variables like a_$i where i is the variable bound by a loop header. During unrolling this elaborates to, say, a_0, a_1 etc.

effectfully commented 5 years ago

for loops were added in #26. Loops are unrolled during parsing. Currently we do not support arbitrary expressions in loop headers, because resolving those during parsing is hard and silly.

In the high-level language we should have for loops in the AST. The high-level language should not be intrinsically typed (for the ease of parsing). Converting from the high-level language and loops unrolling should happen simultaneously.

We also need to be able to use variables like a_$i where i is the variable bound by a loop header. During unrolling this elaborates to, say, a_0, a_1 etc.

No, we should just add arrays instead of this macros nonsense (tracked by #29).

effectfully commented 5 years ago

We also need functions (tracked by #32).