-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HIW'19 practice talk: Mike Vollmer #16
Comments
"Pointer-based memory layout" => why show C code here for a Haskell audience? Could show C and Haskell I suppose to emphasize how conserved this representation is ... |
"What is Gibbon" went immediately to a picture of a tree. I thought |
Along the lines of the prior comment, some of the discussion here |
CapnProto isn't a language -- should mention that this is a C++ benchmark using the capnp API. |
On the "Performance vs. C" slide, where are the numbers for Gibbon? I only see one color on the legend. |
I think you should elaborate more on why the closed-world assumption is a problem, especially with respect to type class instances, which operate on the open-world assumption. What happens if you compile a program and then need to link it against other code, which may define more instances? |
"times slower than gibbon" |
"Integrate how?" -- no mention of EDSLs? Parse-haskell-files vs Template Haskell are the only options. What about Core plugin? That's the one we actually want to do. I was hoping that would show some more concrete (hypothetical) code of how the Haskell integration might work. |
I don't think the need for pointers need to be much explained. I think it suffices to say you need pointers if you want any sharing. "Gibbon allows us to represent the list with this new Indirection case" => not clear whether the compiler is doing it or the user in that phrasing. |
|
Lots of discussion in the questions session. RGS wanted to see more of the different options -- parsing Haskell, Template Haskell, etc. RN and STH advised on how the talk should be structured. Both agreed that LoCal is mostly internal details that aren't real important to this audience. |
Leave feedback here.
The text was updated successfully, but these errors were encountered: