Re: [Haskell-cafe] retrospective on 'seq' - 'unsafeSeq' ?
Bernie Pope [EMAIL PROTECTED] writes: Of course, [unsafeShow] won't be able to print functions in any helpful way, unless we attach source code information to functions as well (which may be worth doing anyway?). It might not be able to print the function's definition, but perhaps its type? One thing to watch out for is cycles in data structures. You may not want to try to detect them, but at least you should be lazy in generating the printable representation of values. For debugging output, I find I often limit output to avoid this. For instance, I defined this helper function for XML parser debugging: showSome :: [Tag] - String showSome a@(_:_:_:_:_:_:_) = (init . show . take 5 $ a)++ ... ] showSome a = show a with a typical error call: then error (Couldn't find tag '++show tag++' in\n++showSome list) Come to think of it, ghci's print-bind-result functionality could benefit from something like that... I also think it would be nice if unsafeShow could be available also in compiled code, not just ghci - e.g. sometimes you might want a mere user to run your application with debugging turned on. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] retrospective on 'seq' - 'unsafeSeq' ?
Hi unrestricted polymorphic was mainly a debugging problem. I wondered if the better solution would have been to provide an 'unsafeSeq' which has no type restriction but must be absent from production code just like 'trace'. That would be very neat! type constraints accordingly. (Analogously there could be an unsafeShow that allows showing offending values in an 'error' without adding a Show constraint to the type signature.) Ideally, unsafeShow could also show types as they are underneath, not as a pretty-printing Show might show them. I have often wanted to overload Show to print things in a readable way, but to have a showRaw which shows things as they are, for debugging purposes. I have even written such code for Yhc: http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-ShowRaw.html I think unsafeShow is a fantastic idea - and would be much more useful to me than unsafeSeq - plus is a non-breaking change. I think Hugs already has 90% of the code to support this, and GHCi's debugger I think has a fair chunk of it, so it could be added given not too much work. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] retrospective on 'seq' - 'unsafeSeq' ?
| type constraints accordingly. (Analogously there could be an unsafeShow that | allows showing offending values in an 'error' without adding a Show | constraint to the type signature.) | | Ideally, unsafeShow could also show types as they are underneath, not | as a pretty-printing Show might show them. I have often wanted to | overload Show to print things in a readable way, but to have a showRaw | which shows things as they are, for debugging purposes. I have even | written such code for Yhc: | http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-ShowRaw.html | | I think unsafeShow is a fantastic idea - and would be much more useful | to me than unsafeSeq - plus is a non-breaking change. I think Hugs | already has 90% of the code to support this, and GHCi's debugger I | think has a fair chunk of it, so it could be added given not too much | work. Yes, as you say, the debugger has most of the machinery. I just don't know what it'd take to make it a callable function. Pepe? Someone might want to make a feature-request ticket for this, with as much background and/or suggested design as poss. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] retrospective on 'seq' - 'unsafeSeq' ?
On 14/04/2008, at 12:19, Simon Peyton-Jones wrote: | type constraints accordingly. (Analogously there could be an unsafeShow that | allows showing offending values in an 'error' without adding a Show | constraint to the type signature.) | | Ideally, unsafeShow could also show types as they are underneath, not | as a pretty-printing Show might show them. I have often wanted to | overload Show to print things in a readable way, but to have a showRaw | which shows things as they are, for debugging purposes. I have even | written such code for Yhc: | http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-ShowRaw.html | | I think unsafeShow is a fantastic idea - and would be much more useful | to me than unsafeSeq - plus is a non-breaking change. I think Hugs | already has 90% of the code to support this, and GHCi's debugger I | think has a fair chunk of it, so it could be added given not too much | work. Yes, as you say, the debugger has most of the machinery. I just don't know what it'd take to make it a callable function. Pepe? Someone might want to make a feature-request ticket for this, with as much background and/or suggested design as poss. unsafeShow sounds quite useful, especially to avoid adding a Show constraint in function signatures only for debugging (of course a decent refactoring tool for Haskell would help with this too, so I hope the HaRe SoC project proposal gets accepted and done!). :print has the code for doing this, but it needs the type information collected by the compiler. In GHC API speak, it needs the HscEnv from the Session object. If we can expose the Session created for GHCi (how? exporting it from GHC.Main? in a thread-local object? FFI trickery?), then this would need nearly zero work, albeit it would print things only when working in GHCi of course. But you can still compile all your modules to object code and call main from GHCi, so I don't think this is a big restriction considering unsafeShow is only for debugging purposes. Another question is where in the package hierarchy would this function live. Since the code it would use is in the ghc package, it would introduce a dependency on it. And I am fairly sure that there is no package in the standard ghc distribution which depends on the ghc package. Ian, can it be made to live in ghc-prim without creating a dependency on the ghc package? Alternatively, with some effort one can create a type-agnostic version of unsafeShow, which would print things in a more raw format, but probably sufficient anyway. I don't think it would work with unboxed values in general, although it can be made to work with the standard types. Actually, Bernie Pope wrote some code for this [1, see GHC Heap Printing library] some time ago, although with the new primitives and changes made for :print in GHC 6.8, this would be way easier nowadays. No need to use StablePtrs, no need to turn on profiling, and above all, no C needed :) And as a bonus this would work out of GHCi too. If there is a clean way to access the Session object, the first option means less implementation work, less code to maintain in GHC, and better functionality. What does the GHC team think? [1] - http://www.cs.mu.oz.au/~bjpop/code.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] retrospective on 'seq' - 'unsafeSeq' ?
On 14/04/2008, at 9:22 PM, pepe wrote: Alternatively, with some effort one can create a type-agnostic version of unsafeShow, which would print things in a more raw format, but probably sufficient anyway. I don't think it would work with unboxed values in general, although it can be made to work with the standard types. Actually, Bernie Pope wrote some code for this [1, see GHC Heap Printing library] some time ago, although with the new primitives and changes made for :print in GHC 6.8, this would be way easier nowadays. No need to use StablePtrs, no need to turn on profiling, and above all, no C needed :) And as a bonus this would work out of GHCi too. Yes, an almost-universal printer would be possible now that we have data constructor names attached to info tables. I'd sort of planned to do that, and then got side-tracked. Of course, this won't be able to print functions in any helpful way, unless we attach source code information to functions as well (which may be worth doing anyway?). One thing to watch out for is cycles in data structures. You may not want to try to detect them, but at least you should be lazy in generating the printable representation of values. And then there is the question of whether to evaluate thunks during printing. Perhaps such a printer would also be useful for the GHCi debugger in cases where it can't infer the right types? Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
