Re: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ?

Pepe Iborra-3

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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ?

Bernie Pope
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.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ?

Ian Lynagh
In reply to this post by Pepe Iborra-3
On Mon, Apr 14, 2008 at 01:22:42PM +0200, pepe wrote:
>
> 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?

I'm not sure I understand the question. If it needs to use functions in
the ghc package then it needs to be in a package that depends on the ghc
package, but ghc depends on ghc-prim, so it can't be in there.


Thanks
Ian

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ?

Pepe Iborra-3

On 30/04/2008, at 0:19, Ian Lynagh wrote:

> On Mon, Apr 14, 2008 at 01:22:42PM +0200, pepe wrote:
>>
>> 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?
>
> I'm not sure I understand the question. If it needs to use functions  
> in
> the ghc package then it needs to be in a package that depends on the  
> ghc
> package, but ghc depends on ghc-prim, so it can't be in there.
>

Scrap that, I figured out a better way to do it. It's an old hack that  
lemmih used for the early breakpoint primitive.
The trick consists in replacing the unsafeShow function for an  
unlinked actualUnsafeShow identifier in the renamer.
Then, we dinamically link the real :print functionality to this  
identifier, when setting the context in GHCi. With the appropriate  
type declarations preloaded in the local environment GHC can be  
convinced to work finely in this way, of course only for interpreted  
code.

pepe
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users