CMonoid cannot be converted to CFunctor by method invocation conversion

[Yo Eight]

Hi all !

During my attempt of giving Frege some monad transformer instances, I hit against what I think being a bug. Here's the code:

package frege.control.monad.Writer where

import frege.control.Monoid

data WriterT w m a = WriterT { run :: m (a, w) }

run :: WriterT w m a -> m (a, w)

run (WriterT k) = k

instance Functor Functor m => (WriterT w m) where

  fmap f (WriterT k) = WriterT $ fmap (\(a, w) -> (f a, w)) k

instance Applicative (Monoid w, Applicative m) => (WriterT w m) where

  return a = WriterT $ return (a, mempty)

  WriterT kf <*> WriterT ka = WriterT $ go <$> kf <*> ka

    where

      go (f, w) (a, w') = (f a, w <> w') -- guilty line

While this snippet seems syntactically correct and well typed, I get a surprising error message:

deiko:trunk yoeight$ java -Xss1m -jar fregec.jar -d build frege/contrib/yoeight/trans/WriterT.fr

running: javac -cp fregec.jar:build -d build -encoding UTF-8 build/frege/control/monad/Writer.java 

build/frege/control/monad/Writer.java:437: error: method m$3061589244fmap in class Consts cannot be applied to given types;

    return Consts.m$3061589244fmap(ctx$1);

                 ^

  required: CFunctor

  found: CMonoid

  reason: actual argument CMonoid cannot be converted to CFunctor by method invocation conversion

1 error

javac terminated with exit code 1

E frege/contrib/yoeight/trans/WriterT.fr:18: java compiler errors are most

    likely caused by erronous native definitions

I'm using 3.19.161 compiler version.

Any ideas ?

Regards,

Yorick

[Marimuthu Madasamy]

It looks like a bug. If we reverse the order of the constraints on Applicative declaration, it works:

instance Applicative (Applicative m, Monoid w) => (WriterT w m)

Regards,

Marimuthu

[Yo Eight]

I open a ticket then.

Thanks.

Yorick.

[Ingo W.]

In this case it is certainly a bug.

Yorrick, please reduce the offending frege code to the utmost and create an Issue on the project page

I will look into it.

[Yo Eight]

Here's the ticket

Regards,

Yorick

[Ingo W.]

Hi all,

looks like this instance thing is a terrible mess, currently.

In principle, if we have

class Sub  Base a => a

instance Base C1 => t

for some t and then

instance Sub C2 => t

it should hold for C2 that it must constrain t no less than C1.

Or, to put it differently, that C1 must be implied by C2.

Yet, this is currently checked nowhere in the compiler.

In addition, the order of individual constraints should be immaterial, but this is the lesser problem.

For example, the compiler accepts the following nonsense:

instance Base Ord a => Maybe a where

    base = error "base"

instance Sub Show a => Maybe a where

    sub  = error "sub"

Luckily, the generated code is not valid either, so javac stops this from being compiled.

It looks like I'll have to rethink (and recode) this one from ground up, so do not expect a quick fix.

In the meantime, please observe that C2 must imply C1 and, as a nasty side condition, that the order of constraints in C2 must match the order of corresponding constraints in C1 and new constraints in C2 must be put last.

Thus, in spite this being a severe compiler error, it does not prevent us from writing correct programs that will also have the same meaning once the error is fixed.

In short:

- Some correct programs are compiled correctly.

- Some correct programs are compiled to invalid java code. But by reordering constraints, one can obtain a semantically equivalent program that works.

- Some invalid programs are not diagnosed as such and are compiled to invalid java code.

Thanks to Yorrick for figuring this out, Thanks to Marimuthu for providing the essential workaround.

[Yo Eight]

No worries, my Coursera compiler class starts today anyway :)

[Ingo W.]

This (issue#12) is now fixed as of 3.20.29 and later.