Re: How to find out the C type signature corresponding to a Haskell function type in FFI?
Brian Hulley [EMAIL PROTECTED] writes: I've got a Haskell module with the following ffi import: foreign import ccall duma_init :: Int - IO Int However my problem is that I've got no idea what the type signature for the corresponding C function should be, HsInt duma_init(HsInt arg); Or use int on the C side and CInt on the Haskell side. fromIntegral can be used for converting integers in Haskell. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding
John Meacham [EMAIL PROTECTED] writes: Another possibility is quasi-utf8 encoding. where it passes through any invalid utf8 sequences as latin1 characters. in practice, this works very well as interpreting both latin1 and utf8 transparently but is more than somewhat hacky. It would not be reliable. I'm strongly against that: it gives an illusion that Latin1 works, but it breaks in very rare cases. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Are new sequences really O(1)?
Simon Marlow [EMAIL PROTECTED] writes: Nice trick. Unfortunately the same assumptions don't hold for GHC's garbage collector - objects are aged in the youngest generation, so it is usually at least two GCs before an object is promoted. We could still do the same trick, but instead we'd have to find maximum stack depth at which all objects below are in an older generation. I don't know how to do it under these assumptions, i.e. how to find that depth. Incedentally, how do you mark the stack depth? Overwrite a return address with a special one, and keep the real one around in a known place? This is the first thing I tried :-) and even implemented it before I realized that it doesn't work under my assumptions. The problem is that I pass the return address in a virtual register, and it's saved on the stack by the callee only if it performs some non-tail calls. The return address is saved at the end of the stack frame. This means that a tail call followed by a non-tail call might read the special return address from the stack, but without jumping through it immediately. This return address is put again on the stack by a different function, with a possibly different stack frame size, so it lands in a different position on the stack, and thus it can't be found when GC wants to restore it. While changing the stack frame layout could perhaps make this workable, I found a much simpler solution. Since forever each stack frame contained a pointer used only by the GC and by stack trace printing. It points to a static structure containing the frame size and return address - source location mapping. This pointer is now marked in the lowest bit by the GC. Pushing a fresh stack frame always puts an even pointer. BTW, a few days earlier I fixed a similar behavior for extensible arrays. Most mutable objects use a write barrier which stores changed locations, but arrays store references to changed objects because their payload is malloced and may be reallocated without a GC. This meant that code which repeatedly appends to a given array has O(N^2) complexity for huge arrays, as each GC scans the whole array. So I now store the size of the initial part of the array which is known to be unchanged since last GC. This is updated manually by particular operations. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Are new sequences really O(1)?
[moved from libraries to glasgow-haskell-users] Ross Paterson [EMAIL PROTECTED] writes: GCs that happen during this process will be more expensive, as they have to scan the stack. I suspect that GC costs are swamping everything else for large n. I just tweaked the implementation GC in my compiler of my language, so that minor collection doesn't scan the whole stack, but only the part up to the deepest point where the stack pointer has been since the previous collection. Deeper regions contain only old pointers so they don't need to be scanned (I have only two generations). A program which builds a list of length 270,000 non-tail-recursively, which in a strict language leads to proportional usage of the stack, and performs on average 4kB of temporary allocations for each element, so there are 9,000 GCs in total with the young heap of 128 kB, runs 10 times faster after the change. GC takes 5% of the time instead of 88%. The implementation relies on the fact that only the topmost stack frame can be mutated, so it's enough to look only one frame deeper than the stack pointer reached. Each frame contained a pointer which is used only for GC and for stack trace printing, and thus it can be marked in the lowest bit without impacting normal operations. I prefer to make non-tail recursion efficient than to have to rewrite algorithms to use a large heap instead of the stack. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Optimization and GCC?
Wed, 19 Dec 2001 09:56:36 +0100, Till Doerges [EMAIL PROTECTED] pisze: /u/joe/built/lib/ghc-5.00.2/includes/Regs.h:255: warning: call-clobbered register used for global register variable I don't know about this one. /tmp/ghc15733.hc:5391: warning: deprecated initialization of zero-length array /tmp/ghc15733.hc:5391: warning: (near initialization for `Main_main_closure.payload') This is already fixed in CVS. ghc3 is not officially supported yet. Nevertheless I'm using it at home and it can successfully compile almost everything from ghc on ix86. This is my mk/build.mk - I'm compiling three files with gcc-2.95.3: ProjectsToBuild = glafp-utils ghc hslibs happy PrimOps_HC_OPTS = -pgmcgcc-2.95.3 ArrayBase_HC_OPTS = -pgmcgcc-2.95.3 PosixTTY_HC_OPTS = -pgmcgcc-2.95.3 This was for gcc-3.0.1 and ghc a few weeks ago. I'll see if it's better now, with gcc-3.0.2. The problem with PrimOps looked like gcc bug, as if it ignored -fomit-frame-pointer for this file. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [qforeign] CursesTest segfaults
29 Nov 2001 18:12:08 +0900, Jens Petersen [EMAIL PROTECTED] pisze: I built qforeign from cvs under Linux. Any idea why tests/CursesTest segfaults? No idea - works for me now. ghc-5.03 ncurses-5.2 glibc-2.2.3 gmp-3.1.1 readline-4.2 -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Casting dynamic values
27 Nov 2001 17:31:10 -0700, Alastair David Reid [EMAIL PROTECTED] pisze:
If GHC is able to inline these functions, construction and
deconstruction of the pair can probably be eliminated.
cast is compiled to something similar to this:
coerce :: a - b -- this generates no runtime code
type Typeable a = a - TypeRep
cast :: Typeable a - Typeable b - a - Maybe b
cast t1 t2 x =
case t1 x of
rep1 - case t2 (coerce x) of
rep2 - case eqTypeRep rep1 rep2 of
True - Just (coerce x)
False - Nothing
Instances of Typeable should not look at their argument to determine
TypeRep of its type but unfortunately the compiler can't in general
assume that.
But I don't think GHC can do this because AFAIK, GHC will not reduce
literal string comparisions at compile time.
Since Oct 1 it tries to. Unfortunately string literals seem to be
floated out to toplevel before there are recognized as literals being
arguments of (==), and the rule doesn't work.
[This is assuming that GHC's implementation of Typeof still uses
strings. This may not be true though since there was talk of adding
direct compiler support to make the implementation of typeof more
efficient and, more importantly, less prone to programmer error.
It doesn't use strings for comparison but uniquely generated numbers.
But it's not safe either: uniqueness of these numbers relies on TyCon
objects being defined at the toplevel, with {-# NOINLINE #-}, and
I'm not sure if common subexpression elimination doesn't mess this up
(it corrupts similar cases).
Anyway equality on statically known TypeRep is not done at compile
time. I don't know why.
--
__( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc: Passing -1 as CString/Ptr a?
Thu, 22 Nov 2001 13:57:32 +0100, Volker Stolz [EMAIL PROTECTED] pisze:
Hi, I want to invoke the C-function 'dlsym', which has three
possible options for a parameter of type (void*):
- NULL
- void* to a string, i.e. CString in Haskell
- RTLD_NEXT = (void *)(-1)
You can obtain the value from an embedded C function.
foreign import unsafe rtldNext :: Ptr a
#def inline void *rtldNext (void) {return RTLD_NEXT;}
--
__( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Reading files via http or ftp
25 Oct 2001 21:01:27 +0100, Colin Paul Adams [EMAIL PROTECTED] pisze: Has anyone used the Socket library to read files specified via an http and/or ftp URL? Yes (http), although I implemented only a small subset of the http client protocol. http://qrczak.ids.net.pl/Haber-0.3.tar.gz -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: qforeign-0.65: Bzip2: decompress hangs if data ends prematurely
Thu, 25 Oct 2001 12:06:53 +0200 (CEST), Michael Marte [EMAIL PROTECTED] pisze: I found that decompress hangs if data ends prematurely, i.e. do content - readFile fp doSomething (Bzip2.decompress content) does not terminate in this case. Try this patch (sorry, untested): --- examples/Bzip2.hsc~ Mon Jun 11 23:19:50 2001 +++ examples/Bzip2.hsc Thu Oct 25 17:55:19 2001 @@ -169,6 +169,7 @@ let blockIn = take blockSize input ok - decompressBlock strm blockIn blockSize case ok of +RunOk 0 [] - ioError (userError bzip2: premature end of +compressed data) RunOk inSize blockOut - liftM (blockOut++) $ unsafeInterleaveIO $ decompressLoop strm (drop inSize input) StreamEnd output - return output It's in CVS at SourceForge now. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 5.02 MonadError Broke My Code
Sun, 21 Oct 2001 19:38:55 -0700, Ashley Yakeley [EMAIL PROTECTED] pisze: MonadError seems to have been redefined in 5.02 to have a fundep: 5.00.2: class (Monad m) = MonadError e m 5.02: class (Monad m) = MonadError e m | m - e Why? It allows some practical functions which would be awkward to write without the fundep. For example: data ParseError = ... class HasParseError e where inject :: ParseError - e parseInteger :: (MonadError m e, HasParseError e) = m Integer -- This type is ambiguous without the fundep because the main part of -- the type doesn't mention e. You could argue that we should write this instead: parseString :: MonadError m ParseError = String - m () but this style isn't always feasible. It would force to have a concrete error type in all places where the error type is not directly visible in the type of the whole function. I don't want to commit to a particular error type in generic parsing library for example - the library only specifies properties of the error type using classes and gives several choices for it; details of the error type are specific to places where the library is used. Also a constraint like 'MonadError m ParseError' which mentions a concrete type can't be put in an instance context without -fallow-undecidable-instances. I have an example where putting this in an instance context is useful: there is a large set of constraints (six) which is used in many functions, so they are packed in a subclass with no methods which serves as a class synonym. Anyway, because of GHC's naive instance overlapping checking, it broke my code: instance (JVMMonad m) = MonadError ThrowableRef m where Sorry about that. A single MonadError class can't simultaneously allow both ways of associating error types with monads. I guess you can move 'MonadError ThrowableRef m' to superclasses of JVMMonad and make MonadError instances for all types in this class separately. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Multi-parameter OOP
Fri, 19 Oct 2001 17:02:54 +0200, George Russell [EMAIL PROTECTED] pisze: So is there any other way of doing this sort of dynamic lookup at runtime, in a reasonably neat way? There is module Dynamic. I don't know if it helps or is reasonably neat. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: catchAllIO
12 Oct 2001 12:15:16 Z, Steinitz, Dominic J [EMAIL PROTECTED] pisze: Can anyone help? catchAllIO seems to live in Exception but I can't find it in the documentation 4.12. Exception. It's deprecated, replaced by Exception.catch. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scope in ghci
Fri, 05 Oct 2001 15:14:15 +0400, S.D.Mechveliani [EMAIL PROTECTED] pisze: Dm1 sort $ dm1 [1%2,1%3]-- contrived example is impossible. Instead, it needs Dm1 List.sort Prelude.$ dm1 [1 Ratio.% 2, 1 Ratio.% 3] This happens when the module Dm1 is compiled. It's because a compiled module doesn't provide the information which names were in scope in its source. Perhaps ghc should use the .o/.hi files for execution and parse its .hs for getting this information if it's set as the current module. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UniCode
Fri, 5 Oct 2001 23:23:50 +1000, Andrew J Bromage [EMAIL PROTECTED] pisze: There is a set of one million (more correctly, 1M) Unicode characters which are only accessible using surrogate pairs (i.e. two UTF-16 codes). There are currently none of these codes assigned, This information is out of date. AFAIR about 4 of them is assigned. Most for Chinese (current, not historic). So rare, in fact, that the cost of strings taking up twice the space that the currently do simply isn't worth the cost. In Haskell strings already have high overhead. In GHC a Char# value (inside Char object) always takes the same size as the pointer (32 or 64 bits), no matter how much of it is used. It just goes to show that strings are not merely arrays of characters like some languages would have you believe. In Haskell String = [Char]. It's true that Char values don't necessarily correspond to glyphs, but Strings are composed of Chars. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UniCode
05 Oct 2001 14:35:17 +0200, Ketil Malde [EMAIL PROTECTED] pisze: Does Haskell's support of Unicode mean UTF-32, or full UCS-4? It's not decided officially. GHC uses UTF-32. It's expected that UCS-4 will vanish and ISO-10646 will be reduced to the same range U+..10 as Unicode. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: enormous executable
Mon, 1 Oct 2001 09:55:11 +0100, Simon Marlow [EMAIL PROTECTED] pisze: We don't have support for shared libraries under Unix at the moment. It has been investigated at various times in the past, and I believe the story is that we couldn't do it without at least losing some performance (more performance loss than you get from compiling C into a shared library). There is also a big problem of binary incompatibility between different versions of ghc, and dependence on the exact version of modules our package depends on. Dynamic libraries work for C because C has a very stable ABI. Also it's easy to maintain binary compatibility in libraries. I'm afraid that cross-module optimizations of ghc make dynamic libraries nearly impractical. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Ptr and ForeignPtr Questions
Sun, 23 Sep 2001 02:04:49 -0700, Ashley Yakeley [EMAIL PROTECTED] pisze: I would assume that Ptr types would always be mapped to non-const pointers. It would be impossible then to directly call a C function with a parameter declared as a const pointer. It's illegal in C to have mismatching prototypes of the same function. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Ptr and ForeignPtr Questions
Sun, 23 Sep 2001 15:41:41 -0700, Ashley Yakeley [EMAIL PROTECTED] pisze: But do you have an example of a Haskell type for a foreign import function, for which the corresponding C function type would be ambiguous? Ptr CChar (as an argument). It could be either char * or const char *. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Converting [Word8] to CString
Fri, 14 Sep 2001 23:40:42 -0700, Ashley Yakeley [EMAIL PROTECTED] pisze: I'm looking for a function that will convert a [Word8] byte-array to a CString (i.e. a C byte array) for the purposes of FFI. You can use newArray which allocates the C byte array using malloc so it must be freed by free, and cast the resulting pointer from Ptr Word8 to CString using castPtr. When the array is temporary, it's better (and faster) to use withArray list_of_Word8 $ \word8Ptr - let cstring = castPtr word8Ptr in ... And it has to be the _same_ list of bytes that comes through on the native side. I don't unserstand this. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: A question about Unicode support
Tue, 11 Sep 2001 13:19:54 -0300 (GMT), Pablo Pedemonte [EMAIL PROTECTED] pisze: Ghc 5.00.2 provides (initial) Unicode support, so I thought the chr function would do. But it seems it still rejects Int values greater than 0xFF. It doesn't. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC FFI Return Type Bug
10 Sep 2001 13:20:33 -0600, Alastair David Reid [EMAIL PROTECTED] pisze: So GHC's Int/Word implementation is different from Hugs'? Hugs represents Word8 (say) by a 32 bit int but doesn't guarantee that the top 24 bits are all zero. GHC does similarly, except that it does guarantee that unused bits are zero. Or one - in negative numbers. In other words it represents value x of type Int8 as if converted to Int. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--RTS
Currently --RTS option for a program compiled with ghc means that all the following arguments are passed to the program, even if they are +RTS and -RTS. IMHO -- should act like --RTS too. Imagine a utility like Unix ls written in Haskell. If someone invokes it ls -- $FILENAME he means that $FILENAME is a filename. He shouldn't care that it's written in Haskell and be forced to write ls --RTS -- $FILENAME as currently. If it's not an option for the program, it's certainly not an option for its runtime. --RTS can be retained in case one really wants to invoke the program with arguments +RTS (and not -- +RTS). PS. +RTS -h has an out of date description of -M. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: POLL: GC options
Mon, 06 Aug 2001 15:40:50 -0700, Thomas Hallgren [EMAIL PROTECTED] pisze: Regarding the maximum heap size, to avoid letting the heap grow too large, you could perhaps take into account the number of page faults that occur during garbage collection, or the ratio between CPU time and real time... A disadvantage of taking many factors into account is that the same program will non-deterministically run or fail. IMHO a default maximum heap size should be well-defined: either based on an environment variable or without limits or a fixed value. It would be bad for example to *automatically* set it depending on the free physical memory, because it would lead to the following: - your program doesn't compile - sorry, works for me - compilation dies with out of memory - you must have low physical memory; please set a flag: it will swap a lot but will finally compile - thanks, I don't know why but now it compiled without setting any flags. It would not be a problem if the limit was reached very rarely. Unfortunately it's not the case. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: help needed for adding isWHNF primop to 5.00.2
Tue, 31 Jul 2001 12:38:03 +0100, Simon Marlow [EMAIL PROTECTED] 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 * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: wait(2)
Thu, 26 Jul 2001 16:44:57 +0200, George Russell [EMAIL PROTECTED] pisze: Is there a way in Glasgow Haskell to get a thread to wait on a child process in the same way as the Posix function wait(), and get the termination status of the child? There is no easy way: all Haskell's thread run in the same process and wait() blocks the whole process. The only (or the only portable) way is to call wait() with WNOHANG repeatedly in a thread and threadDelay for a short period of time between calls. This is what OCaml runtime does. It provides waiting for a process as a threading primitive. It accounts for waiting in its select() loop in the scheduler. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC5] Creating Socket.PortNumber from Int?
Wed, 6 Jun 2001 10:17:34 +0100, Simon Marlow [EMAIL PROTECTED] pisze: Think of it this way: mkPortNumber has been renamed to fromIntegral, and now supports making port numbers from any integral type, not just Int. BTW, why PortNumber is not just Int? -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems finding modules with GHC 5
Mon, 04 Jun 2001 18:59:57 -0400, Leon Smith [EMAIL PROTECTED] pisze: Loading package std ... linking ... done. ghc-5.00.1: can't find module `MArray' ghci Main.hs -package lang -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Poll: System.exitWith behaviour
Wed, 23 May 2001 16:50:42 +1000, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze: I think, having the third point is good, because the Haskell report requires that Computation exitWith code terminates the program, returning code to the program's caller. Well, it says also that Actions, however, must be ordered in a well-defined manner for program execution -- and I/O in particular -- to be meaningful. Haskell 's I/O monad provides the user with a way to specify the sequential chaining of actions, and an implementation is obliged to preserve this order. which is not true in a threaded program. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Poll: System.exitWith behaviour
Here is what I just read on comp.lang.python: | the docs I have say that a thread can stop ITSELF, by raising | SystemExit, or calling sys.exit(). -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Poll: System.exitWith behaviour
Tue, 22 May 2001 15:43:45 +0100, Simon Marlow [EMAIL PROTECTED] pisze: - If this exception propogates to the top of the thread, then the main thread is also sent (ExitException code). This only happens for a standalone executable (ie. one which was started by PrelMain.mainIO). This looks like a strange exception for me (i.e. the fact that it propagates to the main thread). And it's weird to have it as an asynchronous exception in the main thread. I would drop this rule and let 'exitWith ExitSuccess' be the way to commit suicide by a thread, as if it completed, which degenerates to the Haskell 98 interpretation in a single-threaded program. BTW, I don't quite like the fact that 'exitFailure' looks simpler than 'exitWith ExitSuccess'. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Poll: System.exitWith behaviour
Tue, 22 May 2001 17:30:39 +0100, Simon Marlow [EMAIL PROTECTED] pisze: Well, we could do a proper job of extensible data types, which probably isn't hard but is certainly a fair amount of work. This would be IMHO the only right way, but I doubt that it's that simple. For example it would be irritating that you can't extend function definitions accepting values of extensible data types as arguments; even (==) is problematic. It's a pity that there is no direct translation of the OO style open polymorphism. You can use an algebraic type, but it casts all variants in stone; you can store extracted concrete-typed interface in function closures, but it doesn't allow to cast down (retrieve the original, more specific type); you can use existential quantification, with the same limitations; you can use Dynamic, which is not nice to define instances of, puts everything in one big bag, and doesn't provide any hierarchy or extraction by partial matches. I was recently thinking on a similar thing; it would not help with exceptions though, only with MonadError-based exceptions and extensible abstract syntax trees. The idea is to dualize my record proposal by introducing overloaded constructors. It provides views for free, i.e. allows having pattern matching on abstract types with programmer-defined semantics. Details aren't finished yet, but I imagine something like this: data HsExp e n l p = variant -- I like layout :-) -- The proposal doesn't eliminate the need to have type parameters -- here and close the recursion on types later :-( Var n Con n Literal l App e e etc. This introduces overloaded constructors: HsVar :: (e Var n) = n - e Con :: (e Con n) = n - e Literal :: (e Literal l) = l - e App :: (e App e1 e2) = e1 - e2 - e and instances: instance HsExp e n l p Var n instance HsExp e n l p Con n instance HsExp e n l p Literal l instance HsExp e n l p App e e A class of the form 't C t1 t2' allows to create values of type t by applying the constructor C to values of types t1 and t2, and pattern match on values of type t using the constructor C with arguments of types t1 and t2. In another module you can reuse the same constructor names (they don't collide as long as the arity is the same). You can also inherit constructors from other types, similarly as in my records: data GhcExp e n l p = variant Haskell98Exp :: HsExp e n l p Haskell98Exp (Var, Con, Literal, App, etc.) -- This creates forwarding instances of the appropriate -- classes, so Var etc. can be used with GhcExp too. -- Using the constructor Haskell98Exp expresses explicit -- subtyping/supertyping coercions. UnboxedTuple [e] CCall String [e] And you can define such instances yourself: instance PackedString Nil where -- Construction: (Nil) = nilPs -- Needs a better syntax. This *defines* Nil. -- Pattern matching: s | nullPs - Nil -- Matching failure here (because of a failed guard) -- means that the given value is not considered Nil. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonadError and fundeps
On Fri, 11 May 2001, Lauri Alanko wrote: Why? This makes composing and subtyping impossible: instance (MonadTrans t, MonadState s m, Monad (t m)) = MonadState s (t m) where get = lift get put = lift . put This instance is illegal anyway. One of types in the instance head must be a type constructor applied to something (type variables in Haskell 98, anything with -fglasgow-exts). Even if it was legal, it would overlap with instance Monad m = MonadState s (StateT s m) Also MonadReader and MonadWriter can't have such generic instances anyway because their methods have values of type 'm a' as arguments. OTOH without the fundep there are ambiguities. For example: class ParsingState s where stateInput :: s - String stateSkip :: Int - s - s instance ParsingState String where ... instance ParsingState s = ParsingState (s, Pos) where ... input :: (ParsingState s, MonadState s m) = m String -- Ambiguous without the fundep. input = gets stateInput -- Marcin 'Qrczak' Kowalczyk ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonadError and fundeps
On Fri, 11 May 2001, Lauri Alanko wrote: Yep, but in hugs +o the latter overrides the first one. Which is quite convenient. I doubt that it works predictably in all cases (when state types are not known statically). I can try to construct an example if you wish. translift :: (MonadTrans t, Monad m, Monad (t m)) = (m a - m b) - t m a - t m b translift f m = m = lift . f . return instance (MonadTrans t, MonadReader r m, Monad (t m)) = MonadReader r (t m) where ask = lift ask local = translift . local instance (MonadTrans t, MonadWriter w m, Monad (t m), Monoid w) = MonadWriter w (t m) where tell = lift . tell listen = translift listen pass = translift pass This gives wrong results (but I haven't checked). For example listen :: Monoid w = ReaderT r (Writer w) a - ReaderT r (Writer w) (a, w) doesn't listen what the action tells, but listens to 'return' which always tells mempty. Similarly 'local' first runs the action in the original environment and then provides a new environment to 'return' which doesn't look at it. I did most monad transformer forwarding instances in ghc-5.00 and hope that I got them right, but I haven't tested them much. It's not that mechanical (except MonadState), and some combinations can't be done at all. It could be advantageous to put something like translift in an extension of MonadTrans. AFAIR many liftings of this type are similar (but the function must be provided separately for each state transformer), so it would simplify making forwarding instances. Is it inconceivable that m might actually have multiple ParsingStates, and thus you really have to specify which one you want to use to get the input? The idea is to use a single state and abstract over the way in which interesting components are contained in it. It has these advantages: * It works. I doubt that automatic recognition of the state type would work. * It allows to have multiple components of the same type in the state. Now I see that my simulation of a fundep without the fundep (an extra class which generates the dependency, instantiated separately for each monad transformer, with MonadError as a superclass) doesn't work that well: throwError would still be ambiguous so it needs a wrapper with a type which tells how to determine the error type using the new class. So I'm now convinced that MonadError should have the fundep too. Some other mechanism could be invented to make it easier to embed various components in the same type (for MonadReader MonadState) or various alternatives (for MonadError). I have a rather heavy proposal for the first case (a language extension which redesigns records). OCaml has a dual mechanism for the second (polymorphic variants). If my records succeed, I will try to cover variants too. -- Marcin 'Qrczak' Kowalczyk ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
MonadError and fundeps
MonadReader, MonadWriter and MonadState classes have fundeps from the monad type to the environment / output / state type (I added them a few months ago). MonadError doesn't. I thought that it's desirable to make a class with more than one exception type, such that for example each catchError would catch the corresponding throwError only, or even with simulation of some subtyping policy. Now I'm not sure that it was the right choice. I have an example when having this fundep would be very helpful: I am experimenting with building monadic parsing combinators from monad transformers. In particular I already have a Parsec-like parsing monad composed from pieces. It would be bad to hardwire the error type. But without a fundep in MonadError overloaded functions can't be written with MonadError in the context and without mentioning the error type in their type (which would be impractical). My workaround is to have a separate class, similar to MonadError but with a fundep, with MonadError in its superclass, and with its own instances. Fortunately this class can be empty, taking implementation of pushing the error handling through monad transformers from MonadError. But it would be more straightforward to use MonadError directly. I make use of the fundep in MonadState too. So I think that usually one wants these fundeps. Other argument for having a fundep in MonadError: monad transformers provided by modules in package lang don't provide a monad which could handle multiple errors anyway, and it would be impossible to do it generically without overlapping instances. An instance would have to recognize its error type, so it must work on a hardwired type constructor. If there was a fundep, the behavior of different error types can be simulated by providing functions defined in terms of throwError and catchError which throw a specific type or catch only a specific type (this works only in the case where handling of all errors is done at the same level of monad transformers, but I doubt that anyone would make a monad without this property and still wanted to use generic throwing and catching functions). This can be even done generically in terms of classes which coerce a specific error type up or recognize it, without touching all monads, as I am doing in the workaround in the opposite direction. What do you think? If nobody answers, I think I will add the fundep... BTW, another question: should MonadPlus instead of just Monad be a superclass of MonadError? It has a natural definition in terms of catchError. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and the Lazy Functional State Threads Paper
Thu, 03 May 2001 00:02:01 +0200, Thomas Pasch [EMAIL PROTECTED] pisze:
If the immutable array type used was particularly UArray, it would
be more efficient to use the corresponding STUArray instead of
freezeArr3::
(Ix i, MArray.MArray (MArray.STUArray s) e (ST s), IArray.IArray a e)
= (MArray.STUArray s i e) - ST s (a i e)
freezeArr3 = MArray.freeze
Is this the way to do it?
Well, yes, although when the immutable array happens to *not* be
UArray (but e.g. Array), it can be less efficient than with STArray,
because elements must be reboxed. And it's less general (the element
type must be unboxable).
This is why I would use STUArray when it is known that the immutable
array is UArray and nothing else, and STArray in other cases.
I wonder a bit if this triggers the optimization if 'a' is of
type STUArray.
UArray. It does when it's statically determined that 'a' is of type
UArray. It doesn't when a function using freeze is so large that
it's not compiled inline and it's not specialized, so the compiler
uses a single generic version in a code compiled out of line. This
optimization is implented as rewrite rule:
freeze:: (Ix i, MArray a e m, IArray b e) = a i e - m (b i e)
-- Generically implemented in terms of overloaded element access
-- and array construction.
freezeSTUArray:: Ix i = STUArray s i e - ST s (UArray i e)
-- Uses memcpy.
{-# RULES
freeze/STUArray freeze = freezeSTUArray
-- The compiler can replace freeze with freezeSTUArray where types
-- match (if optimization is turned on).
#-}
There is no automatic way of choosing the best mutable array type
corresponding to the given immutable type. Formally there is no
correspondence here (except that there are some rules for freezing
and thawing for specific combinations of types).
Efficiency of bulk array operations improved since released ghc-5.00:
I eliminated many unnecessary bounds checking, at the cost of turning
IArray and MArray methods into functions (so custom instances of
these classes no longer work - they must define different methods).
(By the way I still have problems to see where unboxed values are
a good thing and were you should better avoid them.)
If there could be a universal answer, probably the compiler could do
this automatically all the times :-)
Operations like arithmetic on boxed values are implemented as unboxing,
performing the operation and reboxing. So unboxed values are generally
faster than unboxed values - except that when we perform no operations
at all and just copy values from one place to another (like in freezing
a mutable array), it's cheaper to pass boxed values unmodified than
to unbox or box them.
The compiler is able to optimize away boxing in many cases, e.g.
usually in passing values as arguments to strict functions and
returning results. But it is not able to automatically optimize it
when values are stored in data structures (unless the data structure
itself is optimized away! this sometimes happend to lists), and it's
not able to unbox values of unknown types (so it helps to inline or
specialize critical functions - this sometimes happens automatically).
In any case you can watch what is happening instead of guessing.
There are options which tell ghc to dump intermediate forms of the
program, in not so pretty format (because it's internal: the textual
presentation is defined only for the purpose of dumping). I learned
what ghc is doing from watching the dumps much more than from reading
its source. Some interesting dumps:
ghc -c -no-recomp -O File.hs -ddump-stg
-ddump-realC
-fasm -ddump-asm
In addition I wonder why there are so many array types. Are both
STArray and IOArray really necessary and what's the difference
between them?
Operations on STArray can be safely wrapped in a pure computation
using runST.
Operations on IOArray can be easily mixed with other IO operations.
Embedding them in a pure computation is still possible using
unsafePerformIO, but it's unsafe and slightly less efficient.
You can convert between ST and IO computations using stToIO and
unsafeIOtoST.
What about DiffArray?
It has immutable interface but computes '//' without copying the
whole array as long as it's used in a single-threaded way. OTOH it has
larger constant overheads than Array (because of more magic inside,
more indirections).
I'm still surprised by operations like 'unsafeFreezeArray' and
'freezeArray'. Shouldn't the garbage collector juge if there are
still other references to a distinct object?
I don't know how easy it would be, and I guess that in case the
programmer knows that unsafeFreeze can be safely used it's faster than
asking the garbage collection. Unsafe freezing is used everywhere
in implementation of immutable arrays, so it's worth eliminating
unnecessary overheads.
--
__( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA
Re: GHC and the Lazy Functional State Threads Paper
Sat, 28 Apr 2001 00:13:48 +0200, Thomas Pasch [EMAIL PROTECTED] pisze: newArr = newSTArray readArr = readSTArray writeArr = writeSTArray -- Error: Ambiguous type variable(s) `ix' in the constraint `Ix ix' freezeArr = freezeSTArray Monomorphism restriction strikes again. Constrained type variables of variable bindings without type signatures get a single type. Solution: add explicit type signatures: newArr:: Ix i = (i,i) - e - ST s (STArray s i e) newArr = newSTArray readArr:: Ix i = STArray s i e - i - ST s e readArr = readSTArray writeArr:: Ix i = STArray s i e - i - e - ST s () writeArr = writeSTArray freezeArr:: Ix i = STArray s i e - ST s (Array i e) freezeArr = freezeSTArray or (with ghc = 5.00) compile with -fno-monomorphism-restriction. Welcome to the club of people who think that the monomorphism restriction should be removed. putString [] = returnST () -- Error: Couldn't match `ST s a' against `IO ()' putString (c:cs) = putChar c `thenST_` putString cs The 'Lazy Functional State Threads' paper was written a long time ago, where monads were not a standard part of Haskell. I think that its IO was a special case of ST, which is not true anymore. There are stToIO and unsafeIOToST functions in module ST, but you should not really perform IO from the ST monad. -- Error: Couldn't match `ST s a' against `[b]' putString2 cs = seqST (map putChar cs) Use seqST2, which is now available under the name sequence_ (works for arbitrary monad; at the time where the paper was written it was not even possible to define the Monad class, because it has a higher order kind). Why is there a different definition of seqST in GlaExts? Because it's newer than the paper - actually this module is already obsolete:-) For the ST monad you can use standard overloaded monadic functions and operators: =, , return, sequence, sequence_, mapM, mapM_ etc. When I change the definition of the mutable Array to newArr = MArray.newArray readArr = MArray.readArray writeArr = MArray.writeArray freezeArr = MArray.freeze I get Error in accumArray and accumArray2. I guess this is because of the fact that a STArray is only one possible MArray and there are other possiblities, right? Right: nothing determines which mutable array type to use, and its type doesn't appear in the result, so it's ambiguous. But it's not the whole story. This is a really weird case. The MArray class is defined over the array type, the monad, and the element type. The element type is there because some arrays (namely STUArray and IOUArray among these privided by ghc) are not fully polymorphic wrt. the element type, but have different implementations for different element types (and store element values unboxed instead of under generic object pointers). The ST and STArray types are parametrized by a dummy type variable, and the runST function has a special type with forall in the argument. This ensures that the result of a computation run by runST doesn't depend on values which are mutable in this computation, i.e. that mutable values don't escape their state thread, so separate state threads are truly independent. The result of accumArray is an immutable array. So it should be legal to return it from a computation run by runST... Unfortunately it does depend on the dummy type variable! It's because it requires that the mutable array used to build the result accepts the given element type. The MArray constraint applies to the element type and to the monad. The monad type contains the dummy type variable. So although in practice all MArray instances with ST s as the monad work for all choices of s, the type of a general MArray constraint looks as if it could place constraints on s, and such type is rejected by runST. Fortunately you must resolve the mutable array type anyway. You can choose STArray, which is fully polymorphic wrt. the element type This causes the resulting type not depend on the dummy type variable: an unusual case where the type inferred as the most general type is not really most general! So you can fix it for example by using a specialized version of freezeArr inside accumArray, of type (Ix i, IArray a e) = STArray s i e - ST s (a i e) This will give quite general type of accumArray: arbitrary immutable array from the IArray class. If the immutable array type used was particularly UArray, it would be more efficient to use the corresponding STUArray instead of STArray, so freezing could just copy a memory block (there are magic specializations in ghc's libraries for such case). But if the element type was to remain generic, the type would have to be constrained over STUArray: the compiler doesn't know that UArray and STUArray are in practice defined for the same element types. The STUArray type includes the dummy type variable, so it doesn't work in runST, as explained above. Sorry. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^
RE: :! ghc -c vs :c
On Thu, 26 Apr 2001, Simon Marlow wrote: Yes, this is another thing we'd like to do, but haven't got around to yet. (you can always define your own :compile command using :def of course, but the benefit of a built-in one would be that it could take advantage of the in-memroy interfaces rather than reading them from the disk). IMHO to make compilation in ghci convenient the set of visible names from compiled modules should not differ that much from names visible from interpreted modules. It's not nice that even Prelude names are not in scope when the main module is compiled. Especially if :c without parameters compiled the main module by default. I understand that there are technical difficulties of inavailability of the source context inside compiled modules. One can emulate a better behavior by writing a module consisting of appropriate imports, so why ghci can't do that for me? Let's try to see how it could look like. Unqualified names in scope are drawn from three sources: 1. Names exported by a set of modules chosen by the user. Modules can be individually added to and removed from this set. Probably the full power of imports should be supported: :import Module :import Module (foo, bar) :import Module hiding (bar, baz) :import Module as M -- Perhaps not needed because qualified names -- are managed in a different way. Mentioning the same module twice combines the two effects, as for imports in the source. Prelude is implicitly in this set except if it is included explicitly, as for imports in the source. There is also :unimport Module and a way to display the active imports. 2. All top level definitions and things imported by a chosen source module (i.e. names available inside it), if one is chosen; it must be possible to forget it. When the user chooses a module for which both the source and *.o is available, the module is interpreted. It's impossible to choose a module without the source. Although it would make sense to allow more than one module available this way, it should probably be simplified to be at most one, i.e. choosing some forgets the previous one. Using unqualified ambiguous names coming from combined 1. and 2. is an error. Note that the module in 2. needs not to be present in the set of 1. Particularly when the chosen module reexports some variables qualified and doesn't have them available unqualified, they are not available. 3. Variables bound interactively. I'm not sure when they should be forgotten. If choosing another module in 2. must forget them due to some technical reasons, then ok, but I would prefer to forget them explicitly (not necessarily individually). These definitions cover other things with the same names, as if we were inside a 'do' block. -- Marcin 'Qrczak' Kowalczyk ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [ghci] Comparison with Hugs
Tue, 24 Apr 2001 16:19:21 +0200, Volker Stolz [EMAIL PROTECTED] pisze: ghci however will complain that main is missing and even won't keep the defined functions in scope. Is there anything I can do about that? Add 'module Foo where' at the top of the file (preferably with the module name matching the filename). -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: An attempt at foldr/build fusion for zip
Sun, 22 Apr 2001 08:45:45 -0500, Matt Harden [EMAIL PROTECTED] pisze: I think I may have found a way to get zip friends to fuse with *both* of their input lists. I tried to put in PrelList, changed foldr2_both to use a local recursive function which doesn't pass k around which allows to inline k, and a test shows that it's unfortunately slightly slower than the original. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to implement timeouts for IO operations?
Mon, 23 Apr 2001 15:36:09 +0100, Simon Marlow [EMAIL PROTECTED] pisze: The correct way to implement timeout in GHC 5.00 is below. This should really be in a library somewhere. IMHO unique exceptions should be factored out and available in a standalone way. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to implement timeouts for IO operations?
Wed, 18 Apr 2001 14:52:12 +0200 (MET DST), Johannes Waldmann
[EMAIL PROTECTED] pisze:
it seems to work, but how do I turn off the "Fail: thread killed" messages?
import Exception
t - block $ forkIO $ catchJust asyncExceptions
(unblock timer)
(\_ - return ())
Perhaps the message about killing a thread will not appear in future
versions of ghc. A discussion about it on this list stopped six
weeks ago.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to convert the type signature of a variable to a String?
Sun, 15 Apr 2001 14:20:01 +1000, Andrew J Bromage [EMAIL PROTECTED] pisze:
We know that the most general type of `id' is "a-a".
We assume there's a theoretical function:
get_the_function_type_of :: a - String
where a can be a function type. Now consider:
f :: (String - String) - String
f g = g (get_the_function_type_of g)
The question is: Should `f id' return "a-a" or "String-String"?
Inside f the variable g has type String-String. It doesn't matter
that the expression used to build this argument could be used on
another type too: the level of concreteness of the type is not a
part of the object having that type, but a property of the variable
through which we access it.
It would return "String-String" (assuming that
get_the_function_type_of was in some sense possible). Any other
overloaded function would be also used as for String-String instead of
reporting an ambiguity error, where using it for 'id' directly could
report an ambiguity error if the instance is not defined uniformly
for all types of function arguments and results but depends on a
particular choice of them.
In other words all instances of an overloaded function must agree on
the level to which they examine the type. If one of them doesn't look
at a fragment of the type (e.g. function argument), others can't too;
if one of them depends on them, the type must be determined in order
to make a usage unambiguous.
ghc has -fallow-overlapping-instances which relaxes this requirement.
It allows fallbacks: when a type doesn't fit to any instance, try
to use a more general one. It still doesn't make calls which don't
determine that type unambiguous, and doesn't allow to recognize the
fact that a variable is polymorphic. It has some strange properties,
e.g. importing a module (which defines some instances) can change a
valid program into another valid program with a different meaning.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to convert the type signature of a variable to a String?
Mon, 9 Apr 2001 11:52:47 +0200, Pasch, Thomas (ACTGRO)
[EMAIL PROTECTED] pisze:
So the question is: Is is possible to write a function the gives
back a String with the signature of the argument of that function?
For example:
'function f' gives the String "a-a"
No. Classes are not powerful enough to "recognize polymorphism".
In this form it's not even theoretically consistent: any function
can be treated as a function of a more specific type, so the result
would be ambiguous (for example f has type Int-Int too, so asking
for a type should give "Int-Int" too).
The fact that a function can be treated as of more specific types than
originally defined is not a problem when the function is used, because
interpretations according to possible types agree. But when you want
to make a string out of it, they can't agree if they are not trivial:
a value can't behave as both strings "a-a" and "Int-Int".
In Haskell there are almost no cases where an ambiguity is resolved
implicitly, i.e. when one of several correct interpretations is chosen.
There are not many ambiguities at all, and they result in compile
errors if they arise.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
IArray and MArray
Is it important to keep the current definition of IArray and MArray classes? I would like to change class operations, without changing the interface, i.e. turn methods into ordinary overloaded functions and have different methods. It would affect users making their own instances of these classes, but not users of these instances. The problem is that translation of the index to an Int is coupled with actual array operations. It's not possible to omit the translation with the range check in an overloaded way; such operations must be coded separately for each element type, which is quite painful. It's not possible to add a method which specifies indexing by Int, because there is no reasonable default definition, except using (!!) on the index range: the class Ix doesn't define translation from Int to indices. Many bulk operations don't need indices but just iterate over the array: elems, listArray, amap, thaw, freeze, (==), compare (actually compare is a more complex issue). The performance is horrible if tight loops do the translation. But if the needed functionality is not in the array, the operation must be coded for each type separately instead of letting the compiler do the specialization, and some of these must be matched with rules. Class operations define too much. Translation of indices to Ints with bounds checking is done in the same way for all arrays. These operations must be polymorphic wrt. index, so they don't have a choice. But they have to hardwire the translation into individual methods. I would let operations in IArray and MArray work on Ints and change current methods to functions overloaded over the array and the index. -- Marcin 'Qrczak' Kowalczyk ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacing module Array by IArray
Wed, 28 Mar 2001 21:11:59 +0200, [EMAIL PROTECTED]
[EMAIL PROTECTED] pisze:
The module Array exports module Ix (Haskell 98 Library Report).
The module IArray doesn't export Ix (jet?).
Thanks, it will export it in ghc-5.00.
I think a pack and unpack function to convert between IArray ix be
and UArray ix ube via 'amap pack/unpack' would be useful.
Such conversion is as simple as
\a - listArray (bounds a) (elems a)
or
\a - array (bounds a) (assocs a)
so I don't think it needs a separate function.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: function over Array and UArray possible?
Thu, 29 Mar 2001 19:48:25 +0200, [EMAIL PROTECTED]
[EMAIL PROTECTED] pisze:
Is it possible to give a context, so that a function can have
a signature which combines
foo:: (Ix i) = Array i a - Array i aand
foo:: (Ix i) = UArray i a - Uarray i a ?
Yes:
foo :: (IArray a e, Ix i) = a i e - a i e
Use (!), (//), bounds, assocs, array etc. from module IArray (not Array).
They are overloaded over class IArray, which includes Array and UArray.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: trouble with ghc-4.08.2-1.i386.rpm
09 Mar 2001 15:50:42 +0900, Jens-Ulrik Petersen [EMAIL PROTECTED] pisze:
(BTW are there plans to upgrade to gmp3, which seems to be standard
now in the Linux world?)
Any comments on this?
The CVS version of ghc uses gmp3 for a long time.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fail: thread killed
I think I have raised the issue some time ago, but don't remember
why it hasn't been solved as I would like to.
Currently a thread which is killed displays Fail: thread killed,
e.g. in the following program:
import Concurrent
main:: IO ()
main = do
t - forkIO (threadDelay 100)
threadDelay 50
killThread t
threadDelay 50
Since the very purpose of killThread is to kill the damn thread,
I find it inconvenient to have to wrap any thread which is supposed
to be killable with Exception.catch to avoid the message. Worse:
it should use block and unblock, otherwise there is a small window
where killing the thread will still display the message.
I can probably agree that other kinds of exceptions are displayed;
maybe the programmer didn't know that exceptions are being thrown and
wants the diagnostic. It implies that any well-written code should
catch exceptions in all threads it creates (unless he is sure that the
code will not throw exceptions), since there shouldn't be compiler's
error output from a correct program. Not nice but I can live with that.
Should asynchronous exceptions be really displayed in threads other
than the main thread? IMHO not.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: --add-package
On Fri, 23 Feb 2001, Simon Marlow wrote: I don't think I agree. Installation of an external package shouldn't be doing --delete-package first: that should be left to the user (or rpm -e, or whatever). rpm is a different story. I would expect 'make install' to be idempotent. With your scheme one has to write 'make uninstall install'. -- Marcin 'Qrczak' Kowalczyk ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--add-package
In practice installation script of an external package does
--del-package before --add-package, because if it was installed before,
--add-package would cause an error.
Wouldn't be reasonable then to let --add-package overwrite any existing
package of that name? There is no real safety, because the package
is explicitly deleted anyway.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C-Haskell 0.8.1
Mon, 19 Feb 2001 15:53:41 +1100, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze:
Strange - meanwhile, I have put release 0.10.4 out.
Among other things, it finally has an `install' target.
Thanks, everything compiles and mostly works. Examples still behave
strangely: rngtest goes crazy when changing the number of digits,
all rngtest's widgets are displayed with some black border unless the
mouse cursor is over them, the scale in ih/examples/Counter does not
work, threadtest does not work etc.
`castCCharToChar' and `castCharToCChar' should be sufficient
here, right?
Yes. Same in C2HSDeprecated.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C-Haskell 0.8.1
Fri, 16 Feb 2001 18:42:08 +1100, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze:
Now, everything should be checked in.
Seems OK, thanks.
ghc411hack_dir does not work for me again: ghc -M in build/ghc4/chs/lib
can't find NewStablePtr.hs (because there is only NewStablePtr.hs.in)
and the whole 'make depend' there fails, without removing files
conflicing with ghc' libraries. The failure of 'make depend' is
ignored and finally 'make' there fails to compile C2HS.hs.
I thought that I had fixed all this for Gtk+HS. (In fact,
all Gtk+HS examples are running fine with GHC 4.08 on my
machine.) Have a look at the file gtk+hs/gtk/ghcRtsAux.c.
It defines rts_mkPtr in a somewhat nasty way, but it works :-)
I've seen the hack, but on another box freshly installed ghc-4.08.2,
c2hs from tarball and gtk+hs from tarball did not work (linker can't
find rts_mkPtr). I must see if ghcRtsAux.c is compied at all there.
PS: With the current Gtk+HS source in CVS, all Gtk+HS
examples as well as the iHaskell library and its three
examples should now all work again. I tested it all on
my machine.
ghc version check fails on 4.11 (it should be lexicographic comparison
of version number components, not conjunction of independent
comparisons).
Checking for buggy readXXXOffAddr (for ghc-4.03..4.06) is now
unnecessary as gtk+hs requires ghc-4.08.1 anyway.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C-Haskell 0.8.1
16 Feb 2001 09:21:51 GMT, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] pisze:
ghc411hack_dir does not work for me again:
Ah, I see: haven't run autoconf in c2hs subdirectory. Now it will
hopefully work.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C-Haskell 0.8.1
Fri, 16 Feb 2001 18:42:08 +1100, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze:
PS: With the current Gtk+HS source in CVS, all Gtk+HS
examples as well as the iHaskell library and its three
examples should now all work again. I tested it all on
my machine.
gtk+hs under ghc-4.11 needs -package lang in HCFLAGS in configure.in.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C-Haskell 0.8.1
Fri, 16 Feb 2001 18:42:08 +1100, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze:
PS: With the current Gtk+HS source in CVS, all Gtk+HS
examples as well as the iHaskell library and its three
examples should now all work again.
They compile but they don't run correctly on ghc-4.11. It's because
GMarsh.writeCharOffAddr does not simulate Addr.writeCharOffAddr when
Char is wide, because instance Storable Char treats Char as wide.
You need to cast to CChar, Word8, or Int8 (be careful with sign
extension).
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C-Haskell 0.8.1
Thu, 15 Feb 2001 18:44:56 +1100, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze:
But the error in CInfo is still there.
That's strange. Could you try this with either the release of
0.8.2 that I put up yesterday or with the CVS version again?
Hmm, it works now. There are two files called C2HSConfig.hs (in
c2hs/lib and c2hs/toplevel). I don't know why the wrong one was
being imported.
As noted on the Web page, 0.8.1 didn't work with gtk+hs.
You need c2hs 0.8.2 and the new version 0.10.2 of gtk+hs,
which I released yesterday. (Alternatively, the versions of
both packages in CVS should work, too.)
Both are current versions from CVS, with version numbers as you say.
Does C2HSDeprecated export newStablePtr and freeHaskellFunPtr?
Currently it does not, but GtkCList assumes it does.
Does C2HS export castPtrToFunPtr? Currently it does not, but GMarsh
assumes it does.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C-Haskell 0.8.1
12 Feb 2001 14:48:09 GMT, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] pisze:
It could be my fault: I ran ./configure before updating it with
autoconf, and perhaps did not clean afterwards.
Ok, it was my fault. But the error in CInfo is still there. And
C2HS does not export most of cast*Ptr functions, freeHaskellFunPtr
and newStablePtr, which leads to errors in compilig gtk+hs. And
GtkCList (from the CVS version of gtk+hs) does not import C2HS but
uses newStablePtr etc. And ghc version check in gtk+hs fails for 4.11.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C-Haskell 0.8.1
Mon, 12 Feb 2001 14:07:01 +1100, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze:
This is very strange, because I have tested this and it
worked for me.
It could be my fault: I ran ./configure before updating it with
autoconf, and perhaps did not clean afterwards.
In fact, if you look at the Makefile in the c2hs/lib/ directory,
then you will see that the `depend' target moves these troublesome
files into a subdirectory before compilation
So they will be downloaded each time from the CVS... Perhaps it
would be better to store them under different names and make symlinks
if needed?
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: C-Haskell 0.8.1
11 Feb 2001 13:36:31 GMT, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] pisze:
A problem:
[...]
These problems apply to cvs' HEAD.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC-4.08.2
Thu, 08 Feb 2001 17:09:19 +1100, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze:
This will only work if you install RPM 4, no?
True. I didn't know whether the src.rpm format also changed.
AFAIK it did not change.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Semi-applied datatypes in instance declarations
On Tue, 6 Feb 2001, George Russell wrote: I apologise if this has been raised before, but the code I am writing now would look rather nicer if "partially applied type constructors" were permitted in instances. They are. For example monads. -- Marcin 'Qrczak' Kowalczyk ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Floating point performance
Mon, 29 Jan 2001 18:15:02 +0100, Jan Kort [EMAIL PROTECTED] pisze:
I didn't use any optimizations, but I am sure that
passing -O to ghc will make it see that 1*1*... is a
constant expression.
It does not, because it's n*1*1*1*... where n is not a constant.
Major advantages seem to be from the strictness analysis.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Floating point performance
Fri, 26 Jan 2001 17:40:17 +0100, Jan Kort [EMAIL PROTECTED] pisze:
I made a profile and it says most of the time (93%) is spent in
the function bar.
Did you compile with optimization turned on (option -O)?
I see similar results without -O but quite different with -O.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_scc_
Why
_scc_ "foo"
and not
{-# SCC "foo" #-}
?
IMHO a pragma would be better: does not make the scc-annotated program
non-standard.
(Well, nhc98 should be fixed to ignore unknown pragmas in arbitrary
places.)
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Generic Classes?
Sat, 30 Dec 2000 09:02:55 -0800, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
They'll be in our first release of GHCi.
What about my old comments about distinguishing "the rest of
constructors" from "contents of the constructor we found", and
"the rest of fields" from "contents of the field we are considering"?
IMHO the current state is wrong. Generic instances should not
*require* that operations are directly propagated to arguements of
constructors and values of fields. What happens when we are on the
level of finding a constructor should be separated from what happens
when we are looking inside its fields. And dually, combining fields
should be separated from looking at the value of a field.
It's simple to fix, modulo performance issues. I consider the fixed
version a very good and usable solution, and the current version an
unusable partially flawed design...
It should be possible to rewrite classes which are derivable now
to use the generic mechanism instead of ad-hockery in the compiler.
Bit it will be possible only after the design is fixed not to confuse
constructors and their arguments, and not to confuse sets of fields
and their contents.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Transitive inlining
Tue, 12 Dec 2000 00:41:01 +1100, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze:
PS: I had problems building GHCi and it seems as if my
message to [EMAIL PROTECTED] doesn't get through
somehow...
Subject: "mail boot" problem
?
I have got it.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fun with GHC's optimiser
Thu, 7 Dec 2000 09:17:44 -0800, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
Try now. On the HEAD. Which should compile OK now, incidentally.
But does not work...
../../ghc/compiler/ghc-inplace -recomp -cpp -fglasgow-exts -fvia-C -icheck -O
-package lang -package concurrent -package posix -package-name util -I../lang/cbits
-I../concurrent/cbits -I../posix/cbits -split-objs-c Unique.lhs -o Unique.o
-osuf o
panic! (the `impossible' happened):
mkWWcpr: not a product PrelNum.Integer{-311-}
And also:
ghc-inplace --interactive
[...]
Loading package std ... resolving ... ghc: fatal error: ocResolve_ELF:
/home/users/qrczak/cvs/fptools/ghc/driver/../lib/std/HSstd.o: unknown symbol
`PrelNum_showSignedInteger_closure'
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Or-patterns
Mon, 04 Dec 2000 17:17:42 +0100, George Russell [EMAIL PROTECTED] pisze:
Where you have variables in the patterns, you bind only the
variables which appear in all the patterns, and you unify the
types accordingly.
Or bind them all (otherwise there would be _ written) and get bottom
in case the matching subpattern did not bind the given variable.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Instant readFile
Wed, 15 Nov 2000 18:42:29 +0100, George Russell [EMAIL PROTECTED] pisze:
What I want instead is a function which
(a) opens the file;
(b) slurps the complete contents compactly into an array;
(c) closes the file;
(d) makes the contents of the array available as a String.
Applying
foldr (\_ t - t) (return ())
to the string (and executing this application as an IO action) will
force it to be read completely. If it came from readFile, the file
gets closed as soon as the string is evaluated up to its end.
It all is a bit of a mystery to me how you are supposed to use Addr
like things without space leaks. A little more explanation in the
documentation would not perhaps be amiss . . .
Unfortunately the design of these areas (conversion between Haskell
strings and C strings) is not yet complete. And Unicode in Haskell
strings (already implemented in GHC development versions) will make
the library more complex.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Help me to correct this code, please ! :-)
Fri, 29 Sep 2000 12:26:42 -0300, [EMAIL PROTECTED] [EMAIL PROTECTED] pisze:
instance Ix ix = Foo (MutableByteArray s ix) where
foo x = runST(unsafeFreezeByteArray x)
Mutable objects in the ST world, parametrized by those s type
variables, must be created and used "locally" in an ST computation.
Functions operating on them (like readSTArray) tie the type variable
of these objects with the type variable of the ST computation. If
this type variable is also bound outside (like here in the instance
declaration), the argument of runST is no longer fully polymorphic
wrt. s, as required by the type of runST. runST can be applied only
to a computation which does not return nor refer to a mutable value
from outside.
Conversion between mutable and immutable arrays cannot be expressed
as a pure function because the effect would depend on when its result
is evaluated. They can be converted only by ST actions (which share
the type variable s with the mutable object). Your function is not
just unimplementable, but it would lead to an unsound semantics if
it existed.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
My mistake is harder to diagnose than it could be
I've just done the same mistake a third time: took a module A, moved
part of it to a new module B, imported A from B, but forgot to change
the module header in B which still said "module A".
The GHC's answer to that when compiling B.hs is that the module A
does not export a bunch of things (if listed explicitly in import),
or that they are not found at all (if imported the whole A). Things
that are easily seen exported from A.hs - strange that I was wondering
again what's going on.
GHC should warn when a module imports itself. Or warn about mismatches
between the module and file name except Main. Or whatever - the current
error message is not very helpful.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
Re: The type of zip
Fri, 28 Jul 2000 08:23:52 -0700, Simon Marlow [EMAIL PROTECTED] pisze:
It perhaps should be, but Int8 isn't a primitive type: it's implemented in
terms of Int#. There should really be 8-bit, 16-bit and 32-bit primitive
types in GHC
It's not a problem: writeInt8OffAddr could take Int#. I think that
the overhead of an allocated object makes the exact representation
of Int8 irrelevant. What matters is the ability to pack them tightly
in arrays, or index pointers by multiplies of 8/16/32/64 bits -
for talking with C.
I have read Intel docs about IA-64. Almost everything is being computed
on 64 bits, smaller sizes are only in memory. Maybe having only Int#,
Word#, plus on a 32-bit arch also Int64#, Word64#, would be easier.
It does not require a lot of arithmetic, relational and conversion
primops for example. NCG would be easier for a single size of integers;
it does not handle {Int,Word}64# yet.
But maybe they should be true types. If so, Int and Word module could
be more regular - maybe even producing versions for varying sizes
from a single template. It's more correct but requires more work.
Anyway, I will need 32-bit array indexing for PackedString containing
characters outside '\1'..'\xFF'. {Int,Word}{8,16,32,64} will be more
often used in practice in mirrors of C types. IMHO pointer indexing
of these types should definitely be integrated into the RTS, but I
have no opinion about types themselves. I can try to do that myself
in any of the two ways, except the NCG.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: GHC Renamer
Mon, 17 Jul 2000 15:38:45 -0500, Kate S. Golder [EMAIL PROTECTED] pisze:
Are these declarations simply added to all files?
They are values referenced in RULES pragmas in Prelude modules.
In particular what are "PrelBase.zi" and "PrelBase.zaza"?
Look at ghc/compiler/basicTypes/OccName.lhs in GHC's sources.
It describes and implements the encoding of Haskell names as valid
alphanumeric identifiers. In particular zi is (.) and zaza is ().
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Glob functionality in GHC/Haskell
Mon, 10 Jul 2000 19:11:35 -0400, Alexander Williams [EMAIL PROTECTED] pisze:
/tmp/ghc10834_stb.h:2: parse error before `Examples_d6q9'
/tmp/ghc10834_stb.h:2: warning: type defaults to `int' in declaration of
`Examples_d6q9'
/tmp/ghc10834_stb.h:2: warning: data definition has no type or storage class
ghc-4.08 has some bugs (with newtypes in foreign export) that have
been fixed in the development version (4.07 which is 4.09 now).
I've installed 4.08, http://qrczak.ids.net.pl/qforeign.tar.gz now
has a workaround and should work.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: perl frontend for ghc
Wed, 28 Jun 2000 02:36:04 -0700, Simon Marlow [EMAIL PROTECTED] pisze:
But fortunately now we have, and if you look at the current CVS
HEAD you'll see the new driver, written (almost) entirely in Haskell.
Written in Haskell when we consider a compiler which is needed to
compile it, but it's still written in Perl when we consider the
style:-)
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Method contexts
The restriction that a method context must constrain at least one
type variable that is quantified there has biten me:
class Member c a | c - a where member :: Eq a = c - a - Bool
class Member (s a) a = Sequence s a where single :: a - s a
instance Member [a] a where member s a = elem a s
instance Sequence [] a where single x = [x]
I cannot move the constraint to the class context because it would
force Eq a on all Sequence methods. I cannot have class Member c
(where c has kind *-*) because it is used differently in other places.
Hugs does accept the above definitions.
Could this restriction be removed in ghc please?
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Can't catch exception in socket communication
Wed, 21 Jun 2000 02:00:09 -0700, Simon Marlow [EMAIL PROTECTED] pisze:
installHandler sigPIPE Ignore Nothing
That seems to be enough.
That's it. This one caught me too! But it's standard behaviour,
so I think we should leave it in place.
Adding a note in the documentation.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: GHC Version numbers (was: RE: 4.07 release candidate snapshot ava ilable)
Mon, 19 Jun 2000 20:59:07 -0500, Matt Harden [EMAIL PROTECTED] pisze:
Numbers ending in ".0" are counterintuitive to me.
So start with ".1" :-)
As Linux kernel.
(I see nothing wrong with ".0".)
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Dynamic and persistent data storage
Mon, 12 Jun 2000 20:42:16 +1000 (EST), [EMAIL PROTECTED] [EMAIL PROTECTED] pisze:
To do this would require several things the current Dynamic library lacks:
[...]
I think it's much harder. How would you store and restore actual data?
It depends on its real type, and for many types it's impossible or
impractical ((-), IO, ForeignObj, Handle, MVar, ThreadId), even if
in some sense every part of the value is already evaluated.
OCaml's values look a bit simpler. There exist functions for dumping
and restoring almost any values, even with cycles, and optionally
with functions, provided that it is restored in a process running the
same binary program - code addresses are stored. No type information
existed before dumping (integer 0 looks exactly as false and [] and
NONE) and thus none is restored. You get fancy coercions or undefined
behavior when restoring to a wrong type.
Do you mean storing the physical structure of values without knowing
their types, similarly as in OCaml? Or overloaded specialized dumpers
and restorers for particular types?
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Posix.FileStatus: st_rdev from struct stat is missing
Mon, 12 Jun 2000 09:36:33 -0700, Sigbjorn Finne [EMAIL PROTECTED] pisze:
None of these are POSIX supported (same with st_blksize.)
Ah.
Sorry if I asked this before, but I could not find the answer now:
are POSIX specifications freely available somewhere?
It would be nice to have module(s) Unix, providing parts of the
interface of e.g. The Single UNIX(R) Specification, as an addition to
Posix (i.e. the same FileStatus would have additional fields visible,
and lstat would be there).
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Posix.FileStatus: st_rdev from struct stat is missing
The subject says all.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Signals
Thu, 8 Jun 2000 18:26:27 -0700, William Lee Irwin III [EMAIL PROTECTED] pisze:
Is there a curses library in the works?
Yes, inside http://qrczak.ids.net.pl/Haber-0.2.tar.gz (requires ghc-4.07).
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Signals
I want to clean up (close curses) on termination on signals.
Is there a way of doing this for all relevant signals at once, or I
should install separate handlers for each?
Is there a better way of executing the old handler than the following?
fixIO $ \old - installHandler
keyboardSignal
(Catch (do
endWin
installHandler keyboardSignal old Nothing
raiseSignal keyboardSignal))
Nothing
sigaction returns complete information about the old signal: handler,
mask and flags, thus allowing exact restoring of the previous
state. But Posix.installHandler returns only the old handler, and
does not take nor return any flags. The above is only an approximation.
Should it be fixed?
Why installHandler takes Maybe SignalSet instead of SignalSet?
Nothing is equivalent to emptySignalSet, it does not carry any
additional information.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
RULES for conversions of CTypes
Fortunately it's not needed to make N^2 rules for N types!
{-# RULES
"fromIntegral/a-CShort" fromIntegral = \x - CShort (fromIntegral x)
"fromIntegral/a-CUShort" fromIntegral = \x - CUShort (fromIntegral x)
"fromIntegral/a-CInt"fromIntegral = \x - CInt(fromIntegral x)
"fromIntegral/a-CUInt" fromIntegral = \x - CUInt (fromIntegral x)
"fromIntegral/CShort-a" fromIntegral = \(CShort x) - fromIntegral x
"fromIntegral/CUShort-a" fromIntegral = \(CUShort x) - fromIntegral x
"fromIntegral/CInt-a"fromIntegral = \(CIntx) - fromIntegral x
"fromIntegral/CUInt-a" fromIntegral = \(CUInt x) - fromIntegral x
#-}
(and similarly for the rest of types) should catch all cases.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Unicode
Tue, 16 May 2000 10:44:28 +0200, George Russell [EMAIL PROTECTED] pisze:
As for the language standard: I hope that Char will be allowed or
required to have =30 bits instead of current 16; but never more than
Int, to be able to use ord and chr safely.
Er does it have to? The Java Virtual Machine implements Unicode with
16 bits. (OK, so I suppose that means it can't cope with Korean or Chinese.)
So requiring Char to be =30 bits would stop anyone implementing a
conformant Haskell on the JVM.
OK, "allowed", not "required"; currently it is not even allowed.
The minimum should probably be 16, maximum - the size of Int.
Oops, ord will have to be allowed to return negative numbers when
the size of Char is equal to the size of Int. Another solution is to
make Char at least one bit less than Int, or also at the same time
no larger than 31 bits. ISO-10646 describes the space of 31 bits,
UTF-8 is able to encode up to 31 bits, so then a UTF-8 encoder would
be portable without worrying about Char values that don't fit, and
a decoder could easily check if a character is representable in Char:
ord maxBound would be guaranteed to be positive.
Choices I see:
- 30 = Int, 16 = Char = 31, Char Int
- 30 = Int, 16 = Char, Char Int
- 30 = Int, 16 = Char, Char = Int
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Unicode
Tue, 16 May 2000 12:26:12 +0200 (MET DST), Frank Atanassow [EMAIL PROTECTED] pisze:
Of course, you can always come up with specialized schemes involving stateful
encodings and/or "block-swapping" (using the Unicode private-use areas, for
example), but then, that subverts the purpose of Unicode.
There is already a standard UTF-16 encoding that fits 2^20 characters
into 16bit space, by encoding characters =2^16 as pairs of "characters"
from the range D800..DFFF, which are otherwise unused in Unicode.
Programmers should not be expected to care about this; most will not
anyway. Libraries will handle this format in external UTF-16-encoded
strings.
UTF-8 is usually a better choice for external encoding; UTF-16 should
be rarely used.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Unicode
How safe is representinging Unicode characters as Chars unsafeCoerce#d
from large Ints? Seems to work in simple cases :-)
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Warnings about unused modules
GHC -Wall warns about unused entities that were explicitly imported,
but does not warn about unused "import SomeModule". Maybe it should...
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
RE: Converting float to double.
On Wed, 10 May 2000, Simon Marlow wrote:
{-# RULES
"realToFrac/Float-Double" realToFrac = floatToDouble
"realToFrac/Double-Float" realToFrac = doubleToFloat #-}
Is this 4.06? The current prelude contains
{-# SPECIALIZE realToFrac ::
which should provide for all your float-converting needs :-)
It only provides specialization of this definition, i.e. fromRational and
toRational dispatching is done at compile time (which, I hope, is done
automatically anyway at least in cases where such function gets inlined).
The compiler cannot guess that some primitive Float-Double function can
be used instead of going through Rational.
AFAIR integral types do have {-#RULES#-} for conversions between each pair
of them, including Int16/Word64/etc. I'm not sure about Int-Double etc.
(both fromIntegral and realToFrac can be used here!).
--
Marcin 'Qrczak' Kowalczyk
Re: Converting float to double.
Wed, 10 May 2000 13:49:30 +0200 (CEST), Lennart Augustsson [EMAIL PROTECTED]
pisze:
(BTW, hbc has optimized these conversion since about 6 years ago.)
How? RULES similar to ghc? Or built-in compiler magic for this case?
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Completely abstract types
What should be the preferred way of declaring completely abstract
types, without any meaningful representation known anywhere, for use
as a tag only (of the Ptr type from some new Foreign library)?
1. data CFile = CFile
GHC -Wall warns that I don't use the data constructor anywhere.
Right, this is what I indend to do, I don't want to export it,
and I don't want this warning.
2. newtype CFile = CFile CFile
This is really without any non-bottom representation. The problem
is as the previous one.
3. data CFile
This syntax is not currently supported. Would it make sense?
4. ???
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: putMVar on full MVar
Wed, 12 Apr 2000 15:12:31 +0100, Claus Reinke [EMAIL PROTECTED] pisze:
PS. As for tryTakeMVar or locks on MVars, what is wrong
with using MMVar a = (MVar (MayBe a)) and a suitable
access protocol?
MVar empty-- MMVar is locked
MVar Nothing -- MMVar is empty, not locked
MVar (Just v) -- MMVar holds value v, not locked
That it's impossible to implement the equivalent of takeMVar
(block until it is full).
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: tryTakeMVar :: MVar a - IO (Maybe a)
Sun, 9 Apr 2000 13:54:47 -0700, Sigbjorn Finne [EMAIL PROTECTED] pisze:
Wouldn't be nice to have such function?
Have you tried using Concurrent.isEmptyMVar ?
isEmptyMVar is not enough to implement tryTakeMVar (but tryTakeMVar
would suffice for isEmptyMVar). Just after checking that it is empty
I can't safely take the value out of it, because it could be taken
by another thread right between and I will sleep for a long time then.
tryTakeMVar is a safe variant of isEmptyMVar. The equivalent of
pthread_mutex_trylock and Mutex::try_lock in Ruby.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
tryTakeMVar :: MVar a - IO (Maybe a)
Wouldn't be nice to have such function?
I wanted to translate a thread example written in Ruby and realized
that it's impossible to write that function using MVar primitives
provided; and no module seems to provide an equivalent using
another kind of concurrent variable. I had to simulate mutexes with
MVar (Maybe [MVar ()]) instead of MVar (). I guess that this function
should be possible to implement on plain MVars.
The semantics is obvious: if the variable is empty, return Nothing,
else take its value and return Just it.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Debugging techniques
Thu, 6 Apr 2000 12:15:26 -0700, Michael A. Jones [EMAIL PROTECTED] pisze:
Second, perhaps you can suggest a place I can ask newbie questions
that is more appropriate than this list.
IMHO this is good. For questions not related to GHC there is a parallel
haskell mailing list, and there is a newsgroup comp.lang.functional.
Are there any papers/docs on debug techniques for debugging programs
compiled under GHC?
I don't know any.
Is there a way to force a statement in a let expression to evaluate
and thus print text?
In GHC there is an unsafe function
IOExts.trace :: String - a - a
which returns a value which, when evaluated, prints the given text
before evaluating the second argument of trace.
I tried to perform IO in a let expression, but it seems that it wont
evaluate if some other value does not depend on it, or execution
never reached the let.
Well, laziness is exactly about this, and unfotunately it makes
conventional debugging techniques inappropriate.
Haskell's laziness includes the rule that mere evaluation of
an expression cannot cause any visible side effects other than
nontermination. An expression is evaluated only when its value is
needed to determine the value of another expression, and it was
evaluated only because... etc.
The fist rule ensures that you can always forget that there is laziness
(modulo efficiency issues). The second one ensures that the result
will be the same as for any other evaluation order, if the other
order would give any result at all; but there are cases where lazy
evaluation order does give a result and some other does not or does
it very inefficiently.
This has impact on interface to side effects. Thus I/O is normally done
differently. A function like trace breaks the spirit and theoretical
model of the language. It is included in GHC because it's convenient
for debugging (although I have almost never used it), but theoretically
it should not exist.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: lex 1x23 == [(123,)] reads 1x23 == [(123,)]
Tue, 14 Mar 2000 01:28:47 -0800, Simon Marlow [EMAIL PROTECTED] pisze:
I'm incorporating Daan Leijen's Parsec library (a complete,
fast, and well-documented parsing combinator library, see
http://www.cs.uu.nl/~daan/parsec.html) into hslibs.
Great! I haven't seen it before.
Oops, what about the TokenDef module? Even if it can be done using
some hi-boot stuff, looks as a strange design, and only one instance
can be ever used in one program... IMHO it should be brought to a
standard module scheme. But how?
Manual parametrizing most functions with tokenDef would be not very
convenient and perhaps not very efficient. Maybe it would make sense
to first try to simulate parametrized modules by mechanisms we already
have, then think about how Haskell can be improved to make it easier.
Records. Luckily we have local polymorphism.
module ParseToken
data ParseToken = ParseToken {
identifier :: Parser String,
reserved :: String - Parser (),
operator :: Parser String
-- etc.
}
parseToken:: TokenDef - ParseToken
parseToken tokenDef = ParseToken {
identifier = identifier,
reserved = reserved,
operator = operator}
where
... current module contents ...
module using ParseToken
import ParseToken (ParseToken(..), parseToken)
import StdTokenDef (haskell)
ParseToken {
identifier = identifier',
reserved = reserved',
operator = operator'}
= parseToken haskell
... And now use it as currently, only adding primes to names.
Is it worth some syntactic sugar to make such parametrized modules
more alike normal modules?
It's easy on the exporting side. Just make creation of records similar
to plain declarations.
parseToken:: TokenDef - ParseToken
parseToken tokenDef = ParseToken struct
... current module contents ...
... (well, excluding types, classes and such) ...
I.e. struct {...} is roughly equivalent to {...} of record creation,
with thanslation similar to the above.
It's harder on the other side. I imagine a declaration like
open parseToken haskell
that would bring into the scope everything inside the record whose
selector functions are currently visible - but the selector functions
are still visible, so if it's a global declaration, we have conflicts.
So, will Haskell have ML-like structures, only better, because
first-class?:-)
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: lex 1x23 == [(123,)] reads 1x23 == [(123,)]
Mon, 13 Mar 2000 03:34:28 -0800, Simon Marlow [EMAIL PROTECTED] pisze:
Thanks, this is now fixed (well partially, we don't attempt to lex
hexadecimal literals any more).
Good, I actually wanted to parse WIDTHxHEIGHT :-)
Generally I don't understand why some languages provide libraries
for approximate lexing and parsing of source code of these languages
themselves, instead of some more general parsing libraries.
Most of the time one wants to parse according to some format
defined elsewhere. And even when rules need not to be very specific
(e.g. lexing numbers from command line options), it's very rare that
he wants to strip comments as defined by the source language syntax
or use language-specific base specifications.
On the other hand, for parsing exactly the given language, these
built-in parsers are too simplified. So what are they for?!
Dually, Show is most often used:
- for printing numbers
- for debugging messages
and probably very little more.
Leaving Read and Show, IMHO GHC should include ParseLib or a similar
library. Happy is too heavy for parsing WIDTHxHEIGHT. Is there any
newer version of ParseLib than that in Hugs?
Even ParseLib has some functions very specific to Haskell syntax. Hmm.
Fortunately it's simple enough to write custom versions that fit
the domain. Anyway, I would expect the function "integer" to parse
Integers, not to be a variant of "int" which skips following whitespace
and Haskell comments - BTW, why not parse number polymorphically over
Num? Good that nat is separated from int. IMHO functions like ident
should be parametrized by parsers recognizing the first valid character
and one of the non-first characters (it's a common enough pattern)
instead of being tied to Haskell syntax. Floating point is missing.
Also I would provide a wrapper function
\parser str - case [x | (x,"") - papply parser str] of
x:_ - Just x
[] - Nothing
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
STArray and MutableArray
Why are there separate STArray and MutableArray types, as their
representation is the same?
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Qualified names in foreign export
Shouldn't foreign exported names be allowed to be qualified?
I've just accidentally reused a Prelude name for a function to be
foreign exported and could not resolve the conflict with the first
way that came to mind: qualifying.
It's only not obvious what C name would it get by default. Probably
the unqualified one.
BTW. The fact that functions containing the letter z in their names
will get zz in C names, unless explicitly specified differently,
should be either changed or documented.
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
