Talk 8: Ömer Ağacan

[rrnewton]

Practice talk for Haskell implementors workshop -- 20 + 10 minute format.

27:52 talk time.

[ccshan]

Skip the initial outline entirely. At most, say in passing that you have an experimental GHC plugin.

[jasonhemann]

A presentation style thing---your left hand is a little distracting. See if you can just leave it by your side.

[rrnewton]

"branching" didn't seem to be defined in what you said on that slide... what kind of "branching"? Conditionals? (No, it's the compile time splitting in supercompilation)

[cgswords]

Get rid of those bullets?

[rrnewton]

Don't need to mention a link in the references -- [Bolinbroke, Peyton Jones 2010] is sufficient

[rrnewton]

Any particular reason that (.) is applied prefix rather than infix? I guess it makes it clearer that it's actually a function invocation.

[cgswords]

Definition of "history" on the slide would be nice.

[cgswords]

I would skip the middle beta-reduction step; do it in a single fell swoop and describe it as "repeated beta reductions". You do it for the later ones, I'd do it for the earlier ones, too. Also, consider not listing them on the slides; make each its own slide with the most recent change? This will keep hte code in the middle always, which will make it easier to pay attention to. Also maybe highlight the changes that way?

(There was a typo for h7 I think)

[rrnewton]

I was waiting for a hint that the beta reduction ("driving") steps are boring, and case-of-case is semi-boring, and some sign posting of when the interesting and unique-to-supercompiling stuff was happening.

[ezyang]

Definitely agreed on signposting

[rrnewton]

Ok, so we did hit the splitting bit, but it's on the slide that said "case of case" so that made it seem like it was part of the case of case transform.

[cfbolz]

missed at the beginning where the talk will be given, can somebody tell me?

[rrnewton]

Haskell Implementors Workshop.

[jasonhemann]

Shouldn't that be WHNF?

[ccshan]

Often you point at something while saying "this" or "this branch" or "the second case" and I'm not sure what you're pointing at. Here are some ways to be clearer:

• Move your hands more slowly and with more tension in your arm
• Synchronize your speaking the word "this" with a pause in your movement.
• Use both hands to bracket the beginning and end of what you're pointing at. (Or when using a laser pointer, move back and forth steadily between the beginning and end of what you're pointing at.)

[cgswords]

A general slide comment: I think the step-by-step appearance of information on a slide slows down talks in a not-great way. I'd prefer slides that are fully revealed unless a specific one has a good reason (such as moving something around / revealing something surprising). (Dan's got a great story about this...)

[ccshan]

Sometimes when a transition moves from one expression to the next, it is harder to follow because the two expressions appear to two separate slides. To avoid this, you can repeat the previous expression on the next slide (and say verbally that you are repeating it).

[cgswords]

To piggyback on that, you could have pairs of slides since everything gets names: do a slide with h1/h2, one with h2/h3, one with h3/h4, ..., and then re-display relevant ones when you need them. That might create a nice tempo of slides.

[rrnewton]

12 minute mark -- we're still on the map-of-map example. Ok, just finished it at 12:45.

[jasonhemann]

space between deforestation and (Wadler ...)

[rrnewton]

Based on the title, I wanted more insight on what previous approaches (Mitchell and then Bolinbroke) tried and why they failed. As it stands, so far this is much more like a tutorial on the basics of the technique. But that doesn't yet address the problems, challenges, or future/ongoing work.

("failed": well failed is relative -- they didn't succeed so spectacularly that it was considered worth putting into GHC.)

[cgswords]

Also, it doesn't motivate why it's a good fit for Haskell.

[cfbolz]

@rrnewton that depends on how much you already know

[cgswords]

This technique summary part of the talk seems oddly placed. We had a running example with techniques, and now we're summarizing those techniques; I would have expected that in the opposite order? We explain some of the techniques, then show a big, running example, and how they come up? Or interleaved perhaps.

[cfbolz]

jumping back in the slides can be quite confusing. probably better to repeat the relevant part of the previous slide

[rrnewton]

at 18 minutes on "issues" with supercompiler... maybe better to give very tiny explanation of the core techniques and then put this much earlier

[cgswords]

The in for the second example of a problem with the splitter was mistabbed.

[rrnewton]

Won't the existing GHC CSE indeed share work for multiple calls to fib?

[cgswords]

What's the issue with the matcher example? I didn't follow what the problem was with that optimization?

[rrnewton]

at 21:46 -- but this quote about nofib working badly with supercompilation is exactly what I wanted to hear at the beginning

Ditto for the "Latest work" slide.

I think all I really need to know before that state of affairs information is that supercompilation is aggressive compile-time evalutaion.

[cgswords]

I'm not sure what Omer's contribution is here, now, by the end of the talk. Or is this just a call to action?

[cfbolz]

@cgswords agreed, it didn't really become clear why sharing work is bad in a supercompilation context – it looks like a great optimization in the small example.

[rrnewton]

Re: problems with GHC API -- how much does Hermit address that?

[cfbolz]

not really related to the core supercompilation issues, but I found the critique of the GHC API really interesting.

[rrnewton]

Yeah, same here, I would want to hear that first too, esp. in HIW.

[rrnewton]

Omer does have a prototype... I don't know why he's almost completely hidden that. Ah, here it comes. But we're at 26:54.

[cgswords]

Oh, okay! At this point in the talk, I wasn't sure if / what he was presenting beyond "Bolingbroke's idea will work well for Haskell maybe?" The talk should really present some of those early prototype results IMO.

[samth]

• Lots of bullets ...
• Too many transitions on slides -- don't have slides that are useless to read
• This is just an explanation of supercompilation that we don't need in this much detail.
• Still waiting for something new to be mentioned ...
• I still don't know what the point of this talk is.
• These slides at the end need to be the beginning!
• Wait, why are we now complaining about the GHC API?
• No need for references slide.

[jasonhemann]

Similar comment as to the last one. There should be a concluding remarks/thanks slide, where the remarks come first, then THANKS!

[eholk]

I'd skip the overview slide and dive right into motivation.

We had several minutes going over previous and other people's work. Try to introduce what you've done sooner.

On the case-of-case transformation slide, try to keep the original term on the same slide so you don't have to flip back and forth.

I liked the way you worked through the mapOfMap example, but it wasn't clear whether you were showing an example of previous work or what is new in your paper.

Cite the paper the Nofib quote came from.

End with thank you and a slide with something about your talk. Put citations inline where needed.

[JosephCottam]

How does super-compilation compare with other techniques for compile-time computation (macros, templates)? This would be more useful context for me than the step-by-step example in the first part of the talk.

[cfbolz]

(the slides for introducing supercompilation are probably going to be useful in some other context, so keep them around somewhere :-) )

[jasonhemann]

samth: "Sell'em the brooklyn bridge. Reveal the charade. Then tell'em how you're gonna actually deliver the moon."

[rrnewton]

Sam's describing a possible flow:

• Show some positive things Mitchell and Bolinbroke said about their work
• but "where's my supercompiler for GHC?"
• describe a roadmap and some steps for getting to a GHC plugin
• (GHC API fixes and stuff like that on the way is fine too...)

[rrnewton]

I want to second the idea above about having an expression which is transforming centered (ideally highlighting redexes too) so that visual alignment isn't such a chore.

But, then again, I vote against having map-of-map or reverse walk throughs at all, except maybe for tiny highlights, not as an extended reduction sequence.