[jhc] Typechecker hiccup?

[John Meacham]

On Wed, Jul 18, 2007 at 09:45:19AM -0500, Samuel Bronson wrote:
> On 7/17/07, John Meacham <john at repetae.net> wrote:
> >On Tue, Jul 17, 2007 at 10:20:01PM +0000, Samuel J. J. Bronson wrote:
> >> I just tried to compile this program (based on figure one in "The GRIN 
> >Project:
> >> A Highly Optimising Back End for Lazy Functional Languages"):
> >>
> >>
> >> {-# OPTIONS_JHC -N -fffi #-}
> >>
> >> import Jhc.Basics
> >> import Jhc.Int
> >> import Jhc.Num
> >> import Jhc.Order
> >>
> >> default (Integer, Double)
> >>
> >> main = sum (upto 1 10)
> >>
> >> upto m n | m > n     = []
> >>          | otherwise = m : upto (m+1) n
> >>
> >> sum []     = 0
> >> sum (x:xs) = x + sum xs
> >>
> >>
> >> And I got a stupid error about a missing "put" method for IORef. It 
> >seems that
> >> the typechecker isn't getting rid of all the MetaVars in this program...
> >
> >hmm.. main not being an actual IO action doesn't behave too well with
> >overloading. (I really should make it just fail without an explicit
> >option saying you want to evaluate an expression)
> 
> I don't really want the code to work... I just want it to get a proper
> error. 

Oh, yeah. that is what I meant to say. I just got sidetracked. In
general, a lot of things that should be errors are not checked for. this
can lead to badness later in the compilation process. It is unfortunate
that there are still some user errors that are reported via a pattern
match failure somewhere in the front end :) (but it is much better than
it used to be)

>Also it's taking forever to compile the Prelude -- it's been
> compiling all night and it's still on the same line of output as when
> I went to bed... (I suspect that it would be on a different character
> if I hadn't piped it through tee and less, though).


Hmm.. this sounds wrong. it is possible there is an infinite loop
somewhere. if you compile with some combination of -dcore -dcore-mini
-dcore-steps -dcore-pass then you can usually find the culprit in these
cases. you will see the same optimizations repeating over and over
again. That is usually the cause.

Also, 'Show' and 'Read' instances for large data types tickle the
simplifer in a way that makes it take way way too long. quadratic or
even exponential behavior is sneaking in somewhere. 

> I'd be happy with an error from the typechecker, an error from
> E.FromHs, an error from an E pass... pretty much anything before it's
> trying to write an .ho file ;-).

yes. certainly. 


        John


-- 
John Meacham - ⑆repetae.net⑆john⑈