Modular compiler #151
Modular compiler #151
Conversation
…k unconditionally.
qi-lib/flow/core/passes.rkt
Outdated
| (define-syntax (define-pass stx) | ||
| (syntax-case stx () | ||
| ((_ prio (name stx) expr ...) | ||
| (with-syntax ((name-pass (format-id #'name "~a-pass" (syntax-e #'name)))) |
There was a problem hiding this comment.
format-id will unwrap syntax so syntax-e is not needed here.
Also, is there a reason not to just use the name instead of making and providing name-pass?
There was a problem hiding this comment.
Removed syntax-e (thank you again). The name-pass is provided only for the purpose of testing in qi-tests package - it is basically just a compatibility provide to keep the original interface. The binding is not used anywhere in the compiler.
qi-lib/flow/core/passes.rkt
Outdated
| ;; Syntax macro wrapper for convenient definitions of compiler | ||
| ;; passes. Should be used by modules implementing passes. | ||
| (define-syntax (define-pass stx) | ||
| (syntax-case stx () |
There was a problem hiding this comment.
Why not syntax-parse?
There was a problem hiding this comment.
I still see a proper language composition scheme as necessary in the long term, since it would be valuable from a research standpoint to have a cleanly user-extensible compiler. For that, I feel the "bottom level is hopeless" is a promising approach that we talked about (summary, as a refresher: separate code generation from compilation, and then compose languages at the level of expansion + compilation to a shared core language with escapes, i.e. the meaning of esc isn't just "Racket will expand this" but instead, "I don't know how to expand this," and a subsequent language (including, ultimately, Racket, after code generation) is free to unwrap it and expand it), and I feel Syntax Spec is exactly positioned to realize something like that. If @michaelballantyne also agrees that the present modular compiler approach doesn't conflict with doing something like that later, then we could look towards merging this work soon so that the qi/list work is unblocked.
| (provide (for-syntax define-pass | ||
| run-passes)) | ||
|
|
||
| (begin-for-syntax |
There was a problem hiding this comment.
Can we define this module at phase 0 and then require at the appropriate phase in client modules?
| sep | ||
| collect | ||
| __) | ||
| (begin-for-syntax |
There was a problem hiding this comment.
Why remove normalize-rewrite? Feels useful to have the single rewrite as a distinct function and then have the pass call it to a fixed point. So I think, below, it would be (fix normalize-rewrite)
| sep | ||
| collect | ||
| __) | ||
| (begin-for-syntax |
There was a problem hiding this comment.
Same as other comment, can we define this module at phase 0 and then require at the appropriate phase level in client modules?
qi-lib/pass/deforest.rkt
Outdated
| #:attr curry (make-producer-curry 1 3 | ||
| blanket? pre-arg post-arg | ||
| fine? arg | ||
| form-stx)) |
There was a problem hiding this comment.
I think these are pure indentation changes? Unless you have a strong preference for the new indentation, would prefer to leave these changes out. We can standardize on project local indentation at some point, as we talked about recently (I've also mentioned it in the wiki) and looks like there is a config for pattern there that you could use in Emacs). We should probably try to standardize on whatever DrRacket does, unless it does something we don't like 😄
qi-lib/pass/deforest.rkt
Outdated
| ;; Performs deforestation rewrite on the whole syntax tree. | ||
| (define-pass 100 (deforest stx) | ||
| (find-and-map/qi | ||
| (lambda (stx) |
There was a problem hiding this comment.
Here too, it seems useful to have a distinct name for the individual rewrite (deforest-rewrite) and a separate one for the function that applies it multiple times (deforest-pass). Any reason to move away from that?
|
@michaelballantyne @dzoep and I looked at this together in the Qi meeting today. 👍 |
Summary of Changes
[Please describe your changes]
Public Domain Dedication
(Why: The freely released, copyright-free work in this repository represents an investment in a better way of doing things called attribution-based economics. Attribution-based economics is based on the simple idea that we gain more by giving more, not by holding on to things that, truly, we could only create because we, in our turn, received from others. As it turns out, an economic system based on attribution -- where those who give more are more empowered -- is significantly more efficient than capitalism while also being stable and fair (unlike capitalism, on both counts), giving it transformative power to elevate the human condition and address the problems that face us today along with a host of others that have been intractable since the beginning. You can help make this a reality by releasing your work in the same way -- freely into the public domain in the simple hope of providing value. Learn more about attribution-based economics at drym.org, tell your friends, do your part.)