(PS to avoid losing context, there are ways—perhaps only accessible to moderators?—to split posts into new topics.)
2 Likes
Yes. You can either let me know where you want to split or I can look at assigning the permission
1 Like
FYI we will be taking a break this week after the recent release, so there will be no meeting this Friday Feb 14. If you missed the notes from the release party, there's a lot there to catch up on:
2 Likes
Yesterday's notes:
Important: As the notes mention, now that we're back from break after the recent release, this week we did the "lexing" step on identifying next steps for the project --- that is, just looking at the accumulated list of todos and cleaning them up. Next week, we'd like to do the parsing step, as it were, of identifying directions for the project that community members are interested in and would like to participate in. If you have any medium or long term goals you'd like to see Qi move toward, or ideas or hopes for the project, please join the discussion next week. If you can't make it, feel free to DM me or another Qi regular, either here or on Discord, and we can bring up your thoughts to the group.
Qi is community infrastructure, built by community members for the community. It is whatever we want it to be, and whatever we make it. There are many awesome directions for the project that have already been identified, and surely more that you might think of. Where we choose to go and whether we get there really is up to you!
Last week's notes:
This was our "goal setting" meeting following the recent Qi 5 release, to identify the next things we want to work on as a community (and for the community). Some interesting discussions, esp. re: "transducers."
Highlights:
- Comparing (Clojure) transducers vs stream fusion
- could we implement transducers in continuations in the Racket interpreter?
- LOP at the VM level??
Feedback welcome!
Today's notes:
Highlights:
- list comprehensions vs higher-order functions: the definitive analysis?
- towards Clojure transducers
- some rudimentary benchmarking of Racket's
sequencetype
Last week's notes:
Highlights:
- Qi and Rhombus?
- We investigated a performance puzzle and figured it out! ... or did we?
- Join us tomorrow if you want to help us get to the bottom of it!
This was a fun one.
Highlights:
- We didn't solve the performance puzzle, but we got some reliable data
- Just read till the end
2 Likes
I'm very curious.
I usually use something like 33333 instead of 3 so it's easier to find it in the middle of of a big expansion. If you want a square minus one, I just got
11115556 -> 11115555
44448889 -> 44448888
It would be useful to compare the output of each phase. If they are equal after cp0, it would be useful to find the first one where they are different again.
I remember the BC had some hidden info, for example after some internal optimizations steps (lambda (x) ...) has a fag to signal it's single valued and another to signal it doesn't do interesting things with (tail?) continuations marks. So the later compilations steps can generate more efficient code.
I'm not sure about the hidden information in CS. But references, call and other stuff have in the internal representation an internal field preinfo that I never understood and I think is hidden in the "friendly" output.
1 Like
Ah, thanks, that's a very helpful insight re: the possibility of "hidden" information!
That reminds me of something similar in the Qi compiler, where we currently rely on a compile-time struct to hold some information that isn't explicit in the IR, for the purposes of doing deforestation (in a dedicated deforestation pass). Doing it this way allowed us to achieve deforestation by introducing a single new core language form (called #%deforestable, designating any deforestable operation). At the time, we had assumed that without this approach, we would need to significantly inflate the core language in order to support all deforestable operations.
But it now seems possible that we could introduce just a handful of forms, e.g., #%producer, #%transformer and #%consumer, which would allow us to make all of the metadata from the compile-time struct explicit in the IR, retaining the generality and extensibility of our current approach. I think the tradeoff might be that doing it via "hidden" info could potentially reduce compile time by reducing the size of generated code, but I don't know much about this. I wonder if a similar translation could always avoid hidden information (i.e., even in the case of CS), and whether that would be advisable. Do you have any thoughts or preferences on this?
Notes from Friday:
Two Directions in Deforestation Architecture
There's some interesting stuff there for the patient reader.
Highlights:
- Representing not just deforestable but deforested sequences in the Qi core language
- Clearly separating formal compilation rules (e.g., for abstract stream fusion) from code generation (i.e., to Racket) which includes the actual deforested runtime
- We've had the "probe" debugger for a while, for local testing. Maybe we can also have "tap" for holistic visibility?
- The independent compilation divide in multi-language settings, and ways to overcome it
Btw @gus-massa , we decided to take a break from the "fantastic voyage" into the Racket and Chez Scheme compiler this time, as we didn't want to get sucked too far down that rabbit hole just yet. But it's very interesting (likely for a lot of folks on here), so we felt we could return to it in a little while, ideally with more hands on deck (want to join for that?), so that more people share in the fun and we have a chance to learn some new tricks 
1 Like
Last week's notes:
We discussed some challenges to proposed changes in the design of deforestation in the initial round of feedback. It's pretty in-the-weeds of the implementation, of necessity, but it's a nice dialogue and a view into iterating the design of a core component of the compiler.
Enjoy!
Last week's notes:
We discussed how and why we should introduce inlining in the Qi compiler.
Also Qi Enterprise Edition:trade_mark: (QiEE:trade_mark:) has received buy-in from all stakeholders in upper management including C-levels 
and we have received the go-ahead to conduct market surveys to establish product/market fit by connecting with early adopters and tech evangelists.
Last week's notes:
Highlights:
- a sketch for inferring naive and deforested semantics for the same sequence operation (e.g.,
map) from a common set of defining parameters (ideas welcome!) - formally specifying semantics of deforestation is a rabbit hole we'd like to avoid
- Qi Enterprise Edition™ and formal verification opportunities
- for inlining with bindings present,
gensymsare bad.make-syntax-introduceris good. - On the road in the Swiss Alps
Notes from Friday:
Highlights:
- using a "persistent symbol table" to facilitate inlining of separately defined flows
- rabbit holes involving parsing approaches, terminals from the future, and Emacs
1 Like
Friday's notes:
We're making progress on inlining separately-defined flows 
Highlights:
- Using transformer bindings as a sub-in for a free identifier table
- Capturing flow syntax at the definition site in compile-time metadata
- Inlining that syntax in a new compiler pass at the start of compilation
- How to solve the problem of inlining surface syntax post-expansion? (ideas welcome!)