July 2001 - Glasgow-haskell-users

RE: help needed for adding isWHNF primop to 5.00.2
by Bernard James POPE 01 Aug '01

01 Aug '01

Hi all, Apologies for my large number of postings to this list of late. > the normal definition of WHNF applies only > to types containing _|_, i.e. pointed types. Unpointed types are never > represented by thunks, so I would be inclined to include them in WHNF. Yes, I agree here. It is useful for me since I am using WHNF to determine whether expressions are evaluated. Perhaps it is a slight abuse of the terminology, but it gives me what I want :) > You also have to deal with indirections, although you can assume (at the > moment) that an indirection will eventually lead to an object in WHNF. Good point. I did make this assumption. Well to be precise I made the assumption that the thunk and indirection closure flags were mututally exclusive. If things change I guess I will have to follow the indirections. currently my definition is: #define isHNFzh(r,a) r=(! closure_THUNK((StgClosure *)a)) I believe under this definition that unpointed types and indirections are considered to be in WHNF. My initial tests seem to indicate that this is working well. > You have to declare the primitive like this, > BTW: > > isWHNF# :: a -> (# State# RealWorld, Int# #) > > because the compiler doesn't know about the IO type and you can't return > a Bool directly. I'm not too fussed about the unboxed Int, although as Marcin points out it does look like some of the comparision primops can return a Bool. I couldn't figure out how they did it so I left it with the Int#. > There's no problem with the simplifier as long as you declare the > primitive to have the correct properties, i.e. that the polymorphic > argument is lazy. Great. > It sounds like you also need a way to take apart arbitrary objects and > look at their components. Yes indeed. I use type classes for this with deriving rules for user defined types. I'm in the midst of writing this up for IFL, in Stockholm, mid September. In particular, I am looking for "portable" ways of taking objects apart, that's why type classes are attractive. Of course, isWHNF cannot be written in Haskell, but if I can get it to work for Hugs, GHC and NHC, then that is good enough for me :) What I hope is that some of this can appear as a Meta-programming library for Haskell, which is more powerful than Read and Show. Something a bit similar to the semantic domain of Meta-ML. > I know that Andy Gill was also interested in > having similar facilities, perhaps he can help out. I wonder if Andy is reading this? Possibly there are other people around who are also interested in this. I think the HAT people at NHC headquarters are also interested in these things. There once was talk of starting a debugging group for Haskell, but I don't know what happened. Thanks heaps for your help. Bernie.

3 3

FFI and Control-C
by Koen Claessen 31 Jul '01

31 Jul '01

Hi, I recently started experimenting using the FFI in GHC and GHCi. In GHCi, one would like to press control-C in the middle of a computation, and get back to the prompt. It is however hard to understand how control-C and the foreign function calls interact. I noticed that GHCi does not react to control-C when the program in inside a foreign function. Instead, it then breaks when the foreign function comes back. This behavior would be fine in many applications if it were consistent. However, often after I have pressed control-C, the internal state of the foreign library is usually completely messed up. Even beyond what one can think is possible when allowing to abruptly break computations. So, my questions are: 1) Does anyone know what exactly happens when control-C is pressed during foreign function evaluation? 2) Does anyone know how this can be controlled in a more finegrained way? For example, in old Hugses, it was possible to use the function "breakOn", which allowed/disallowed control-C breaking. /Koen.

1 0

RE: help needed for adding isWHNF primop to 5.00.2
by Simon Marlow 31 Jul '01

31 Jul '01

> I wonder if Andy is reading this? Possibly there are other people > around who are also interested in this. I think the HAT people > at NHC headquarters are also interested in these things. There > once was talk of starting a debugging group for Haskell, but I > don't know what happened. There's a mailing list for debugger-related discussion at debuggers(a)haskell.org (subscribe in the usual way). To date it has received a single message, namely the nhc 1.06 announcement :-) Cheers, Simon

1 0

RE: help needed for adding isWHNF primop to 5.00.2
by Simon Marlow 31 Jul '01

31 Jul '01

> Tue, 31 Jul 2001 12:38:03 +0100, Simon Marlow > <simonmar(a)microsoft.com> pisze: > > > That's the way I'd go. You have to declare the primitive like this, > > BTW: > > > > isWHNF# :: a -> (# State# RealWorld, Int# #) > > > > because the compiler doesn't know about the IO type and you > can't return > > a Bool directly. > > It can return a Bool, e.g. ==# returns a Bool. But ==# doesn't also return an unboxed tuple, and the code generator has special hacks to deal with primops that return enumerated types. The ==# primop actually returns an Int# which the code generator arranges to convert into a real Bool using the closure table. I guess you could return a Bool by actually indexing into the closure table, or by just returning {False,True}_static_closure. Cheers, Simon

1 0

Re: help needed for adding isWHNF primop to 5.00.2
by Marcin 'Qrczak' Kowalczyk 31 Jul '01

31 Jul '01

Tue, 31 Jul 2001 12:38:03 +0100, Simon Marlow <simonmar(a)microsoft.com> pisze: > That's the way I'd go. You have to declare the primitive like this, > BTW: > > isWHNF# :: a -> (# State# RealWorld, Int# #) > > because the compiler doesn't know about the IO type and you can't return > a Bool directly. It can return a Bool, e.g. ==# returns a Bool. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: help needed for adding isWHNF primop to 5.00.2
by Simon Marlow 31 Jul '01

31 Jul '01

> From reading the documentation that comes with GHC and > glancing over the > source code, I came to these set of assumptions, please > correct me if I am > wrong: > > - values of unpointed types are never in WHNF That's really up to you, but the normal definition of WHNF applies only to types containing _|_, i.e. pointed types. Unpointed types are never represented by thunks, so I would be inclined to include them in WHNF. > - values of pointed types may be in WHNF, in particular: > > - data constructors are in WHNF > - partial applications are in WHNF > - functions are in WHNF > - thunks are not in WHNF > (this list is probably not exhaustive as you say, but > I am happy > with this set of definitions for the moment) You also have to deal with indirections, although you can assume (at the moment) that an indirection will eventually lead to an object in WHNF. > > I can also imagine it > > could interact badly with the complexities of GHC's > > simplifer. > > This is something I do not know. In the end I may define it > with this type: > > isWHNF :: a -> IO Bool That's the way I'd go. You have to declare the primitive like this, BTW: isWHNF# :: a -> (# State# RealWorld, Int# #) because the compiler doesn't know about the IO type and you can't return a Bool directly. There's no problem with the simplifier as long as you declare the primitive to have the correct properties, i.e. that the polymorphic argument is lazy. > I want it for the purposes of meta-programming, and also for > debugging since > that is what I am working on. At the end of a computation > (that results in > a value of pointed type, say) I want to know to what extent > expressions were > evaluated: > > foo xs = take 3 xs > > ... foo [4..] ... > > debugger> foo [4,5,6,_ = [4,5,6] It sounds like you also need a way to take apart arbitrary objects and look at their components. I know that Andy Gill was also interested in having similar facilities, perhaps he can help out. Cheers, Simon

1 0

RE: help needed for adding isWHNF primop to 5.00.2
by Julian Seward (Intl Vendor) 30 Jul '01

30 Jul '01

| > I would like to add a primitive to GHC 5.00.2 of the form: | > | > isWHNF :: a -> Bool One might be inclined to ask what for? Such a primitive is probably difficult to implement, given the variety of GHC's closures, and is potentially dangerous -- you could conceivably break referential transparency (?) I can also imagine it could interact badly with the complexities of GHC's simplifer. What would you hope to gain from such a thing? Perhaps you have some wider purpose which could be achieved some other way? J

2 1

RE: linking with c++ libraries
by Julian Seward (Intl Vendor) 30 Jul '01

30 Jul '01

| To reliably link with C++, you need to compile both the code | which invokes C++ (i.e. whatever uses the C++ library) and | "main" (that is, ghc/rts/Main.c, not main.hs) with a C++ compiler. | | So, in summary: | | - Compile any code which may call the C++ library (and keep | inter-module inlining in mind; probably safest to compile | all of your code this way) via C, and compile the C with g++. | | - Re-compile the run-time system (at least Main.c) with | g++, too. | | That may not fix your specific core dump, but you'll need to | do this anyway. After some discussion in the GHC office, we're unsure about why you need to compile Main.c with a C++ compiler for this to work. Pls can you clarify? J

2 1

outputs during runtime
by Nicole Gabler 30 Jul '01

30 Jul '01

Hello All, I wrote a small haskell program that amongst other things parses some files to manipulate them. During runtime I want the program to output information about the status every time another file is parsed. That doesn't work, the output appears much later, mostly not until end of program. But I need these outputs at that specific time, so what can I do to manage it? Thanks Nicole

3 2

RE: outputs during runtime
by Julian Seward (Intl Vendor) 30 Jul '01

30 Jul '01

Unfortunately that usually means that you need to let the IO type filter down from the top level to all fns which need to print something. Then you can emit a message perhaps in the same function which reads the files. Or is it perhaps a buffering problem? J -----Original Message----- From: Nicole Gabler [mailto:gabler@ics-ag.de] Sent: Monday, July 30, 2001 10:50 AM To: glasgow-haskell-users(a)haskell.org Subject: outputs during runtime Hello All, I wrote a small haskell program that amongst other things parses some files to manipulate them. During runtime I want the program to output information about the status every time another file is parsed. That doesn't work, the output appears much later, mostly not until end of program. But I need these outputs at that specific time, so what can I do to manage it? Thanks Nicole

1 0