Today's Qi meeting notes

General
,
61

(PS to avoid losing context, there are ways—perhaps only accessible to moderators?—to split posts into new topics.)

2 Likes
62

Yes. You can either let me know where you want to split or I can look at assigning the permission

1 Like
63

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:

An Unexpected Party

2 Likes
64

Yesterday's notes:

Lexing and Parsing

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!

65

Last week's notes:

Compile Time

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!

66

Today's notes:

The Best of Three Worlds

Highlights:

  • list comprehensions vs higher-order functions: the definitive analysis?
  • towards Clojure transducers
  • some rudimentary benchmarking of Racket's sequence type
67

Last week's notes:

A Puzzling Performance

Highlights:

  • Qi and Rhombus?
  • We investigated a performance puzzle and figured it out! ... or did we? :chipmunk:
  • Join us tomorrow if you want to help us get to the bottom of it! :detective: :magnifying_glass_tilted_right:
68

This was a fun one.

Into the Depths

Highlights:

  • We didn't solve the performance puzzle, but we got some reliable data
  • Just read till the end :slight_smile:
2 Likes
69

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
70

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?