Program Compiles With GHC 6.6 but not Hat

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://c
lk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=ht
tp://get.live.com/messenger/overview

_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

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://c
lk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=ht
tp://get.live.com/messenger/overview 
>
>
> _______________________________________________
> Hat mailing list
> Hathaskell.org
> http://ww
w.haskell.org/mailman/listinfo/hat


_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

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/d
irect/01/? 
>> href=http://get.liv
e.com/messenger/overview
>>
>> _______________________________________________
>> Hat mailing list
>> Hathaskell.org
>> http://ww
w.haskell.org/mailman/listinfo/hat
>
>
> _______________________________________________
> Hat mailing list
> Hathaskell.org
> http://ww
w.haskell.org/mailman/listinfo/hat

_______________________________________________
Hat mailing list
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

Thomas Davie <tatd2kent.ac.uk> 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
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

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
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

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
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

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
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

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
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat

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
Hathaskell.org
http://ww
w.haskell.org/mailman/listinfo/hat