Skip to content
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

Code from 2018-07-12 doesn't typecheck. #59

Open
leifmetcalf opened this issue Oct 1, 2018 · 1 comment
Open

Code from 2018-07-12 doesn't typecheck. #59

leifmetcalf opened this issue Oct 1, 2018 · 1 comment

Comments

@leifmetcalf
Copy link
Contributor

leifmetcalf commented Oct 1, 2018

The pretty instance for Mul:

instance (Pretty l, Pretty r) => Pretty (Mul l r) where
  pretty (Mul a b) = unwords [autoParens a, "*", autoParens b]
    where autoParens a@(Add _ _) = "(" ++ pretty a ++ ")"
               autoParens                   a = pretty a

Gives the following error:

    • Couldn't match expected type ‘Add l0 r0’ with actual type ‘l’
      ‘l’ is a rigid type variable bound by
        the instance declaration
        at /home/leif/Documents/type-level/src/Lib.hs:91:10-49
    • In the first argument of ‘autoParens’, namely ‘a’
      In the expression: autoParens a
      In the first argument of ‘unwords’, namely
        ‘[autoParens a, "*", autoParens b]’
    • Relevant bindings include
        a :: l (bound at /home/leif/Documents/type-level/src/Lib.hs:92:15)
        pretty :: Mul l r -> String
          (bound at /home/leif/Documents/type-level/src/Lib.hs:92:3)

And the same for autoParens b. I think I'm missing a LANGUAGE pragma somewhere that would prevent autoParens (Add _ _) from collapsing to Add l r -> String.

@alpmestan
Copy link
Contributor

Not this is an oversight from me, I tried to make a somewhat smart instance but at a point in the design space (and blog post) where we just can't expect what's below like this, we don't know what the left or right hand side of the multiplication hold, we would need to tweak the Pretty class to be augmented with some information about precedence etc.

Maybe it'd just be simpler to ignore the whole problem since the blog post isn't about that at all, and we have pretty printing libraries that can do this well?

Thanks for reporting the issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants