How to safely use withDict?

Learn
1

I was wondering if ImplicitParams could be emulated via withDict from GHC.Base

{-# LANGUAGE PatternSynonyms #-}
{-# LANGUAGE ViewPatterns #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE DataKinds #-}
import GHC.Base (withDict)
class LocalVar str val | str -> val where
    local :: val
data LocalDict str val where 
    LocalDict :: LocalVar str val => LocalDict str val

mkLocalDict :: forall str val. val -> LocalDict str val
mkLocalDict val = withDict @(LocalVar str val) val LocalDict

pattern LocalBind :: forall str val. LocalDict str val -> val
pattern LocalBind dict <- (mkLocalDict @str @val -> dict)
  where
    LocalBind (LocalDict :: LocalDict str val) = local @str @val
{-# COMPLETE LocalBind #-}
main = do 
    LocalBind @"inpt" LocalDict <- getLine
    putStrLn (local @"inpt")

This gives me:
bus error runhaskell
and
segfault runhaskell
or just doesn’t output anything. Is withDict inherently unsafe or am I doing something wrong?

2

withDict should only threaten coherence, not cause segfaults—this is a GHC bug. The code also compiles just fine, so I guess it’s a bytecode issue. I suggest trying again with latest GHC to see if it’s already been fixed, otherwise report the bug on the GHC gitlab.

3

This seems to work fine with GHC 9.14.1, segfaults with earlier versions.

4

Interestingly, while running it on my computer gave a bus error, it seems to work fine with PlayHaskell. Is that due to os types? (Mine was windows) V 9.12.2

5

If it segfaults for you on Windows even on 9.14.1, please report it as a GHC bug.

6

Sorry, that was 9.12.2

7

play.haskell compiles.

8

Not only compiles, it runs fine. However on my computer, it gave a bus error on GHC 9.12.2. I was simply wondering why it worked there and not on my computer given that it was the same compiler. I’m guessing machine types?

9

Perhaps I wasn’t clear. What I meant by this is that—from what I’ve seen—ghc produces good binaries for the code; the issue only emerges when interpreting it, such as with ghci, runghc or runhaskell. Since play.haskell compiles to binary, it’s not affected.