<div dir="ltr"><div>i've written (more opaquely than i'd like), about this topic a few times , including on that ticket <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/14917#note_230433">https://gitlab.haskell.org/ghc/ghc/-/issues/14917#note_230433</a> ! <br></div><div><br></div><div>ultimately, you want some notion of function types /lambdas that have the equivalent to the C++ Const-Eval / C++ Template arg "compile time instantiation is the only allowed flavor".</div><div><br></div><div>for the particulars in the context of runtime rep levity, my intuitions break down, but i've had examples of the sort of "must be resolved at compile time" where for the behavior i'd need isn't expressible using type classes because those can be instantiated abstractly rather than  concretely and still be valid programs. <br></div><div><br></div><div>granted i'm not terribly current on the state of play in >= ghc 9.4 for this stuff, but i would not be surprised if the architectural hooks needed for a "strict staging lambda" arent there yet. (you can manufacture some of this stuff with typed template haskell, BUT theres no mechanism for expressing the primops that certain uses cases, like SIMD shuffle, would need)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 2, 2023 at 9:18 AM J. Reinders <<a href="mailto:jaro.reinders@gmail.com">jaro.reinders@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">No, I found it. It is this GHC issue: <br>
<br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/14917" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/14917</a><br>
<br>
> On 2 Jan 2023, at 15:07, Tom Ellis <<a href="mailto:tom-lists-haskell-cafe-2017@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2017@jaguarpaw.co.uk</a>> wrote:<br>
> <br>
> On Mon, Jan 02, 2023 at 02:01:56PM +0100, J. Reinders wrote:<br>
>> I seem to recall another thread where there were more suggestions<br>
>> like a special form of type classes that is always guaranteed to<br>
>> monomorphise away<br>
> <br>
> Perhaps this?<br>
> <br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/454#issuecomment-1030258076" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/454#issuecomment-1030258076</a><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>