Discussion:
Proposal: Num instance for (a -> b)
Add Reply
Daniel Cartwright
2018-11-11 04:47:47 UTC
Reply
Permalink
relevant reddit comment thread:
https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_source=reddit-android

instance Num b => Num (a -> b) where
f + g = \x -> f x + g x
f * g = \x -> f x * g x
f - g = \x -> f x - g x
negate f = \x -> negate (f x)
abs f = \x -> abs (f x)
signum f = \x -> signum (f x)
fromInteger i = \x -> fromInteger (f x)
Henning Thielemann
2018-11-11 04:54:44 UTC
Reply
Permalink
relevant reddit comment thread:https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632

In short: It would make 2(x+y) no longer a type error but equivalent to 2.
We would lose a lot of type safety for little syntactic gain.
Henning Thielemann
2018-11-11 05:00:46 UTC
Reply
Permalink
Post by Henning Thielemann
Post by Daniel Cartwright
relevant reddit comment
thread:https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
In short: It would make 2(x+y) no longer a type error but equivalent to 2. We
would lose a lot of type safety for little syntactic gain.
Btw. before adding more Wat instances please implement the GHC warning
about such instances:
https://ghc.haskell.org/trac/ghc/ticket/11796
Dannyu NDos
2018-11-11 05:04:23 UTC
Reply
Permalink
I suggest adding this as an orphan instance (Like Show (a -> b)) in a
seperate module (say, Numeric.Function).
Post by Daniel Cartwright
Post by Henning Thielemann
Post by Daniel Cartwright
relevant reddit comment
https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
Post by Henning Thielemann
Post by Daniel Cartwright
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
Post by Henning Thielemann
In short: It would make 2(x+y) no longer a type error but equivalent to
2. We
Post by Henning Thielemann
would lose a lot of type safety for little syntactic gain.
Btw. before adding more Wat instances please implement the GHC warning
https://ghc.haskell.org/trac/ghc/ticket/11796
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Henning Thielemann
2018-11-11 05:15:11 UTC
Reply
Permalink
I suggest adding this as an orphan instance (Like Show (a -> b)) in a seperate module (say, Numeric.Function).
https://hackage.haskell.org/package/NumInstances

It would not save much, because in a reasonably big project you will
somewhen import a package that transitively depends on the module. E.g.
'diagrams-canvas' depends on NumInstances.
Tom Murphy
2018-11-11 05:27:52 UTC
Reply
Permalink
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
relevant reddit comment
thread:https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
In short: It would make 2(x+y) no longer a type error but equivalent to 2. We
would lose a lot of type safety for little syntactic gain.
Btw. before adding more Wat instances please implement the GHC warning
https://ghc.haskell.org/trac/ghc/ticket/11796
This is my feeling as well.

Tom
Dan Burton
2018-11-11 06:36:04 UTC
Reply
Permalink
-1, per the very confusing errors that would ensue.

If this behavior is desired, you can use a newtype wrapper. As it happens,
this fits the pattern of ANum <http://hackage.haskell.org/package/ANum>.
(Any Applicative can be made an instance of Num in this way.)

