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?
When reading the section 10.3 Controlling Evaluation Order in History
of Haskell I thought that the example that justified the 'seq' to be
unrestricted polymorphic was mainly a debugging problem. I wondered if the
better solution would have been to provide an 'unsafeSeq' which has no
type
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.
| 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
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
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
