Program Compiles With GHC 6.6 but not Hat

[Aditya Siram]

The following program compiles and runs on GHC 6.6 but fails to compile with
the '-hat' option to hmake. The error message is:
**Begin Output**
hat-trans   HatTest.hs
Wrote Hat/HatTest.hs
ghc-6.6      -c -package hat -o Hat/HatTest.o Hat/HatTest.hs

Hat/HatTest.hs:40:50:
    Ambiguous type variable `a' in the constraint:
      `Integral a'
        arising from use of `htakeodds' at Hat/HatTest.hs:40:50-58
    Probable fix: add a type signature that fixes these type variable(s)
**End Output**

The program source is:

import Prelude

takeodds xs = [ x | x <- xs, (mod x 2) ==0]

main = do { print (takeodds [1 ..7]); }


Thanks...
Deech

_________________________________________________________________
Talk now to your Hotmail contacts with Windows Live Messenger.
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get.live.com/messenger/overview

_______________________________________________
Hat mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hat

[Olaf Chitil]

This is caused by a limitation of Hat: Hat cannot handle defaulting of
numeric classes.

Your Haskell program makes use of defaulting: The main function could
work with numbers of either type Int or Integer. The Haskell defaulting
rule says that in such a case it should choose Integer.

To help Hat add a type annotation, e.g.

main = do { print (takeodds [(1::Integer) ..7]); }

To get a better error message, you could compile your original program
without -hat but with the additonal line

default()

which turns defaulting off and thus will yield an error message about an
ambiguous type variable referring to your original program.

In real programs we have hardly ever come across uses of defaulting.

Ciao,
Olaf


Aditya Siram wrote:

> The following program compiles and runs on GHC 6.6 but fails to
> compile with the '-hat' option to hmake. The error message is:
> **Begin Output**
> hat-trans   HatTest.hs
> Wrote Hat/HatTest.hs
> ghc-6.6      -c -package hat -o Hat/HatTest.o Hat/HatTest.hs
>
> Hat/HatTest.hs:40:50:
>    Ambiguous type variable `a' in the constraint:
>      `Integral a'
>        arising from use of `htakeodds' at Hat/HatTest.hs:40:50-58
>    Probable fix: add a type signature that fixes these type variable(s)
> **End Output**
>
> The program source is:
>
> import Prelude
>
> takeodds xs = [ x | x <- xs, (mod x 2) ==0]
>
> main = do { print (takeodds [1 ..7]); }
>
>
> Thanks...
> Deech
>
> _________________________________________________________________
> Talk now to your Hotmail contacts with Windows Live Messenger.
> http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get.live.com/messenger/overview 
>
>
> _______________________________________________
> Hat mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/hat

_______________________________________________
Hat mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hat

[Thomas Davie-2]

Olaf,
   This brings up something that's been niggling me for a while.  Why  
can Hat not deal with defaulting?  Surely it could be handled by the  
first stage of hat-trans being inserting explicit type signatures  
based on the standard defaulting rules?

Bob

On 17 Nov 2006, at 20:43, Olaf Chitil wrote:

