Csaba Hruska

Our approach ([GHC/GRIN](https://github.com/grin-tech/ghc-grin)) has the following pipeline: Haskell->Core->STG->[GRIN](https://github.com/grin-tech/grin)->LLVM. However [simplexhc](https://github.com/bollu/simplexhc) and [simplexhc-cpp](https://github.com/bollu/simplexhc-cpp) implements the STG->LLVM pipeline but without the frontend part. There are some [blog posts](https://pixel-druid.com/blog/) about simplexhc: - [Announcing...

Can you give some details about GHC design decisions which interfere with GRIN?

I believe that the dictionary approach is not an issue at all if the optimizer framework implements interprocedural [Dead Data Elimination](http://nbviewer.jupyter.org/github/grin-tech/grin/blob/master/papers/MoL-2010-19.text.pdf#page=55). That will eliminate the unused class methods.

The run-time specialization can be done in GRIN level also.

I don't see, what's the obstacle?

Do you mean a dispatch function to select between specialized and generic functions? Heap Points-To will reveal the overloaded routes. Then an optimization pass would select a subset of heavily...

In GRIN square would be compiled naively to a function which uses dictionary. However the HPT would tell that various dictionaries are passed to it at lots of call sites....

These are real concerns. But I want to analyze/compile real world programs so GHC is the only option for that. (IMHO) If it turns out that the optimizer need user...

Would it be possible to change type class handling from dictionary passing style to JHC style type level lookup using a core pass on GHC core representation?

Hi, As a workaround for cubemaps you can sample six 2D textures manually. But there is no technical obstacle to support it, so I'll implement is soon. I'm glad that...