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 typ
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 w
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
| > 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
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. (Analogo
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
