haskell reify, was sequencing data structures

[Bernard James POPE]

Hi,

Alistair writes:
> This interface looks pretty similar to the interfacein Hugs  The module is 
> hugs98/libraries/Hugs/Internals.hs:

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
provides.

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 
> well.)

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
     remember. 

   - 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.

Cheers,
Bernie.