akeep / nanopass-framework

The new nanopass framework; an embedded DSL for writing compilers in Scheme
MIT License
321 stars 42 forks source link

Other documentation ideas: cheatsheet/table + gentle tutorial #10

Closed rrnewton closed 7 years ago

rrnewton commented 10 years ago

Tim Zakian is working on a gentle tutorial document.

Another thing I'd like to put together would be a little cheatsheet in the form of a table or spreadsheet that shows:

Anything else that should go in there?

One thing I'm wondering about is how we can best clarify to students where the magic ends and the plain ol' Scheme code begins.

akeep commented 10 years ago

On Wednesday, January 8, 2014 at 9:17 AM, Ryan Newton wrote:

Tim Zakian is working on a gentle tutorial document. Another thing I'd like to put together would be a little cheatsheet in the form of a table or spreadsheet that shows: which forms bind which names which forms expect which names

Anything else that should go in there?

I think the pattern matching and cata-morphisms should definitely be in there. The other big thing is probably to note is that while it looks like S-expression pattern matching, it is not S-expression pattern matching, and so if you have a language production of: (let ([x* e*] ...) body)

You cannot match it (or produce it with a template) as (let (,binding* ...) ,body)

The other gotcha that people seem to run into early on in using this stuff is using the meta-variables in pattern matching.

Finally, I'd be clear about where quasi quote is bound and not bound. For instance, it is not bound in the definitions section of a pass, but it is in the definitions section of a transformer and in the right-hand-side of a transformer clause (for transformers with an output nonterminal).

Past that, I'm not sure how to predict where the students will run into problems... but I'm sure they will find whole new problems, this is somewhat the nature of these things.

One thing I'm wondering about is how we can best clarify to students where the magic ends and the plain ol' Scheme code begins. This is a good question.

There is not much magic in the language definitions, they expand in a pretty predictable way, but they lead to a lot of magic in the passes. One way to do this is to describe how the catamorphisms and auto generated clauses work, though it is a bit complicated, and I'm not sure how easily it is going to be to internalize it.

I think a simpler approach might be to give a general idea of how where magic happens:

(define-pass foo : Lin (e) -> Lout () (definitions defs ...) ; no magic here, just normal scheme code. (Expr : Expr (e) -> Expr () [pat ; magic when the catamorphisms aren't fully specified guard ; no magic here, can only use input variables from pattern rhs rhs ...] ; in rhs expressions only quasi quote is magic clause ...) body) ; when body is omitted, body is automatically generated

Additionally, no clauses are auto generated if an else clause is included or if the transformer explicitly names all clauses.

Transformers are auto generated if a transformer with a single input and output language form will fit the bill.

-andy:)

— Reply to this email directly or view it on GitHub (https://github.com/akeep/nanopass-framework/issues/10).

akeep commented 7 years ago

Issue moved to new repository: nanopass/nanopass-framework-scheme