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.