Re: [Haskell-cafe] Type inference
Cale Gibbard wrote: On 09/02/06, Brian Hulley [EMAIL PROTECTED] wrote: Brian Hulley wrote: f :: forall m. (forall a. a-m a) - c - d - (m c, m d) Of course this type doesn't work on your original example, since (,) is a type constructor with two parameters, not one, but this type signature does actually work just fine in GHC. --- data Pair x = Pair x x deriving Show data Id x = Id x deriving Show f :: forall m c d. (forall a. a - m a) - c - d - (m c, m d) f g x y = (g x, g y) --- *Main f (\x - Pair x x) 3 hello (Pair 3 3,Pair hello hello) *Main f (\x - Id x) 3 hello (Id 3,Id hello) Perhaps in practice this kind of workaround is sufficient, although this requires you to put the results into a form that can be syntactically matched against m a. I wonder though if it would be possible to have a type system that would work for my original example by automatically creating internal declarations type T1 a = (a,a) and type T2 a = a so that m would match against T1 and T2 respectively. It is difficult to know if this would be a worthwhile thing to do or if most practical applications of polymorphism in any case involve transformations whose shape can be captured sufficiently with multi-param typeclasses etc. Regards, Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI question
On 2/9/06, Frederico Franzosi [EMAIL PROTECTED] wrote: Hi, I don't really know how this stuff exactly works, but here's few things I have found useful when I ran into this sort of problems. I'm developping a package wich imports C functions. For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib it gives an error message (undefined references of objects from PKG to functions in lib) I don't have exact answer, but ghc uses ld under the hood and sometimes the order of libraries on ld command line matters. Here's few things that might be useful if that's the case. Use ghc -v and find final link ld/gcc (I don't recall which one ghc invokes for linking) and try that line yourself, you can also move libraries up on list etc to find what order you actually need. Add -llib to the options in package.conf as a library- try adding as first and try adding as last. Try both ;-) Try adding as object file, ie /path/to/lib.a Order of arguments on ghc command line doesn't matter so much, because ghc will put (if I recall correctly) package libraries first and then add -llib and such options to the end on the ld command line- so it's pretty hard to work around the problem just by invoking ghc different way. $ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a it compiles correctly. and also when I do: $ghc -package PKGname-PKGversion -fffi -o main Main.hs /path/to/lib.a If I were to guess these work because /path/to/lib.a is handled as an object file, which is somehow different from being library. I have no knowledge what and why there is this sort of magic restrictions. HTH, -Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Elementary HaXml question
Hi all, I'm new to Haskell and HaXml and I'm playing around with the latter to clean some (well-formed) 'legacy' html. This works fine except for the following cases. Some of the elements to be cleaned are: font size=4iHello World/i/font ifont size=4Hello World/font/i This should become: h1 class=subtitleHello World/h1 I can build filters to find font, font size=4 or i, but the combination does not seem to work. From what I could gather from the documentation, it should be something like: foldXml (txt ? keep : (attrval(size,AttValue[Left 4]) `o` tag font) / tag i ? replaceTag h1 : children) This doesn't work. I am clearly missing something elementary here, so any hints are welcome. Cheers, K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: FFI question
Frederico Franzosi wrote: I'll try to make it short. I'm developping a package wich imports C functions. the fact is that when I try to compile if I call the compiler in the usual way, using -package and -llib it gives an undefined reference error... For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib it gives an error message (undefined references of objects from PKG to functions in lib) but if I use: $ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a it compiles correctly. It looks like -llib is appearing earlier on the linker's command line than the library from your package, when you use -package. You haven't specified a dependency between the two, so GHC is making an arbitrary choice. The right way to fix this, if your package depends on a library, is to include that library in the extra-libraries field of the package. Cheers, SImon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type inference
Brian Hulley wrote: Fred Hosch wrote: Is type inferencing in Haskell essentially the same as in SML? The most significant difference certainly is that type inference has been beefed up with type classes in Haskell, which are quite a powerful mechanism refining Hindley/Milner inference. Besides that, Haskell allows some additional programs for which types can /not/ be inferred (e.g. the examples Brian was giving), while SML does not. SML also has a complicated thing called the value restriction because it allows mutable references to be altered via side effects. Because Haskell has no side effects, there is no need for a value restriction. Although there is no need for it, Haskell still has it, in minor variation. It is commonly known as The Dreaded Monomorphism Restriction ;). - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Emulating bash pipe/ process lib
Marc Weber Marc Weber wrote: Hi. I want to write a little haskell program executing about 4 programs passing data via pipes. As my python script seems to be slower than a bash script I want to try a ghc executable now. It should invoke different parts of a text to speech chain. This way I have one interface then. Talar und #haskell told me that I might use runProcess and pass handles for stdin and out created by createPipe and fdToHandle. So my simple test looks like this: module Main where import System.IO import System.Posix.IO main = do (fdIn,fdOut) - createPipe let (iohIn, iohOut) = (fdToHandle fdIn, fdToHandle fdOut) hIn - iohIn hOut - iohOut hPutStr hIn test line - hGetLine hOut print line -- should now print test having been piped through my pipe but I get the error: pipe2: file descriptor: 3: hPutStr: illegal operation (handle is not open for writing) And in current CVS docs in base.System.Process.hs it is said that createPipe is no longer exported ? If you want to communicate with external programs via pipes, then System.Process should provide everything you need. Take a look at runInteractiveProcess in particular. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Emulating bash pipe/ process lib
On 2/9/06, Marc Weber Marc Weber [EMAIL PROTECTED] wrote: Hi. I want to write a little haskell program executing about 4 programs passing data via pipes. As my python script seems to be slower than a bash script I want to try a ghc executable now. It should invoke different parts of a text to speech chain. This way I have one interface then. There is also the HsShellScript library, which has many utilities for using Haskell as a shell programming language, including good support for piping. You can find it here: http://www.volker-wysk.de/hsshellscript/ -- Kurt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elementary HaXml question
I'm new to Haskell and HaXml and I'm playing around with the latter to clean some (well-formed) 'legacy' html. This works fine except for the following cases. Some of the elements to be cleaned are: font size=4iHello World/i/font ifont size=4Hello World/font/i This should become: h1 class=subtitleHello World/h1 From what I could gather from the documentation, it should be something like: foldXml (txt ? keep : (attrval(size,AttValue[Left 4]) `o` tag font) / tag i ? replaceTag h1 : children) Is the bracketing correct? I can't remember the precedence of the operators offhand, but perhaps it should be foldXml (txt ? keep : (((attrval(size,AttValue[Left 4]) `o` tag font) / tag i) ? replaceTag h1 : children)) Yes, the braketing is correct since the following code: foldXml (txt ? keep : fontSize4 / tag em ? mkSubtitle : children) fontSize4 = (attrval(size,AttValue[Left 4]) `o` tag font) mkSubtitle = mkElemAttr h1 [(class, (subtitle!))] [children] now transforms font size=4emHello World/em/font into h1 class=subtitleemHello World/em/font Which I'm satisfied with (hurray!). The em appears because I 'keep' it higher in the original switch, the example above is just an extract for brevity's sake. I still have a problem with the other example: emfont size=4Hello World/font/em I _think_ the line in the .hs file should be: tag em / fontSize4 ? mkSubtitle : Which doesn't work, and I don't know why. If the first example works, shouldn't the second, too? I also tried tag em / font ? mkSubtitle : Which doesn't work either. I transformed it into tag font `o` children `o` tag em ? mkSubtitle : without avail. Again, any ideas are welcome. (btw: I like HaXml, Malcolm, nice work!) Koen. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI question
On Thu, 9 Feb 2006, Christopher Brown wrote: Frederico, Have you tried using Green Card? http://haskell.org/greencard/ It is basically a foreign function pre-processor for Haskell. It allows your Haskell programs to interface with C libraries in a very straight forward way. I tried it, and managed to get it working to some extent. Then I found out about hsc2hs and the current FFI support in ghc, and I noticed that according to http://www.haskell.org/greencard/ , the current version of Green Card is an alpha release from 2003. From comparison of the two, my impression is that this parrot is dead, and everyone is just too polite to say so. Unfortunately, this inability to pull the shades on Green Card, Haskell Direct, etc., takes away a little from ghc's outstanding FFI. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] standard poll/select interface
Hello John, Thursday, February 09, 2006, 3:19:30 AM, you wrote: JM If we had a good standard poll/select interface in System.IO then we JM actually could implement a lot of concurrency as a library with no JM (required) run-time overhead. I'd really like to see such a thing get JM into the standard. Well, mainly it would just be a really useful thing JM to have in general. If others think it is a good idea I can try to come JM up with a suitable API and submit it to the repo. i have delayed answering to this letter until i announced my Streams library. now i can say that such API already exists - in terms of my library you need just to write an transformer that intercepts vGetBuf/vPutBuf calls and pass them to the select/poll machinery. so you can write such transformer just now and every program that uses Streams will benefit from its usage. Converting programs that use Handles to using Streams should be also an easy task. JM I was actually asking for something much more modest, which was the JM routine needed to pass them to the select/poll machinery. but yeah, what JM you say is one of my expected uses of such a routine. Once a standard IO JM library settles down, then I can start working on the exact API such a JM routine would have. but if all will wait while the library settles down, it will never occur :) your work can change design of library, like the my library itself can change the shape of haskell' :) at this moment, i just developed the library which satisfy demands in extending current I/O library by new features, such as Unicode support, high speed, portability to other compilers, binary i/o, i/o for packed strings, and asynchronous i/o using methods other than select(). but i don't implement all these features actually, i just developed infrastructure, in which all these features can be easily added. unlike the System.IO library, you don't need to ask someone to implement new features or make corrections in foreign sources. you just need to develop module what implements this standard Stream interface and then it can be used as easy as transformers from the library itself as i understand this idea, transformer implementing async i/o should intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate async operation, and then switch to another Haskell threads. the I/O manager thread should run select() in cycle and when the request is finished, wake up the appropriate thread. what's all. if you will ever need, this implementation can then be used to extend GHC's System.IO internals with the support for new async i/o managers (as i understand, select() is now supported by GHC, but poll(), kqueue() is not supported?). the only difference that my lib gives an opportunity to test this implementation without modifying GHC I/O internals, what is somewhat simpler. so, interface for async vGetBuf/vPutBuf routines should be the same as for read/write: type FD = Int vGetBuf_async :: FD - Ptr a - Int - IO Int vPutBuf_async :: FD - Ptr a - Int - IO Int i think that implementations for ghc and jhc should be slightly different, though, because of different ways to implement multi-threading. but the I/O manager should be the same - it just receives info about I/O operations to run and returns information about completed ones. ... well, this I/O manager should implement just one operation: performIO :: Request - IO () type Request = (IOType, FD, Ptr a, Int, Notifier) data IOType = Read | Write | ... type Notifier = Result - IO () data Result = OK Int | Fail ErrorInfo performIO starts new I/O operation. On the completion of this operation, Notifier is called with information about results of execution. so, for the GHC the following should work: vGetBuf_async fd ptr size = do done - newMVar let notifier = putMVar done () performIO (Read, fd, ptr, size, notifier) takeMVar done for JHC, the body of vGetBuf_async may be different if you will find this interface reasonable, at least for the first iteration, i will develop appropriate transformer, so for you remains only the implementation of performIO of course, Streams library is not some standard just now, and moreover - it is not compatible with JHC. the greatest problem is what i using type classes extensions available in GHC/Hugs what is not in H98 standard. so, i'm interested in pushing Haskell' to accept most advanced possible extensions in this area and, of course, in actual implementing these extensions in the Haskell compilers. alternative way to make Streams available to wider range of Haskell compilers is to strip support of streams working in monads other that IO. JM Don't take the absence of a feature in jhc to mean I don't like or want JM that feature. There are a lot of things I don't have but that I'd JM definitly want to see in the language simply because I was only shooting JM for H98 to begin with and was more interested in a lot of the back end JM stuff. You should figure out
Re[2]: [Haskell-cafe] Emulating bash pipe/ process lib
Hello Donn, Thursday, February 09, 2006, 8:58:27 PM, you wrote: DC Slow devices like pipes, sockets etc. get along fine with Handles DC or whatever buffered I/O - as long as you have only one going at a time. DC Multiple input sources - like, say you want to read a process' output DC (unit 1) and diagnostic output (unit 2) separately, and either one has DC the potential to fill up the pipe and block while you're waiting for DC input on the other pipe - buffers at least complicate the dispatching DC mechanics you need for this, if not make it impossible. are you tried LineBuffering and NoBuffering? seem that it is developed exactly for this case (plus for terminals) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FFI Wiki Page (was: FFI question)
Bulat wrote: we need to establish FFI page on the wiki and give at least links to all this packages and small info about using FFI with ghc/hugs There is such a page (to be more precise, a section of a page): http://haskell.org/hawiki/LibrariesAndTools section FFI Preprocessors Also there are http://haskell.org/hawiki/FfiCookbook and http://haskell.org/hawiki/FfiTutorial pages. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Emulating bash pipe/ process lib
On Thu, 9 Feb 2006, Bulat Ziganshin wrote: Thursday, February 09, 2006, 8:58:27 PM, you wrote: DC Slow devices like pipes, sockets etc. get along fine with Handles DC or whatever buffered I/O - as long as you have only one going at a time. DC Multiple input sources - like, say you want to read a process' output DC (unit 1) and diagnostic output (unit 2) separately, and either one has DC the potential to fill up the pipe and block while you're waiting for DC input on the other pipe - buffers at least complicate the dispatching DC mechanics you need for this, if not make it impossible. are you tried LineBuffering and NoBuffering? seem that it is developed exactly for this case (plus for terminals) That's part of the idea, it helps keep the data out of buffers where select or whatever can't see it. But then you need functions with semantics that really support unbuffered I/O. When select tells you that the device is readable, you don't know that there is one full line, or how many bytes there are, so hGetLine doesn't apply here, nor would the Haskell equivalent of fread(3) if there were one. The only thing left is hGetChar - one char, then select, then another. (And multi-byte chars cause us to worry about this.) Since POSIX read(2) already supports exactly the functions you need for unbuffered I/O, it's simpler, easier and more efficient to leave the whole business right there at the file descriptor level. I'm sure you can make a non-buffering buffer layer work on top of the file descriptor, but what makes it worth the trouble? Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] standard poll/select interface
On 09.02 22:24, Bulat Ziganshin wrote: as i understand this idea, transformer implementing async i/o should intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate async operation, and then switch to another Haskell threads. the I/O manager thread should run select() in cycle and when the request is finished, wake up the appropriate thread. what's all. if you will ever need, this implementation can then be used to extend GHC's System.IO internals with the support for new async i/o managers (as i understand, select() is now supported by GHC, but poll(), kqueue() is not supported?). the only difference that my lib gives an opportunity to test this implementation without modifying GHC I/O internals, what is somewhat simpler. so, interface for async vGetBuf/vPutBuf routines should be the same as for read/write: type FD = Int vGetBuf_async :: FD - Ptr a - Int - IO Int vPutBuf_async :: FD - Ptr a - Int - IO Int Please don't fix FD = Int, this is not true on some systems, and when implementing efficient sockets one usually wants to hold more complex state. JM Don't take the absence of a feature in jhc to mean I don't like or want JM that feature. There are a lot of things I don't have but that I'd JM definitly want to see in the language simply because I was only shooting JM for H98 to begin with and was more interested in a lot of the back end JM stuff. You should figure out the nicest design that uses just the JM extensions needed for the design you want. it could help us decide what JM goes into haskell-prime to know what is absolutely needed for good JM design and what is just nice to have. this simply means that the Streams library cannot be used with JHC, what is bad news, because it is even more rich than GHC's System.IO. jhc had chance to get modern I/O library. but it lost that chance :) I think it is more like all haskell-prime programs. Seriously, if we design a new IO subsystem it would be quite nice to be able to use it from standard conforming programs. Maybe things can be reformulated in a way that will be compatible with haskell-prime. please look. at this moment Sreams library lacks only a few important features, already implemented in GHC's System.IO: sockets, line buffering and async i/o. moreover, i don't have an experience in implementing the async i/o, so foreign help is really necessary If you want I can look at getting network-alt to implement the interface. - Einar Karttunen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Language shootout (reloaded)
Just so we can feel that we're doing the right things :) On the great language shootout, as of last night, we're: * Ranked overall number 1, by a good margin: * Ranked number 1 on lines of code * Ranked number 2 on speed. http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=all Thanks to everyone who's contributed to the entries over the last few weeks, on the wiki, and on this list. Cheers, Don P.S. I remember having a discussion on #haskell 2 weeks ago where we all agreed that Haskell placing #1 was pretty much impossible. Did we have an inferiority complex? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Numerical methods in Haskell
Hello Creighton, Friday, February 10, 2006, 12:45:21 AM, you wrote: CH Between google searching and looking through the activity CH report, I take it that no one has really developed serious CH libraries for matrix manipulations, diff eqs, etc. it was a discussion and development in this direction, but seems that there is no ultimate result see for example june thread Re: [Haskell-cafe] matrix computations based on the GSL -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language shootout (reloaded)
Don Stewart wrote: P.S. I remember having a discussion on #haskell 2 weeks ago where we all agreed that Haskell placing #1 was pretty much impossible. Did we have an inferiority complex? Still---and, please, forgive me for this---I feel that us being #1 now tells us more about the Haskell community than it tells us about Haskell. Regards, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language shootout (reloaded)
On 10/02/06, Stefan Holdermans [EMAIL PROTECTED] wrote: Don Stewart wrote: P.S. I remember having a discussion on #haskell 2 weeks ago where we all agreed that Haskell placing #1 was pretty much impossible. Did we have an inferiority complex? Still---and, please, forgive me for this---I feel that us being #1 now tells us more about the Haskell community than it tells us about Haskell. The Haskell community is an important part of Haskell. :) - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