-- Dan Burton
Post by Daniel Cartwright
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
relevant reddit comment
https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
Post by Henning Thielemann
Post by Henning Thielemann
In short: It would make 2(x+y) no longer a type error but equivalent to
2.
Post by Henning Thielemann
Post by Henning Thielemann
We
would lose a lot of type safety for little syntactic gain.
Btw. before adding more Wat instances please implement the GHC warning
https://ghc.haskell.org/trac/ghc/ticket/11796
This is my feeling as well.
Tom
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-11-11 21:44:12 UTC
Reply
Permalink
ANum seems to be just Data.Monoid.Ap.
Also, I can see not wanting to worsen the error messages, though it is
worth pointing out that we already have a Monoid instance with the same
semantics, and a similar potential for confusing error messages.
Post by Dan Burton
-1, per the very confusing errors that would ensue.
If this behavior is desired, you can use a newtype wrapper. As it happens,
this fits the pattern of ANum <http://hackage.haskell.org/package/ANum>.
(Any Applicative can be made an instance of Num in this way.)
-- Dan Burton
Post by Daniel Cartwright
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
relevant reddit comment
https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
Post by Henning Thielemann
Post by Henning Thielemann
In short: It would make 2(x+y) no longer a type error but equivalent
to 2.
Post by Henning Thielemann
Post by Henning Thielemann
We
would lose a lot of type safety for little syntactic gain.
Btw. before adding more Wat instances please implement the GHC warning
https://ghc.haskell.org/trac/ghc/ticket/11796
This is my feeling as well.
Tom
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Oleg Grenrus
2018-11-11 22:10:43 UTC
Reply
Permalink
Monoid doesn't have fromInteger -like function. For example, we don't have FromString b => FromString (a -> b) instance.

Unfortunately fromInteger is part of Num, so comparison with Monoid is unjust.

Sent from my iPhone
Post by Daniel Cartwright
ANum seems to be just Data.Monoid.Ap.
Also, I can see not wanting to worsen the error messages, though it is worth pointing out that we already have a Monoid instance with the same semantics, and a similar potential for confusing error messages.
Post by Dan Burton
-1, per the very confusing errors that would ensue.
If this behavior is desired, you can use a newtype wrapper. As it happens, this fits the pattern of ANum. (Any Applicative can be made an instance of Num in this way.)
-- Dan Burton
Post by Tom Murphy
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
relevant reddit comment
thread:https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
In short: It would make 2(x+y) no longer a type error but equivalent to 2. We
would lose a lot of type safety for little syntactic gain.
Btw. before adding more Wat instances please implement the GHC warning
https://ghc.haskell.org/trac/ghc/ticket/11796
This is my feeling as well.
Tom
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-11-11 22:30:15 UTC
Reply
Permalink
I'm not quite sure the comparison is unjust - i was referring to +,-,*
giving strange error messages, not necessarily fromInteger. Recall that the
instance is Monoid b => Monoid (a -> b).

