haskell reify, was sequencing data structures
Bernard James POPE
Thu, 21 Aug 2003 14:06:23 +1000 (EST)
> This interface looks pretty similar to the interfacein Hugs The module is
Yes. You may recall that I had something even closer to the Hugs interface
previously which I called GhcInternals. I modelled that on what Hugs
I even think that you suggested that we unify their designs. I agree,
but I don't think I replied, sorry about that. I think I got tangled up
in other problems and never got back to it.
Noone else said anything about that version, so I assumed that there was
very little interest in it - which is probably true.
> It seems to me that, with a little tweaking of the Buddha and Hugs.Internals
> interfaces, we could provide the same interface on both Hugs and GHC. (It's
> also pretty simple to implement so it could potentially be added to NHC98 as
I'm all for making a consistent interface. But I wonder what kind of
interface people would like and what they would want to do with it,
besides writing universal printers (which are very useful nonetheless).
Things that seem important (to me) are:
- Do you want to observe cycles and or sharing? Of course this is very
hard to do because of garbage collection. In buddha I observe cycles
but not other forms of sharing. To do this I have to be very careful
not to cause garbage collection when I'm traversing the heap.
I don't remember now whether you can observe cycles using the
Hugs internals interface. I _think_ that it was possible but I don't
- Do you want the ability to force thunks or just stop when you see them?
The incremental approach of the Hugs interface is nice, but I'm worried
that it will make the detection of cycles harder - that's the reason
I moved to reify in buddha away from Hugs style. (In buddha I just
want to print things up to the extent that they are evaluated when
reify is called, I stop when I see a thunk, cycle, nullary constructor).
- There needs to be some support from the compilers/interpreters. Hugs
already has this. Ghc has some of it, but I abuse the profiling system
in order to get the names of constructors to be present on the heap.
I'm not happy with this. Under normal compilation GHC doesn't keep
constructor names around, as far as I know. However, the new debugger
in GHC must do something to get names of things, so perhaps the
-prof hack is no longer needed?
GHC's heap representation is already quite intricate, and I wonder if
the implementors/maintainers would not want to introduce more
complexity for the sake of a library that few people might use?
I don't know what the case is with NHC, though I seem to recall
Malcolm or Olaf saying that such a thing would be possible, but I
might be making that up.