>
> This is caused by a limitation of Hat: Hat cannot handle defaulting  
> of numeric classes.
>
> Your Haskell program makes use of defaulting: The main function  
> could work with numbers of either type Int or Integer. The Haskell  
> defaulting rule says that in such a case it should choose Integer.
>
> To help Hat add a type annotation, e.g.
>
> main = do { print (takeodds [(1::Integer) ..7]); }
>
> To get a better error message, you could compile your original  
> program without -hat but with the additonal line
>
> default()
>
> which turns defaulting off and thus will yield an error message  
> about an ambiguous type variable referring to your original program.
>
> In real programs we have hardly ever come across uses of defaulting.
>
> Ciao,
> Olaf
>
>
> Aditya Siram wrote:
>
>> The following program compiles and runs on GHC 6.6 but fails to  
>> compile with the '-hat' option to hmake. The error message is:
>> **Begin Output**
>> hat-trans   HatTest.hs
>> Wrote Hat/HatTest.hs
>> ghc-6.6      -c -package hat -o Hat/HatTest.o Hat/HatTest.hs
>>
>> Hat/HatTest.hs:40:50:
>>    Ambiguous type variable `a' in the constraint:
>>      `Integral a'
>>        arising from use of `htakeodds' at Hat/HatTest.hs:40:50-58
>>    Probable fix: add a type signature that fixes these type  
>> variable(s)
>> **End Output**
>>
>> The program source is:
>>
>> import Prelude
>>
>> takeodds xs = [ x | x <- xs, (mod x 2) ==0]
>>
>> main = do { print (takeodds [1 ..7]); }
>>
>>
>> Thanks...
>> Deech
>>
>> _________________________________________________________________
>> Talk now to your Hotmail contacts with Windows Live Messenger.  
>> http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?
>> href=http://get.live.com/messenger/overview
>>
>> _______________________________________________
>> Hat mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/hat
>
>
> _______________________________________________
> Hat mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/hat

_______________________________________________
Hat mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hat

[Bernie Pope]

On 18/11/2006, at 11:14 AM, Thomas Davie wrote:

> Olaf,
>   This brings up something that's been niggling me for a while.  
> Why can Hat not deal with defaulting?  Surely it could be handled  
> by the first stage of hat-trans being inserting explicit type  
> signatures based on the standard defaulting rules?
>
> Bob

That would require hat-trans to do type checking, wouldn't it?

Bernie.
_______________________________________________
Hat mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hat

[Malcolm Wallace]

Thomas Davie <[hidden email]> writes:

>    This brings up something that's been niggling me for a while.  Why  
> can Hat not deal with defaulting?  Surely it could be handled by the  
> first stage of hat-trans being inserting explicit type signatures  
> based on the standard defaulting rules?

We made a deliberate design decision that hat-trans should be entirely
syntax-directed - it does not do type inference.  There are good reasons
for this decision.

  * In a well-designed language, you would not need type information for
    the tracing transformation.  And indeed, Haskell is so well designed
    that you do not, except for this one very small (but very annoying)
    instance.
  * Implementing type inference is difficult enough that we did not
    consider the effort worthwhile for the tiny benefit of being able to
    handle defaulting.
  * In order to be able to handle all the many experimental type-system
    extensions accepted by a compiler like ghc, hat-trans would need to
    replicate ghc's type inference as exactly as possible.  Given the
    number of papers written about this very topic, that would not be an
    easy task!  But in fact, apart from defaulting, it is only necessary
    to _syntactically_ transform type signatures (where they are used),
    and the ghc type system can infer the rest.

Regards,
    Malcolm
_______________________________________________
Hat mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hat

[Neil Mitchell]

Hi

> >    This brings up something that's been niggling me for a while.  Why
> > can Hat not deal with defaulting?  Surely it could be handled by the
> > first stage of hat-trans being inserting explicit type signatures
> > based on the standard defaulting rules?
>
> We made a deliberate design decision that hat-trans should be entirely
> syntax-directed - it does not do type inference.  There are good reasons
> for this decision.

I have a plan to get round this :)

Yhc currently generates Core, which is a nice abstract Haskell like
language, close enough to the original to allow debugging in a
reasonable similar environment. If Yhc.Core was converted to Hat
traced Haskell then you'd get numeric defaulting for free.

It's not perfect, but it might be worth it to get more reliable (but
less accurate) Hat trace generation. I plan to do this sometime soon -
its probably a few hours work at maximum.

Thanks

Neil
_______________________________________________
Hat mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hat

[Neil Mitchell]

Hi

> >   This brings up something that's been niggling me for a while.
> > Why can Hat not deal with defaulting?  Surely it could be handled
> > by the first stage of hat-trans being inserting explicit type
> > signatures based on the standard defaulting rules?
> >
> > Bob
>
> That would require hat-trans to do type checking, wouldn't it?

One idea that _might_ work is to translate Int -> Integer, then you
get rid of defaulting integers, at the cost of changing the program
semantics ever so slightly. Personally I'd say the cost is more than
worth it, but I know some of the Hat developers disagree with me on
that.

Thanks

Neil
_______________________________________________
Hat mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hat

[Bernie Pope]

On 19/11/2006, at 10:07 AM, Neil Mitchell wrote:

> Hi
>
>> >   This brings up something that's been niggling me for a while.
>> > Why can Hat not deal with defaulting?  Surely it could be handled
>> > by the first stage of hat-trans being inserting explicit type
>> > signatures based on the standard defaulting rules?
>> >
>> > Bob
>>
>> That would require hat-trans to do type checking, wouldn't it?
>
> One idea that _might_ work is to translate Int -> Integer, then you
> get rid of defaulting integers, at the cost of changing the program
> semantics ever so slightly. Personally I'd say the cost is more than
> worth it, but I know some of the Hat developers disagree with me on
> that.
>
> Thanks
>
> Neil

Hi Neil,

I would also argue strongly against that approach.

It is important that debugging tools preserve the semantics of the  
underlying program as closely as possible.

You might remove a slightly inconvenient problem, but at the cost of  
introducing subtle and difficult-to-explain changes in program  
behaviour.

Probably the best solution is to lobby various compiler writers to  
generalise the defaulting mechanism, but that may be easier said than  
done :)

Cheers,
Bernie.
_______________________________________________
Hat mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hat

[Neil Mitchell]

Hi Bernie,

> I would also argue strongly against that approach.
>
> It is important that debugging tools preserve the semantics of the
> underlying program as closely as possible.

Yes, but if the alternative is to make debugging so annoying that no
one uses the debugging tool, then its probably a worthwhile trade off.
Currently I don't use Hat, as when I am ready to debug a Haskell
program (i.e. its broken) I can be pretty much 100% certain that it
won't work with Hat without several changes. At the point I am trying
to solve a complex bug, I don't want to go and do something else.


> Probably the best solution is to lobby various compiler writers to
> generalise the defaulting mechanism, but that may be easier said than
> done :)

If you came up with a concrete proposal, that was a generalisation of
the existing defaulting method, and provided an implementation for
GHC, you might have a lot more success at your attempts. (Certainly if
you implement in for Yhc, we'd accept it)

Thanks

Neil
_______________________________________________
Hat mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/hat