HSP and GHC 7
stepcut
HSP fails to build under GHC 7. The error messages is reported here:
http://code.google.com/p/hsp/issues/detail?id=6
I assume it is related to the new type-checker, but I have not be able
to figure out exactly what is going on yet.
Adding an explicit type sig to the part after asChild makes the
compiler happy:
instance Monad m => EmbedAsChild (HSPT' m) (Block t) where
asChild b = asChild $
(<script type="text/javascript">
<% show b %>
</script> :: (Monad m) => XMLGenT (HSPT' m) XML)
But it makes HSP really annoying to use, because this issue arises in
a lot of end-user HSP code.
As the warning suggests, you could also enable IncoherentInstances.
But I have never enabled that and not regretted it. So, a fix that
does not require explicit signatures or incohorent instances would be
swell..
- jeremy
Niklas Broberg
serious about this at this point.
However, I notice that the errors pertain to the use of TypeCast.
Possibly, hopefully, removing that hack and moving to equality
constraints proper might make it work again. No promises as to when I
can sit down and think about it though.
Cheers,
/Niklas
> --
> You received this message because you are subscribed to the Google Groups "Haskell Server Pages" group.
> To post to this group, send email to haskell-se...@googlegroups.com.
> To unsubscribe from this group, send email to haskell-server-p...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/haskell-server-pages?hl=en.
>
>
stepcut
Switching to equality constraints made everything compile. Do you want
a patch which removes TypeCast completely, or one that uses ifdef's to
support both variants depending on compiler version. I think ~ was
added in 6.10?
- jeremy
Jeremy Shaw
fix the error in HSP..
- jeremy
Jeremy Shaw
This instance fails:
instance (Monad m) => EmbedAsChild (HSPT' m) (Block t) where
asChild b = asChild $
<script type="text/javascript">
<% show b %>
</script>
But only when this instance is present:
instance EmbedAsChild (HSPT' m) (XMLGenT HJScript' ()) where
asChild script = asChild . snd $ evalHJScript script
because we also have this instance:
instance (EmbedAsChild m c, m1 ~ m) => EmbedAsChild m (XMLGenT m1 c) where
asChild m = asChild =<< m
So, we have two different ways to embed an XMLGenT inside of m, and
the compiler can't figure out which to use. I am not sure if this is
because it shouldn't have worked in the first place, or because of a
bug in the new type checker, or an intentional change in the way
things work...
- jeremy
Niklas Broberg
>
> instance EmbedAsChild (HSPT' m) (XMLGenT HJScript' ()) where
> asChild script = asChild . snd $ evalHJScript script
>
> because we also have this instance:
>
> instance (EmbedAsChild m c, m1 ~ m) => EmbedAsChild m (XMLGenT m1 c) where
> asChild m = asChild =<< m
So I guess this is the real meat of the problem. We have two different
XML generator monad transformers, HSPT' and HJScript'. The second
instance says that generated inner elements should be in the same
generator as the outer element in which it is embedded. The first
instance tries to embed one type of generator inside another.
When implementing this, I believed that the default (second) instance
would only be applicable if the first one "failed", being less
specific, but reading SPJ [1] I can see that this was a somewhat naive
assumption (even though it's actually worked for a long time!). I
haven't entirely been able to convince myself that the situation SPJ
talks about (Jeremy's minimized bug report) is actually the same as
the one we're discussing here, but it seems to be similar enough...
At any rate, if we can't find a way to solve this using flags or
whathaveyou, it seems to me that we still should be able to salvage
the situation by removing the first instance above, replacing it with
some explicit application of some combinator that the programmer has
to call, that runs the HJScript and returns a block that can then be
embedded normally.
Btw, Jeremy, the reason for introducing XMLGenT in the first place is
exactly the second instance above. Without that transformer there
would be no way at all to create a reasonable defaulting instance,
which would mean that all nested tags would have to be explicitly
typed everywhere - not feasible!
Cheers,
/Niklas
[1]http://hackage.haskell.org/trac/ghc/ticket/4485#comment:2
stepcut
going to work.
We tried it on our local code base, and it does make everything
compile, but the server just loops when it tries to render the page.
(ignoring a bunch of context), when i have this:
> return $ (<li><% show doc %></li>)
Which gets embedded as a child, it gets stuck in a loop. if I add a
type signature:
> return $ (<li><% show doc %></li> :: XMLGenT SeeReasonPart XML)
Then it renders. So, that leads me to believe that it is not picking
the instance we want and is getting stuck in a loop. But when we force
it to pick the right instance, everything is ok.
Obviously, code that compiles with no errors, but then loops because
the wrong instance was used is not an acceptable solution.
So, I guess the next step is to try to remove the instances that cause
incoherence in the first place?
By 'first one' did you mean:
> instance EmbedAsChild (HSPT' m) (XMLGenT HJScript' ()) where d
- jeremy
Niklas Broberg
> incoherence in the first place?
>
> By 'first one' did you mean:
>
>> instance EmbedAsChild (HSPT' m) (XMLGenT HJScript' ()) where d
>> asChild script = asChild . snd $ evalHJScript script
Yes, exactly. I propose we instead introduce a combinator like (naming
suggestions welcome)
script :: HJScript () -> Block ()
script = snd . evalHJScript
With the instance 'EmbedAsChild (HSPT' m) (Block t)', we could then
embed HJScript () values inside HSPT by e.g.
foo = <div><% script s %></div>
instead of just saying s in the code brackets.
Cheers,
/Niklas