An example is a user might mistakenly type `mempty "text"`, which is just
`const mempty`, though this might not be what they mean (GHC 8.6 will give
the hole in `f :: Text -> Text; f x = _ x;` a suggestion of `mempty`, which
might certainly be confusing to a beginner). Similarly `2 4` might parse 2
as being applied to 4, if (a -> b) had a Num instance (correct me if i'm
wrong in saying thats how such a string might be parsed).
Post by Oleg Grenrus
Monoid doesn't have fromInteger -like function. For example, we don't have
FromString b => FromString (a -> b) instance.
Unfortunately fromInteger is part of Num, so comparison with Monoid is unjust.
Sent from my iPhone
ANum seems to be just Data.Monoid.Ap.
Also, I can see not wanting to worsen the error messages, though it is
worth pointing out that we already have a Monoid instance with the same
semantics, and a similar potential for confusing error messages.
Post by Dan Burton
-1, per the very confusing errors that would ensue.
If this behavior is desired, you can use a newtype wrapper. As it
happens, this fits the pattern of ANum
<http://hackage.haskell.org/package/ANum>. (Any Applicative can be made
an instance of Num in this way.)
-- Dan Burton
Post by Daniel Cartwright
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
relevant reddit comment
https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
Post by Henning Thielemann
Post by Henning Thielemann
In short: It would make 2(x+y) no longer a type error but equivalent
to 2.
Post by Henning Thielemann
Post by Henning Thielemann
We
would lose a lot of type safety for little syntactic gain.
Btw. before adding more Wat instances please implement the GHC warning
https://ghc.haskell.org/trac/ghc/ticket/11796
This is my feeling as well.
Tom
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-11-11 22:42:20 UTC
Reply
Permalink
Sorry, the parsing is tied to fromInteger. So i see what you mean about the
poor errors not being as comparable. Henning and another brought up a good
point, that either users ought to be warned or it would go in its own
module ala Text.Show.Function.
Post by Daniel Cartwright
I'm not quite sure the comparison is unjust - i was referring to +,-,*
giving strange error messages, not necessarily fromInteger. Recall that the
instance is Monoid b => Monoid (a -> b).
An example is a user might mistakenly type `mempty "text"`, which is just
`const mempty`, though this might not be what they mean (GHC 8.6 will give
the hole in `f :: Text -> Text; f x = _ x;` a suggestion of `mempty`, which
might certainly be confusing to a beginner). Similarly `2 4` might parse 2
as being applied to 4, if (a -> b) had a Num instance (correct me if i'm
wrong in saying thats how such a string might be parsed).
Post by Oleg Grenrus
Monoid doesn't have fromInteger -like function. For example, we don't
have FromString b => FromString (a -> b) instance.
Unfortunately fromInteger is part of Num, so comparison with Monoid is unjust.
Sent from my iPhone
ANum seems to be just Data.Monoid.Ap.
Also, I can see not wanting to worsen the error messages, though it is
worth pointing out that we already have a Monoid instance with the same
semantics, and a similar potential for confusing error messages.
Post by Dan Burton
-1, per the very confusing errors that would ensue.
If this behavior is desired, you can use a newtype wrapper. As it
happens, this fits the pattern of ANum
<http://hackage.haskell.org/package/ANum>. (Any Applicative can be made
an instance of Num in this way.)
-- Dan Burton
Post by Daniel Cartwright
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
relevant reddit comment
https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
Post by Henning Thielemann
Post by Henning Thielemann
In short: It would make 2(x+y) no longer a type error but equivalent
to 2.
Post by Henning Thielemann
Post by Henning Thielemann
We
would lose a lot of type safety for little syntactic gain.
Btw. before adding more Wat instances please implement the GHC warning
https://ghc.haskell.org/trac/ghc/ticket/11796
This is my feeling as well.
Tom
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Cartwright
2018-11-11 22:46:37 UTC
Reply
Permalink
It would be nice if the Semiring/Ring[1] parts of Num were pulled into its
own class. The overloading of integer literals to functions does seem
disruptive.

[1]:
http://hackage.haskell.org/package/semirings-0.2.1.1/docs/Data-Semiring.html
Post by Daniel Cartwright
Sorry, the parsing is tied to fromInteger. So i see what you mean about
the poor errors not being as comparable. Henning and another brought up a
good point, that either users ought to be warned or it would go in its own
module ala Text.Show.Function.
Post by Daniel Cartwright
I'm not quite sure the comparison is unjust - i was referring to +,-,*
giving strange error messages, not necessarily fromInteger. Recall that the
instance is Monoid b => Monoid (a -> b).
An example is a user might mistakenly type `mempty "text"`, which is just
`const mempty`, though this might not be what they mean (GHC 8.6 will give
the hole in `f :: Text -> Text; f x = _ x;` a suggestion of `mempty`, which
might certainly be confusing to a beginner). Similarly `2 4` might parse 2
as being applied to 4, if (a -> b) had a Num instance (correct me if i'm
wrong in saying thats how such a string might be parsed).
Post by Oleg Grenrus
Monoid doesn't have fromInteger -like function. For example, we don't
have FromString b => FromString (a -> b) instance.
Unfortunately fromInteger is part of Num, so comparison with Monoid is unjust.
Sent from my iPhone
ANum seems to be just Data.Monoid.Ap.
Also, I can see not wanting to worsen the error messages, though it is
worth pointing out that we already have a Monoid instance with the same
semantics, and a similar potential for confusing error messages.
Post by Dan Burton
-1, per the very confusing errors that would ensue.
If this behavior is desired, you can use a newtype wrapper. As it
happens, this fits the pattern of ANum
<http://hackage.haskell.org/package/ANum>. (Any Applicative can be
made an instance of Num in this way.)
-- Dan Burton
Post by Daniel Cartwright
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
relevant reddit comment
https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
Post by Henning Thielemann
Post by Henning Thielemann
In short: It would make 2(x+y) no longer a type error but
equivalent to 2.
Post by Henning Thielemann
Post by Henning Thielemann
We
would lose a lot of type safety for little syntactic gain.
Btw. before adding more Wat instances please implement the GHC
warning
Post by Henning Thielemann
https://ghc.haskell.org/trac/ghc/ticket/11796
This is my feeling as well.
Tom
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Dan Burton
2018-11-12 03:38:09 UTC
Reply
Permalink
The overloading of integer literals to functions does seem disruptive.
Most, if not all, of my objection has to do with the concern that integer
literals (and floating point literals, if functions also got a comparable
Floating instance) could be accidentally used as functions. Everything else
about these potential instances seems benign.

