per-key configuration of static-info union and intersection; use of intersection by if and cond

[mflatt]

This PR has two changes:

• Change the way keys for static information are defined so that the definition can supply union and intersection operations on values associated with the key. The operations are also directly exposed by statinfo_meta.union and statinfo_meta.intersect.
• Change if and cond to trigger earlier enforestation of body forms under the same circumstances as def, and then intersect static information from the branches to provide static information for the overall if or cond form. This kind of expansion and intersection is not done for match, because enforesting the result bodies requires expanding the binding patterns, and it's not clear that earlier expansion there is a good idea.

As an example use, these changes allow me to remove some annotations on ifs (or on let bindings where the right-hand size if an if) that seemed especially annoying in some of my rhombus/slideshow-based slides.

[usaoc]

I’m a bit worried about more and more eager expansion, because it can lead to somewhat weird expansion order (#472 being an example). That may or may not be a big problem, though.

[mflatt]

I share your concern about eager expansion, and I think we probably want to avoid it in most cases. But my experience writing Rhombus code, so far, is that the tradeoff is worthwhile in this case.

If we do go this way for if and cond, I can imagine that we might find one or two additional cases where it seems worthwhile in the future — or maybe not. I haven't yet run into other contexts where seems worthwhile.

[samth]

Would this also be applicable to match?

[mflatt]

Would this also be applicable to match?

See the second bullet in the original comment. In fact, after thinking about it a little more, probably the comment there understates the obstacles to changing expansion order when binding patterns are involved.

[samth]

I guess it still worries me that using match instead of cond will have significant and non-obvious implications for other aspects of the program, especially since we're making pattern matching a much more pervasive part of Rhombus. I'm also a little concerned that the rules for static info propagation will be hard to explain to users as it grows more and more type system-like features.

[mflatt]

I guess it still worries me that using match instead of cond will have significant and non-obvious implications for other aspects of the program, especially since we're making pattern matching a much more pervasive part of Rhombus. I'm also a little concerned that the rules for static info propagation will be hard to explain to users as it grows more and more type system-like features.

Well, yes. That second sentence, in particular, is the central concern of the whole static-information experiment.

But the changes to if and cond here are motivated by my experience writing a lot of rhombus/static code. So far, I've found the static-information system to be more effective and easier to use than I expected, and the biggest discomfort has been with if and cond. (The second-biggest discomfort has been working with expressions that have maybe(...) annotations, but that's for another day, and I doubt that changing if is the way to go for that one.) This change has made things work a little better for me, and it has not made my own reasoning more difficult — but that's just me and for a short time. I don't have a better idea for evaluating the change than merging to get long-term experience by more people.

[rfindler]

I wonder if there is a rational programmer experiment to try here? @chrdimo ?

[mflatt]

The consensus in the March 21 Rhombus meeting was to merge this and try it out, for now.

[mfelleisen]

@rfindler @chrdimo

If you give us a Rhombus that runs w/o static information, we can check two hypotheses with the RP and tune them to specific questions. (RP evaluate the pragmatics of different semantic choices or different tools for the same task.)

[rfindler]

I'm not sure what the specific task here would be. Programming with use_static comes with some benefits and drawbacks as compared to not. The benefit something like the benefit of types in general (although it isn't a type system). The "cost" is that you have to put static information into the code, except the issue, IIUC, isn't that you have to put information there but that sometimes it is too annoying to put the annotations in cases that seems like it shouldn't be. I think @chrdimo saw a demo of this at WGLD. I'm not sure how to cast this into the RP framework but it does seem like the kind of thing where some kind of RP-inspired investigation might be yield interesting results, maybe.

[mfelleisen]

@chrdim Christos and I spent 40 mins on this just now. I proposed two different tasks to evaluate: 1. does the addition of static annotations pay off when debugging a mistake in the program? 2. does the addition of static annotations help improve the performance of programs? One could apply the two RP investigation methods to this scenario we just published (one with Lukas, one withe Ben). Both would require substantial (not necessarily very large) Rhombus programs. [[ Keep in mind that I try to delete all Rhombus messages so that nobody thinks Rhombus is Matthias polluted. I have only vague ideas — mostly from the OOPSLA paper. ]]