On Wed, Jun 29, 2005 at 12:11:22PM +0100, Thomas Davie wrote:

On 28 Jun 2005, at 21:03, Ken T Takusagawa wrote:

...

The following short program:

module Main where Just foo = undefined

Causes an error message: hmake -hat hatd.hs hat-trans hatd.hs Wrote Hat/hatd.hs /usr/bin/haskell-compiler -c -package hat -o Hat/hatd.o Hat/hatd.hs

Hat/hatd.hs:10:10: Qualified variable in pattern: T.mkRoot

with hat 2.0.4 and ghc 6.4-2 (debian)

My last reply I realise was somewhat useless - in that the addition of a main function still gives the error. However, I think that this is actually hat catching a syntactic error that the normal compilers don't catch... The haskell syntax states:

decl -> gendecl | (funlhs | pat0) rhs

where, gendecl covers type definitions, funlhs covers functions (and must start with a lower case character), and pat0 covers 0 arity paterns.

The 0 is the tightness of binding, not the arity. pat^0 -> pat^1 -> ... -> pat^10 -> gcon apat_1 Such contructs look a bit odd at the top level, but I think foo x = f y where Just y = x is more common. Even more so is [ x | Just x <- xs] Thanks Ian

Thomas Davie writes:

Okay, I see that, now I'm slightly intrigued -- if, as before, we have

Just foo = undefined

Doesn't that have 2 effects: foo = undefined undefined :: Maybe a

and thus cause a type error (i.e. undefined has become too specific)?

No, 'foo' does not literally gain the value of 'undefined'. In fact, foo gets no value at all, because the computation diverges before the pattern can be matched. /Semantically/ divergence is equivalent to 'undefined', but syntactically, 'foo' and 'undefined' are separate bindings, and their types are therefore not constrained to be equal. Regards, Malcolm

Thomas Davie writes:

...

No, 'foo' does not literally gain the value of 'undefined'. In fact, foo gets no value at all, because the computation diverges before the pattern can be matched. /Semantically/ divergence is equivalent to 'undefined', but syntactically, 'foo' and 'undefined' are separate bindings, and their types are therefore not constrained to be equal.

Okay, but does this not force undefined to have the type Maybe a?

i.e. Just x = undefined File y = undefined

would cause a type error?

'undefined :: forall a . a' is a truly polymorphic value, in fact the only possible value of such an unconstrained type. In your example, it is instantiated twice, at different actual types, just as for instance the polymorphic function 'map' can be instantiated at several different actual types: map toUpper "hello" map (+1) [1,2,3] The only place where instantiating a polymorphic value at different types might cause a problem is in a recursive definition where the usage occurrence is at a different type to the defining occurrence, e.g. f x = f [x] Most functional languages do not permit this because it makes type inference undecidable. However Haskell allows it, provided that you give an explicit type signature so full inference is not required. Regards, Malcolm

Bernard Pope writes:

...

...

Just foo = undefined

In Hat do you desugar the above code to:

v = undefined foo = (\Just x -> x) v

In short, yes. The tracing machinery then gets wrapped around the desugared version. Regards, Malcolm

hat-trans is generating bad code for this, because the pattern binding is at the toplevel. If the pattern binding were in a let or where clause, the generated code is different. When not at the toplevel, the parent, p, of the binding is always a variable passed in. But at the toplevel, there is no static parent, so hat-trans has wrongly substituted T.mkRoot (which explicitly represents no parent), in both the generated pattern and the generated expression:

gx px T.mkRoot = T.constUse px T.mkRoot sx -- incorrect vs. gx px p = T.constUse px p sx -- correct

I think the attached patch for hat-trans should fix the problem (but would like someone to confirm this is not going to break anything else, before I will commit it to CVS).

You are absolutely right. I just committed it to CVS. Ciao, Olaf