-- Dan Burton
It would be nice if the Semiring/Ring[1] parts of Num were pulled into its
own class. The overloading of integer literals to functions does seem
disruptive.
http://hackage.haskell.org/package/semirings-0.2.1.1/docs/Data-Semiring.html
Post by Daniel Cartwright
Sorry, the parsing is tied to fromInteger. So i see what you mean about
the poor errors not being as comparable. Henning and another brought up a
good point, that either users ought to be warned or it would go in its own
module ala Text.Show.Function.
Post by Daniel Cartwright
I'm not quite sure the comparison is unjust - i was referring to +,-,*
giving strange error messages, not necessarily fromInteger. Recall that the
instance is Monoid b => Monoid (a -> b).
An example is a user might mistakenly type `mempty "text"`, which is
just `const mempty`, though this might not be what they mean (GHC 8.6 will
give the hole in `f :: Text -> Text; f x = _ x;` a suggestion of `mempty`,
which might certainly be confusing to a beginner). Similarly `2 4` might
parse 2 as being applied to 4, if (a -> b) had a Num instance (correct me
if i'm wrong in saying thats how such a string might be parsed).
Post by Oleg Grenrus
Monoid doesn't have fromInteger -like function. For example, we don't
have FromString b => FromString (a -> b) instance.
Unfortunately fromInteger is part of Num, so comparison with Monoid is unjust.
Sent from my iPhone
ANum seems to be just Data.Monoid.Ap.
Also, I can see not wanting to worsen the error messages, though it is
worth pointing out that we already have a Monoid instance with the same
semantics, and a similar potential for confusing error messages.
Post by Dan Burton
-1, per the very confusing errors that would ensue.
If this behavior is desired, you can use a newtype wrapper. As it
happens, this fits the pattern of ANum
<http://hackage.haskell.org/package/ANum>. (Any Applicative can be
made an instance of Num in this way.)
-- Dan Burton
Post by Daniel Cartwright
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
relevant reddit comment
https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_so
Post by Henning Thielemann
Post by Henning Thielemann
Post by Daniel Cartwright
urce=reddit-android
https://wiki.haskell.org/index.php?title=Num_instance_for_functions&oldid=36632
Post by Henning Thielemann
Post by Henning Thielemann
In short: It would make 2(x+y) no longer a type error but
equivalent to 2.
Post by Henning Thielemann
Post by Henning Thielemann
We
would lose a lot of type safety for little syntactic gain.
Btw. before adding more Wat instances please implement the GHC
warning
Post by Henning Thielemann
https://ghc.haskell.org/trac/ghc/ticket/11796
This is my feeling as well.
Tom
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Jon Fairbairn
2018-11-12 10:16:15 UTC
Reply
Permalink
Post by Daniel Cartwright
ANum seems to be just Data.Monoid.Ap.
Also, I can see not wanting to worsen the error messages, though it is
worth pointing out that we already have a Monoid instance with the same
semantics, and a similar potential for confusing error messages.
The existence of a previous bad decision doesn’t seem to me to
be a good reason to make another one.
--
Jón Fairbairn ***@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2014-04-05)
Daniel Cartwright
2018-11-12 13:14:06 UTC
Reply
Permalink
I'm not sure I would label it a bad decision, but the concerns here make
sense.
Post by Daniel Cartwright
ANum seems to be just Data.Monoid.Ap.
Also, I can see not wanting to worsen the error messages, though it is
worth pointing out that we already have a Monoid instance with the same
semantics, and a similar potential for confusing error messages.
The existence of a previous bad decision doesn’t seem to me to
be a good reason to make another one.
--
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2014-04-05)
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Dannyu NDos
2018-11-11 04:55:17 UTC
Reply
Permalink
I'm +1 on this, since it is conventional to write addition (and others)
over function as such in most math textbooks.
Post by Daniel Cartwright
https://www.reddit.com/r/haskell/comments/9vtis5/the_universe_of_discourse_i_hate_the_environment/e9f1lea?utm_source=reddit-android
instance Num b => Num (a -> b) where
f + g = \x -> f x + g x
f * g = \x -> f x * g x
f - g = \x -> f x - g x
negate f = \x -> negate (f x)
abs f = \x -> abs (f x)
signum f = \x -> signum (f x)
fromInteger i = \x -> fromInteger (f x)
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Anthony Clayden
2018-11-17 04:48:32 UTC
Reply
Permalink
relevant reddit comment thread: ...
Are you people completely nuts? Haven't you wreaked enough havoc with
the Foldable Traversable Piffle?

