`stack ghci` trigger ambiguity errors

[adinapoli]

Hey guys, I don't know if I'm undercaffeinated and tired at this point of the day, but trying to load foundation in ghci triggers the following:

ghci> :l Foundation/String.hs
[16 of 47] Compiling Foundation.Numerical.Additive ( Foundation/Numerical/Additive.hs, Foundation/Numerical/Additive.o )

Foundation/Numerical/Additive.hs:38:11: error:
    • Could not deduce (Prelude.Num n) arising from the literal ‘0’
      from the context: Additive a
        bound by the class declaration for ‘Additive’
        at Foundation/Numerical/Additive.hs:31:7-14
      or from: IsNatural n
        bound by the type signature for:
                   scale :: forall n. IsNatural n => n -> a -> a
        at Foundation/Numerical/Additive.hs:36:14-39
      Possible fix:
        add (Prelude.Num n) to the context of
          the type signature for:
            scale :: forall n. IsNatural n => n -> a -> a
    • In the pattern: 0
      In an equation for ‘scale’: scale 0 _ = azero
   |
38 |     scale 0 _ = azero
   |           ^

The suggested fix seems trivial enough (it's not the only place where it happens), thus the question: am I doing something wrong or is there a real issue here?

[NicolasDP]

do you think it is related to #51 ?

[vincenthz]

I think it looks like the type of problem if you're not using RebindableSyntax. relevant https://github.com/haskell-foundation/foundation/issues/185

[adinapoli]

I guess you are both right, in a sense. As Vincent correctly pointed out we need RebindableSyntax to be enabled, but it's not the only extension. In fact, I had success calling ghci and loading Foundation.String.UTF8 with this .ghci:

:set -fobject-code
:set -XRebindableSyntax
:set -XGADTs
:set -XTypeFamilies
:set -XBangPatterns
:set -XDeriveDataTypeable

And by calling ghci this way: stack exec ghci -- -DARCH_IS_LITTLE_ENDIAN. This is because the cpp-option gets "created" by looking at the cabal manifest when we build the project, but for ghci that's not the case.

One might argue this ticket could be easily morphed into one that:

• Extend .ghci the way I've suggested (plus any other needed)
• Find a way to automatically set that cpp-option without the explicit command line argument. Maybe that can be put in the .ghci file as well?

[vincenthz]

yes, if you don't go through the stack path then you'll have to add all the default extensions that are listed in the .cabal file.

  default-extensions: NoImplicitPrelude
                      RebindableSyntax
                      TypeFamilies
                      BangPatterns
                      DeriveDataTypeable

(TypeFamilies implies GADTs, and RebindableSyntax implies NoImplicitPrelude)

yes updating a .ghci sounds good, also we could maybe go away from ARCH_IS_LITTLE_ENDIAN By using ghc 's include files (like MachDeps.h). I things one of those files have what we need

[flip111]

Extend .ghci the way I've suggested (plus any other needed)

Hello @adinapoli that would be nice to extend .ghci if you have good suggestions. There is a template for stack you can modify. However i noticed some issues, don't they conflict with your suggestion?

Find a way to automatically set that cpp-option without the explicit command line argument.

Which cpp-option are you referring to?

[mgsloan]

For the purposes of being friendly with multi-package ghci, I propose removing NoImplicitPrelude and TypeFamilies from default extensions. If I add a default template package to the stack project, then stack ghci will give warnings about these:

(I know it's weird to use a screenshot for this, but I recently changed my terminal setup and copy paste isn't working, gotta fix it).

Why remove these even though the stack.yaml only has foundation and basement? Well, if you're working on a project and you end up wanting to modify foundation a lot and reload it all in ghci, then it's very helpful for it to be able to be loaded alongside other projects.