Hi all, Apologies for my large number of postings to this list of late.

the normal definition of WHNF applies only to types containing _|_, i.e. pointed types. Unpointed types are never represented by thunks, so I would be inclined to include them in WHNF.

Yes, I agree here. It is useful for me since I am using WHNF to determine whether expressions are evaluated. Perhaps it is a slight abuse of the terminology, but it gives me what I want :)

You also have to deal with indirections, although you can assume (at the moment) that an indirection will eventually lead to an object in WHNF.

Good point. I did make this assumption. Well to be precise I made the assumption that the thunk and indirection closure flags were mututally exclusive. If things change I guess I will have to follow the indirections. currently my definition is: #define isHNFzh(r,a) r=(! closure_THUNK((StgClosure *)a)) I believe under this definition that unpointed types and indirections are considered to be in WHNF. My initial tests seem to indicate that this is working well.

You have to declare the primitive like this, BTW:

isWHNF# :: a -> (# State# RealWorld, Int# #)

because the compiler doesn't know about the IO type and you can't return a Bool directly.

I'm not too fussed about the unboxed Int, although as Marcin points out it does look like some of the comparision primops can return a Bool. I couldn't figure out how they did it so I left it with the Int#.

There's no problem with the simplifier as long as you declare the primitive to have the correct properties, i.e. that the polymorphic argument is lazy.

Great.

It sounds like you also need a way to take apart arbitrary objects and look at their components.

Yes indeed. I use type classes for this with deriving rules for user defined types. I'm in the midst of writing this up for IFL, in Stockholm, mid September. In particular, I am looking for "portable" ways of taking objects apart, that's why type classes are attractive. Of course, isWHNF cannot be written in Haskell, but if I can get it to work for Hugs, GHC and NHC, then that is good enough for me :) What I hope is that some of this can appear as a Meta-programming library for Haskell, which is more powerful than Read and Show. Something a bit similar to the semantic domain of Meta-ML.

I know that Andy Gill was also interested in having similar facilities, perhaps he can help out.

I wonder if Andy is reading this? Possibly there are other people around who are also interested in this. I think the HAT people at NHC headquarters are also interested in these things. There once was talk of starting a debugging group for Haskell, but I don't know what happened. Thanks heaps for your help. Bernie.