Re: Type error for function main

On Thu, 16 Oct 2003, Ross Paterson wrote:

> On Thu, Oct 16, 2003 at 02:35:26PM +0200, Josef Svenningsson wrote:
> > I was just trying to write the smallest valid Haskell program. One try was
> > the following:
> >
> > > main = return 0
>
> Much too long -- 9 characters are enough.
>
I know that my above try isn't optimal but I have only managed to get it
down to 11 characters. Care to share your solution?


> > But I get the following error message:
> > ERROR "foo.hs":1 - Unresolved top-level overloading
> > *** Binding             : main
> > *** Outstanding context : Monad c
> >
> > Why do I get this? According to the Haskell report a module where one
> > doesn't specify the name should implicitly be called Main. And a Main
> > module have a function main of type IO t for some t. So Hugs should be
> > able to figure out that the monad should be IO in this case, at least
> > according the Haskell report.
>
> I'm not so sure.  It could well be argued from 4.5.5 that type inference
> for this binding group leaves the type variable ambiguous, and that the
> restriction on the type of main is supposed to be a later restriction.
> (And Hugs does the Monomorphism Restriction differently anyway.)
> Hugs already departs from the Report in not requiring that anonymous
> modules define main (to cater for people who can't be bothered with
> a module header for little things).  It would take a special case to
> handle main, it's not clear it's necessary, and who else would care?
>
Yes, I know Hugs doesn't do exactly what the report says when it comes to
modules. Despite what it may have sounded like in my previous mail I don't
think this is a very important issue. If you don't care to fix it I won't
be upset. It just seemed natural to enforce the type of main to be IO
whenever the module is called Main. But I guess it's because Hugs doesn't
care to call the module Main in case the header is omitted that this gets
unnecessarily complicated to implement.

Oh, well.

	/Josef