Last week's notes:
Designing List Operations
Highlights:
- Perfoming functional list operations with Qi syntax with
qi/list
- A funky case of backwards incompatibility that isn't really
- Introducing
λ syntax to Qi for great justice
- Compiler architecture and neatly separating expansion and compilation via appropriate introduction of core language forms
- A Qi compiler community event could be in the cards
Enjoy! (And the meeting today starts in about an hour -- join us if you're around).
@dominik.pantucek @michaelballantyne I'm not sure I understand the issue with knowing floe nonterminal positions in code generation for the new #%deforestable core form, but I've suggested a possible approach in the notes 
Just a quick note: I think the Previous link on that page is broken.
I think the issue is that different deforest-able procedures might accept procedure arguments in different positions: assuming all higher-order positions are to be flow syntax, you need to know which ones to make flows for which positions (which suggests a way to mark them is needed). But I may also have misunderstood.
Yes you're right @benknoble . I think another aspect is that we need to know which ones are flow syntax positions at the expansion stage, since the expander will need to expand those positions into the core language before the deforestation comes into play. I think I was confused earlier because at the compilation stage, I felt we could just take the name of the form (which could be preserved as a field in the new core form) and manually encode into the compiler how the various positions in that form should be codegen'd to Racket (at least as a short term solution to unblock further deforestation work). But this wouldn't be enough if portions of the form haven't even been expanded from surface Qi yet (or are incorrectly expanded as wrapped Racket via esc).
Yeah there are a few broken links lately since I haven't posted notes for some meetings. I still have many of the notes in WIP so if I get around to posting them the links will get fixed, otherwise I will declare bankruptcy and connect the links to skip over the missing ones (don't worry, the "order of effects" one -- which was such a good one 
-- I still intend to get to it as soon as we return to discussing the topic!).
1 Like
Notes for a recent meeting on the subject of Git best practices:
Commit Issues
Highlights:
- Small vs large commits
- Consistent vs inconsistent commits
- Cohesive vs hodgepodge commits
- Complete vs partial commits
- Normalized vs denormalized commits
- Commits over a short vs long timeframe
- "Death of the author"
And guiding principles for writing good commits.
We are all still learning and we will be continuing this discussion on Friday (i.e. day after tomorrow), so if you have strong opinions on Git practices that projects should follow, or would like to learn about such practices for your own project, this would be a good one to join for! All are welcome, and hope to see you there.
As a reminder, Qi meets in the old Racket gather.
Alright we're back with Qi meeting notes this week! Here are today's notes:
One Track Minds
This one was fairly in-the-weeds about next steps for Qi's deforestation of list-oriented APIs. Some highlights:
- what to do when macros start to look a lot like functions?
- more on achieving clean separation of hosted language from host language, and how enriching the core language is a way to do that
- Qi 5 on the horizon?
Today's notes:
Choose Your Words Carefully
Highlights:
- we're continuing on list deforestation, incorporating it formally in the core language and supporting Qi syntax in higher-order positions in
map, filter, etc.
- we have some ideas on making deforestation extensible to custom (e.g. user-defined) list APIs, but it'll be some time before we understand how
1 Like
Last week's notes:
An Expander for your Expander
This one was pretty in-the-weeds on developing a proof of concept for "deep extension" of the Qi compiler further, which would eventually allow us to extend deforestation to custom list operations -- essentially exposing both syntax and semantics to extension, in a limited way, via a kind of macro system.
