Re: ghc-6.2 bug in type inference

"Simon Marlow" <simonmar@xxxxxxxxxxxxx> writes:

> >     *  package extra-ghc-opts are propagated to all 
> >        compilations, whether those compilations use that package or
> >        not.
> 
> Indeed - I don't recommend the use of extra_ghc_opts at all.

OK, noted.  I realised later that the extra options are only propagated
if the package is marked 'auto', but in any case, extra_ghc_opts does
seem like a bad idea, and I will it avoid in future.

> >     *  -fglasgow-exts makes perfectly reasonable Haskell'98 code
> >        invalid, throws up a totally misleading error unrelated to the
> >        cause of the problem, and gives no clue as to what particular
> >        extension is responsible.
> 
> Taking these in order:
> 
>  - -fglasgow-exts breaks Haskell 98 code: yes of course, because it
>    defines extra keywords for one thing.

Yes, I accept that.  Adding extra keywords is fine.  Stealing an
identifier (%) that already commonly means something else (as defined
in the Haskell'98 Libraries, no less! - it was even in the Prelude
once) is rather more confusing.

But I suppose what I was really objecting to was that, because of the
unfortunately behaviour of packages, I didn't even know -fglasgow-exts
was in effect.

>  - throws up a misleading error message:
>    I'm not sure if you're
>    talking about this specific case or error messages in general.

This specific case only.  Of course error messages are hard to get
right.  Take this as a suggestion for improving one particular case
that had me stumped for three days.

>                   You can report this as a bug if you like :-)

I thought I just did :-)

>  - gives no clue as to what extension is responsible: hmm, this is
>    a really hard problem too, isn't it?

For syntactic extensions perhaps, but for type extensions, no, it
is not all that hard.  For instance, the error message could have
included some text like

    "involving use of linear implicit parameter %s"

I'm sure most of the other type-system extensions (MPTC, ordinary
linear parameters, etc) could be mentioned in a few words likewise.
There must be /some/ information in the AST showing their presence.
Especially when the user has never heard of the feature being named,
this is a clue that they have tripped over an extension, and they
should investigate further, rather than being baffled (like me)
that the error message was seemingly incorrect.

>    Surely you don't mean that we
>    should figure out, for every error message, which set of extensions
>    if turned off would make the error go away?

Of course not.  But simply mentioning any extensions visibly in use
within the currently erroneous expression would be enough.

>    If I turn on FFI extensions in nhc98, does it helpfully remind me
>    what I've done wrong when I attempt to use 'foreign' as a function
>    name?

Touche!  (You can't turn off FFI extensions in nhc98...)

Regards,
    Malcolm