Why ref pointy-headed discussion on reddit when you could also ref far
more frequent complaints:

https://blog.plover.com/prog/haskell/type-errors.html
"I think there must be something really wrong with the language design
here. I don't know exactly what it is, but I think someone must have
made the wrong tradeoff at some point."

https://blog.plover.com/prog/haskell/evaluation-functor-2.html
https://blog.plover.com/prog/haskell/evaluation-functor.html

(It's by no means only that author complaining; it's just that was
easiest to grab.)

No, EKmett, including `length` in `Foldable` with a `((,) a)` instance
is a lot more serious than "somewhat unfortunate".
At what point is it better to put "weird" stuff into its own libraries (or newtypes) and keep base clean?
Always the standard Prelude should be clean of "weird" stuff. So that
beginners don't have to go round the houses to exclude the standard
and get a sensible Prelude. A beginner has more than enough to cope
with without piling the import mechanism on them.

Whereas it's no burden on the pointy-heads to import WeirdPrelude.

If the CLC process were to do anything useful, I'd expect yous to be
organising that. And then I could leave yew lot to turn your Haskell
into Perl, where any composition of symbols can acquire some meaning.

As it is, the only reason I monitor the Libraries list is to complain
about proposals for nuttiness.

AntC
Henning Thielemann
2018-11-17 10:23:08 UTC
Reply
Permalink
 relevant reddit comment thread: ...
Are you people completely nuts? Haven't you wreaked enough havoc with the Foldable Traversable Piffle?
I am still using at most GHC-7.8.4 as main compiler because of broken type
safety starting from GHC-7.10. Breaking type safety for everyone was
achieved quickly, but restoring at least a bit of it for the ones who care
will certainly not happen for years (presumedly not before more Wats are
implemented):
https://ghc.haskell.org/trac/ghc/ticket/11796

However, I cannot see how this relates to the Foldable desaster or to the
https://blog.plover.com/prog/haskell/type-errors.html
"I think there must be something really wrong with the language design here. I don't know exactly what it is, but
I think someone must have made the wrong tradeoff at some point."
Since he already defined 'adj' as top-level function, I'd suggest he gives
it a monomorphic type signature and all type ambiguities are gone.
Top-level type signatures are good style anyway.

Loading...