Re: [Haskell-cafe] Matching constructors
On 10/02/06, Creighton Hogg <[EMAIL PROTECTED]> wrote:
> Hi,
> If I have something like
> data Patootie = Pa Int | Tootie Int
> and I want to pull out the indices of all elements of a list
> that have type constructor Tootie, how would I do that?
>
> I thought I might be able to use findIndices, but I don't
> know how to express the predicate.
Just to clear up a small point, Tootie isn't a type constructor, but a
data constructor. ('Maybe' is a type constructor, 'Just' is a data
constructor.)
You can use list comprehensions with pattern matching to write this
fairly succinctly:
tootieIndices xs = [i | (Tootie {}, i) <- zip xs [0..]]
The {} matches whatever parameters Tootie might have, so this will
continue to work even if you later extend the Tootie data constructor
with more fields. If you want to match more carefully, you can of
course put a variable there.
- Cale
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] question about type lambda and decidability of typechecking
For the record, a little more digging turned up this http://portal.acm.org/citation.cfm?id=583852.581496 which answers most of my questions. On Feb 10, 2006, at 2:02 PM, Robert Dockins wrote: OK. I've been doing a little thinking about type lambda in Haskell. Now, I understand the prevailing wisdom is that adding type lambda and/or partially applied type synonyms to the haskell type system would make type checking/inference undecidable. The reason given is that higher-order unification is undecidable. I have to admit that I don't fully understand this reason. Setting aside typeclasses for now, it seems to me that type expressions together with the kind system are just the simply-typed lambda calculus with unit, which is well known to be strong normalizing. So any type with kind * has a normal form with (by definition) no internal redexes. I think this is sufficient to guarantee that all type lambdas are removed. Now you can proceed using first-order unification, which is decidable. Of course, all valid expressions have kind * (ignoring unboxing and other trickiness for now). So where have I gone wrong? Do typeclasses complicate the matter? Or have I missed something more basic? Thanks, Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hashtable woes
On 2/10/06, Ketil Malde <[EMAIL PROTECTED]> wrote: > Hmm...perhaps it is worth it, then? The benchmark may specify "hash > table", but I think it is fair to interpret it as "associative data > structure" - after all, people are using "associative arrays" that > (presumably) don't guarantee a hash table underneath, and it can be > argued that Data.Map is the canonical way to achieve that in Haskell. Based on this advice, I wrote a k-nucleotide entry using the rough structure of the OCaml entry, but with the manual IO from Chris and Don's "Haskell #2" entry. It runs in under 4 seconds on my machine, more than ten times the speed of the fastest Data.HashTable entry. -- Brian T. Sniffen [EMAIL PROTECTED]or[EMAIL PROTECTED] http://www.evenmere.org/~bts ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: standard poll/select interface
On Fri, Feb 10, 2006 at 12:26:30PM +, Simon Marlow wrote: > in fact, I think this should be the basic API, since you can implement > readFD in terms of it. (readNonBlockingFD always reads at least one > byte, blocking until some data is available). This is used to partially > fill an input buffer with the available data, for example. this is the behavior of standard file descriptors. not non-blocking ones. We should definitly not guarentee reads fill an input buffer fully at least for the lowest level calls, that is the job for the layers on top of it. > > One problem here is that in order to implement readNonBlockingFD on Unix > you have to put the FD into O_NONBLOCK mode, which due to misdesign of > the Unix API affects other users of the same file descriptor, including > other programs. GHC suffers from this problem. non blocking ones will return immediatly if no data is available rather than make sure they return at least one byte. In any case, the correct solution in the circumstances is to provide a select/poll/epoll/devpoll interface. It is nicer than setting NON_BLOCKING and more efficient. This is largely orthogonal to the Streams design though. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re[2]: Streams: the extensible I/O library
Hello Simon, Wednesday, February 08, 2006, 2:58:30 PM, you wrote: SM> I would prefer to see more type structure, rather than putting SM> everything in the Stream class. You have classes ByteStream, SM> BlockStream etc, but these are just renamings of the Stream class. There SM> are many compositions that are illegal, but we don't find out until SM> runtime; it would make a lot more sense to me to expose this structure SM> in the type system. i initially used normal splitted classes (vGetBuf was in BlockStream) and so on, but come accross problems with the type classes system and decided to simplify the design. now i feel himself more confident with the classes, feel that i know source of my previous problems and therefore slowly migrate back to the splitted classes design. the library as published is just on the half of this way. but i know some limitations. that is the one problem: data BinHandle = forall h . (Stream IO h) => BinH h with such definition, i cannot use for BinHandles any operations that is aside of Stream interface. BinHandles, like in the NewBinary library, can be constructed from files or memory buffers, and memory buffers should support "saveToFile" operation. this operation require the "MemoryStream" interface, what implement by memory buffers, but not by files. in the old implementation, all operations was in the Stream interface, so i can implement "saveToFile" and this operation generated run-time error when used not with memory buffers. now it's inpossible to use it, i need to add second field of type (Maybe MemoryStream) the same problem will appear for all "forall h . Stream h" datatypes - if they need some operations from additional interfaces, then additional fields should be introduced, quantified by these interfaces moreover, splitting the Streams interface will require from the library users to give more classes in defining context for their functions, like the: process :: (Stream IO h, Seekable IO h, Buffered h) => h -> IO () that is not so good, especially if adding new interfaces means slowdown of calls to this function SM> My view is that the most basic level of stream is a byte stream, SM> supporting only two operations: read an array of bytes and write an SM> array of bytes, i.e. vGetBuf/vPutBuf. This makes implementing a stream, SM> or transformer, much easier and shorter. it is exact what is implemented, except for: there are two types of low-level streams. for memory-resident streams it is inefficient to work through getbuf/putbuf operations. MemoryStream interface impelements instead vReceiveBuf operation which just returns address and size of next data block in memory. accordingly, the buffering implementation slightly changes - it is the reason why i implemented FileBuffering.hs (working through GetBuf/PutBuf) and MemoryBuffering.hs (working through ReceiveBuf/SendBuf) moreover, there are third type of streams - based on the getchar/putchar or getbyte/putbyte operations. example of former is StringBuffer, later - UArray Int Word8 (not implemented, but possible in future) SM> Also I'd like to see separate SM> input/output streams for even more type safety, and I believe SM> simplicity, it will be great! but it is very uneasy and even seems impossible: 1) this will prevent dividing streams into the MemoryStream/BlockStream/ByteStream, what i like you consider as more important. it is impossible to say what InputStream BlockStream implements only vGetBuf, while OutputStream BlockStream implements only vPutBuf operation 2) such division will require to implement 2 or 3 (+ReadWrite) times more Stream types than now. Say, instead of FD we will get InputFD and OutputFD, instead of CharEncoding transformer - two transformers and so on. most of the functionality in Input and Ouput variants will be repeated (because this functionality don't depend on input/output mode) and in addition to the current large lists of passed calls like the: vIsEOF(WithEncoding h _) = vIsEOFh vMkIOError(WithEncoding h _) = vMkIOErrorh vReady(WithEncoding h _) = vReadyh vIsReadable (WithEncoding h _) = vIsReadable h we will get the same lists in 2 or 3 repetitions!!! 3) i don't think that we can completely throw away the r/w streams, they can be required for example for database-style access. and if we need to implement this type of streams, our win in separating implementations of Input and Output streams will become a loss moreover, difference between input and output streams are well-known and errors in this area can be easily spotted by the users. so i think that such division would be great, but it requires too much work and will essentially compilcate the library. when the Haskell class system will be essenially improved, it will have sense. differences between MemoryStream, ByteStream and so on is not so obvious (because it's specific to this library), so dividing them should help users to spot error
Re: [Haskell-cafe] Numerical methods in Haskell
Hello, If you are working on finance type stuff, you may be interested in my Decimal library: http://article.gmane.org/gmane.comp.lang.haskell.cafe/8734 I think my 'last even' rounding algorithm is broken because I misread the spec -- so be warned: hunk ./Decimal/Operations.hs 78 -| roundHint == RoundOneHalf && (lastIsEven d) = (Decimal s (coef + 1) exp) +| roundHint == RoundOneHalf && (lastIsEven d) = (Decimal s (coef + 1) exp) -- FIXME: this may be wrong, see pep327 Jeremy Shaw At Fri, 10 Feb 2006 14:09:23 -0500, Rob Tougher wrote: > > I'm currently working on a mathematics library in Haskell. I'm not a > mathematician -- I'm basically writing this library as an excuse to > learn mathematics and Haskell at the same time. > > Feel free to check out the code: > >http://robtougher.com/ > > My main focus is financial mathematics (options pricing, etc), but I took > a detour last week and implemented basic matrix stuff. I might work on > some Linear Programming algorithms (simplex, interior point) before > returning to finance. > > - Rob > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re[2]: Emulating bash pipe/ process lib
Hello Simon, Friday, February 10, 2006, 2:53:25 PM, you wrote: i'm not very interested to do something fascinating in this area. it seems that it is enough to do 1) non-blocking read of the entire buffer on input 2) flush buffer at each '\n' at output that should be enough to implement LineBuffering for everyone except purists? and for the NoBuffering the same except for flushing after each output operation? 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) >> >> >> DC> That's part of the idea, it helps keep the data out of buffers where >> DC> select or whatever can't see it. >> >> DC> But then you need functions with semantics that really support unbuffered >> DC> I/O. When select tells you that the device is readable, you don't know >> DC> that there is one full line, or how many bytes there are, so hGetLine >> DC> doesn't apply here, nor would the Haskell equivalent of fread(3) if there >> DC> were one. The only thing left is hGetChar - one char, then select, then >> DC> another. (And multi-byte chars cause us to worry about this.) >> >> when i think how to implementat LineBuffering, i decided that it is >> the only possible way - read byte a time and see for a '\n'. i don't >> know how System.IO implemented but i think that it should do the same SM> Read as much as you can into the buffer without blocking. Line SM> buffering on input is actually implemented exactly the same as block SM> buffering. SM> You might argue that strictly speaking this isn't line buffering, since SM> you can get data from the Handle before the end of line is available. SM> That's true, but I'd argue this is more useful. In fact, we changed SM> block buffering on input handles so that the input buffer doesn't have SM> to be completely full before data can be returned, which is also not SM> strict block buffering, but seems more useful. SM> I suppose conceivably you might want to force a read buffer to be SM> completely full so that you could guarantee to read it all without SM> blocking, but in that case you might as well use hGetBuf & peekArray. SM> Similarly you might want to ensure the buffer contains a complete line SM> before starting to read it, but can use hGetLine anyway. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re[2]: standard poll/select interface
Hello Simon, Friday, February 10, 2006, 3:26:30 PM, you wrote: as i understand this idea, transformer implementing async i/o should intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate type FD = Int vGetBuf_async :: FD -> Ptr a -> Int -> IO Int vPutBuf_async :: FD -> Ptr a -> Int -> IO Int >> >> >> EK> Please don't fix FD = Int, this is not true on some systems, >> EK> and when implementing efficient sockets one usually wants >> EK> to hold more complex state. >> >> the heart of the library is class Stream. both "File" and "Socket" >> should implement this interface. just now i use plain "FD" to >> represent files, but that is temporary solution - really file also >> must carry additional information: filename, open mode, open/closed >> state. This "File" will be an abstract datatype, what can be based not >> on FD in other operating systems. >> >> The same applies to the "Socket". it can be any type what carry enough >> information to work with network i/o. >> >> implementation of async i/o should have a form of Stream Transformer, >> which intercepts only the vGetBuf/vPutBuf operations and pass other >> operations as is: SM> I don't think async I/O is a stream transformer, fitting it into the SM> stream hierarchy seems artificial to me. yes, it is possible - what i'm trying to implement everything as tranformer, independent of real necessity. i really thinks that idea of transformers fit every need in extending functionality it is a list of my reasons to implement this as transformer: 1) there is no "common FD" interface. module System.FD implements something, but it is a really interface only for file i/o. it's used partially in System.MMFile, implementing memory-mapped files, and i think these fd* operations will be used to partially implement Socket operations, but something will be different, including using recv/send instead of read/write to implement GetBuf/PutBuf operations. so, there is no common "instance Stream FD", but different instances for files, memory-mapped files and sockets. As Einar just mentioned, Socket dataype will include information what absent in File datatype. So, these 3 types have in common using FD to implement some of its operations, but some operations will be different and internal dataype structures will be different. Transformer is an ideal way to just reimplement vGetBuf/vPutBuf operations while passing through all the rest. Without it, instead of 3 methods of doing I/O (mmap/read/recv) you will need to implement all the 5 (mmap/read/recv/readAsync/recvAsync) - it's even without counting selct, epoll and kqueue separately 2) as you can see in epoll()-based implementation of async i/o in alt-network library, Einar attaches additional data (read/write queues) to the FD to support epoll() interface. These data will be different for select, epoll, kqueue and other methods of async i/o. At least, without async i/o no information should be needed. Transformer is an ideal way to attach additional data to the file/socket without changing of "raw" datatype. Again, otherwise you will need to attach all these data to the raw file, duplicate this work with the raw socket and then repeat this for select, epoll and other async i/o methods on the other side, reasons for your proposal, as i see: 1) if FD will incorporate async i/o support, the System.FD library will become much more useful - anyone using low-level fd* functions will get async i/o support for free but there is another defeciency in the System.FD library - it doesn't include support for the files>4Gb and files with unicode filenames under Windows. it seems natural to include this support in fd* too. now let's see. you are proposing to include in fd* implementation support for files, sockets, various async i/o methods and what's not all. are you not think that this library will become a successor of Handle library, implementing all possible fucntionality and don't giving 3rd-party libraries chances to change anything partially? i propose instead to divide library into the small manageable pieces what can be easily stidied/modified/replaced and that brings something really usefull only when used together. if what means that low-level fd* interface can't be used even to work with raw files without great restrictions (no Unicode filenames in windows, no async i/o) then it will mean just this. SM> It is just another way of doing I/O directly to/from file descriptors. SM> If your basic operation to read from an FD is SM>readFD :: FD -> Int -> Ptr Word8 -> IO Int SM> then an async I/O layer simply provides you with the exact same SM> interface, but with an implementation that doesn't block other threads. SM> It is part of the file descriptor interface, not a stream transformer. SM> Also, you probably need SM>readNonBlockingFD :: FD -> Int -> Ptr Word8 -> IO Int SM>isReadyFD :: FD -> IO Bool SM> in fact, I think this should be the basic API, since
[Haskell-cafe] Numerical methods in Haskell
I'm currently working on a mathematics library in Haskell. I'm not a mathematician -- I'm basically writing this library as an excuse to learn mathematics and Haskell at the same time. Feel free to check out the code: http://robtougher.com/ My main focus is financial mathematics (options pricing, etc), but I took a detour last week and implemented basic matrix stuff. I might work on some Linear Programming algorithms (simplex, interior point) before returning to finance. - Rob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] question about type lambda and decidability of typechecking
OK. I've been doing a little thinking about type lambda in Haskell. Now, I understand the prevailing wisdom is that adding type lambda and/or partially applied type synonyms to the haskell type system would make type checking/inference undecidable. The reason given is that higher-order unification is undecidable. I have to admit that I don't fully understand this reason. Setting aside typeclasses for now, it seems to me that type expressions together with the kind system are just the simply-typed lambda calculus with unit, which is well known to be strong normalizing. So any type with kind * has a normal form with (by definition) no internal redexes. I think this is sufficient to guarantee that all type lambdas are removed. Now you can proceed using first-order unification, which is decidable. Of course, all valid expressions have kind * (ignoring unboxing and other trickiness for now). So where have I gone wrong? Do typeclasses complicate the matter? Or have I missed something more basic? Thanks, Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Matching constructors
Creighton Hogg <[EMAIL PROTECTED]> writes: > data Patootie = Pa Int | Tootie Int > and I want to pull out the indices of all elements of a list > that have type constructor Tootie, how would I do that? x = [Pa 3, Tootie 5, Pa 7, Tootie 9, Pa 11] y = [ i |Tootie i <- x ] z = [ i | i@(Tootie _) <- x ] y or z might be helpful. -- Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] multiple defentions of .. fst defined here errors.
Why do these error occur? After hiding the packages com (beeing in comlib) and hdirect (beeing in lib) and adding -package com -package hdirect it works fine. I haven't tried without hiding but adding -package options yet. ghc --make -H16m -O -fglasgow-exts -syslib com -fno-warn-missing-methods daotest.hs Chasing modules from: daotest.hs Skipping DAO ( ./DAO.hs, ./DAO.o ) Skipping DB ( ./DB.hs, ./DB.o ) Skipping Main ( daotest.hs, daotest.o ) Linking ... c:\haskell\myfptoolsdirectory\fptools\hdirect\comlib/libHScom.a(PointerPrim.o)(.text+0x696):ghc2648.hc: multiple definition of `__stginit_PointerPrim_' c:\haskell\myfptoolsdirectory\fptools\hdirect\lib/libHShdirect.a(PointerPrim__12.o)(.text+0x0):ghc2036.hc: first defined here c:\haskell\myfptoolsdirectory\fptools\hdirect\comlib/libHScom.a(PointerPrim.o)(.text+0x6da):ghc2648.hc: multiple definition of `__stginit_PointerPrim' c:\haskell\myfptoolsdirectory\fptools\hdirect\lib/libHShdirect.a(PointerPrim__12.o)(.text+0x44):ghc2036.hc: first defined here Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[3]: [Haskell-cafe] Emulating bash pipe/ process lib
On Fri, 10 Feb 2006, Bulat Ziganshin wrote: ... > when i think how to implementat LineBuffering, i decided that it is > the only possible way - read byte a time and see for a '\n'. i don't > know how System.IO implemented but i think that it should do the same Don't know - I see that Simon M followed up with an explanation that I think confirms my impression that LineBuffering is indistinguishable from BlockBuffering, for input. I assume it's only there for the sake of output, where it does make a difference. Only NoBuffering is interoperable with select. > DC> Since POSIX read(2) already supports exactly the functions you need for > DC> unbuffered I/O, it's simpler, easier and more efficient to leave the whole > DC> business right there at the file descriptor level. > > can you please describe that read(2) does that is better than reading > char-at-a-time? It returns whatever available data, as long as it's more than 0 bytes and less than the caller-supplied limit. This is the only read operation that works with select (including char-at-a-time, as a special case where the caller-supplied limit is 1.) > DC> I'm sure you can make > DC> a non-buffering buffer layer work on top of the file descriptor, but what > DC> makes it worth the trouble? > > if you don't have I/O library that implements what you need, it is > indeed simpler to use lower I/O directly. if you have I/O library that > does that you need, it is easier to write: > > (hIn, hOut) <- createUnixPipe > vPutStrLn hOut "hello" > s <- vGetLine hIn > > i'm writing such lib now, so i'm interested to know what i need to > do so that it will work ok. It won't! I mean, we can use it the same way as the ordinary Handle in the original example, but we know in principle, if you call vGetLine, it may block regardless of whether select reports input data, because select can't tell you whether there's a full line of input. So you don't have anything to worry about here - this is not your problem. I only wanted to point out that for select-based I/O event multiplexing, we will continue to need file descriptors and system level POSIX I/O, and that the need for this can occur in such ordinary, mundane applications as reading stdout and stderr in parallel. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Associated Type Synonyms question
On Fri, Feb 10, 2006 at 05:20:47PM +0100, Niklas Broberg wrote: > - when looking at the definition of MonadWriter the Monoid constraint > is not strictly necessary, and none of the other mtl monads have > anything similar. Is it the assumption that this kind of constraint is > never really necessary, and thus no support for it is needed for ATS? I think that's right -- it's only needed for the Monad instance for WriterT. But it is a convenience. In any instance of MonadWriter, the w will be a monoid, as there'll be a WriterT in the stack somewhere, so the Monoid constraint just saves people writing general functions with MonadWriter from having to add it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Matching constructors
Or inline as > findIndices (\x -> case x of Tootie _ -> True; _ -> False) listOfPasAndTooties There was a recent thread about wanting a more succint way to write this (unary pattern matching): http://thread.gmane.org/gmane.comp.lang.haskell.cafe/11109 If John got his wish, then you could write something like > findIndices (@ Tootie _) listOfPasAndTooties Maybe this feature will appear in a future Haskell standard? though I don't see anything on the Haskell' wiki about this... Cheers Jared. -- http://www.updike.org/~jared/ reverse ")-:" ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Matching constructors
On Fri, 10 Feb 2006, Creighton Hogg wrote:
> Hi,
> If I have something like
> data Patootie = Pa Int | Tootie Int
> and I want to pull out the indices of all elements of a list
> that have type constructor Tootie, how would I do that?
>
> I thought I might be able to use findIndices, but I don't
> know how to express the predicate.
(\p -> case p of {Pa _ -> False; Tootie _ -> True})
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Matching constructors
tootieIndices = findIndices isTootie where isTootie (Pa _) = False isTootie (Tootie _) = True would be my first approach. /g On 2/10/06, Creighton Hogg <[EMAIL PROTECTED]> wrote: > Hi, > If I have something like > data Patootie = Pa Int | Tootie Int > and I want to pull out the indices of all elements of a list > that have type constructor Tootie, how would I do that? > > I thought I might be able to use findIndices, but I don't > know how to express the predicate. > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- We have lingered in the chambers of the sea By sea-girls wreathed with seaweed red and brown Till human voices wake us, and we drown. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Combinatory logic interpreter?
On Feb 10, 2006, at 11:09 AM, Colin Paul Adams wrote: Is there any Haskell code around that can interpret combinatory logic expressions? Humm. That's kind of a broad question. I've written a shell for interpreting the pure untyped lambda calculus which has definitions for Turner's Combinators. You can get the darcs repo here: http://www.eecs.tufts.edu/~rdocki01/lambda/ you will also need http://www.eecs.tufts.edu/~rdocki01/shell/ http://www.eecs.tufts.edu/~rdocki01/shell-readline/ Or... you can play with it on the haskell IRC channel by using the '@lam' lambdabot command. Its hard to know if this will meet your needs without knowing more. What are you trying to do? Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Associated Type Synonyms question
Hi, I'm playing around with associated type synonyms (ATS) [1] and the PHRaC interpreter, trying to model existing uses of FDs. I really enjoy working with ATS, but I've come across a situation that I don't quite know how to handle, or indeed if it can be handled at all. The scene is Control.Monad.Writer from mtl, where we can find the following definition (simplified for presentation): class (Monoid w, Monad m) => MonadWriter m w | m -> w where tell :: w -> m () The class MonadWriter has two type parameters, one for the monad itself and the other for that which is written. The Monoid constraint on the output is (I guess) there only as a documentation of sorts, stating that the intention is that the output of subsequent tell's should be combinable using mplus. A simple custom monad that just does output could be written as: data MyWriterM w a = MyWriterM (a, [w]) instance Monad (MyWriterM w) where return x = MyWriterM (x, []) MyWriterM (a, xs) >>= k = let MyWriterM (b, xs') = k a in MyWriterM (b, xs ++ xs') instance MonadWriter (MyWriterM w) w where tell x = MyWriterM ((), [x]) Now, to model this using ATS we would write, ignoring the Monoid constraint, the following class declaration*: class Monad m => MonadWriter m where type Output m tell :: Output m -> m () instance MonadWriter (MyWriterM w) where type Output m = [w] tell x = MyWriterM ((), [x]) This works fine, but the obvious question is then, where to put back the Monoid restriction? This time we want the type Output m to be constrained, so my naive first guess was to write: class (Monad m, Monoid (Output m)) => MonadWriter m where .. but phrac says "illegal context for class MonadWriter: only type variables can be constrained". I can't really think of anywhere else to put the restriction, other than making up an ad hoc class constraint syntax for associated types like class Monad m => MonadWriter m where type (Monoid) Output m ... My first question is already stated: where do I put the Monoid constraint? But since I suspect the answer is "you don't", a number of followup questions spring to mind: - why not? Apart from possibly having to use some ugly syntax for it, are there any fundamental reasons why this should not be allowed? - when looking at the definition of MonadWriter the Monoid constraint is not strictly necessary, and none of the other mtl monads have anything similar. Is it the assumption that this kind of constraint is never really necessary, and thus no support for it is needed for ATS? Hope someone can shed some light on this matter :-) Regards, /Niklas [1] http://www.cse.unsw.edu.au/~chak/papers/CKP05.html * Using Haskell syntax instead of the PHRaC equivalent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Combinatory logic interpreter?
On Fri, 10 Feb 2006, Colin Paul Adams wrote: > Is there any Haskell code around that can interpret combinatory logic > expressions? http://www0.us.ioccc.org/1998/fanf.lambda Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Matching constructors
Hi, If I have something like data Patootie = Pa Int | Tootie Int and I want to pull out the indices of all elements of a list that have type constructor Tootie, how would I do that? I thought I might be able to use findIndices, but I don't know how to express the predicate. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Combinatory logic interpreter?
Is there any Haskell code around that can interpret combinatory logic expressions? -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language shootout (reloaded)
On Fri, 10 Feb 2006, Cale Gibbard wrote: > 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. :) Is it part of the Haskell 98 report? :-] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Numerical methods in Haskell
Actually I was starting to develop a matrix library, but then I found someone beat me to it... which is nice of course because you can move straight on to using it... http://dis.um.es/~alberto/hmatrix/matrix.html It uses the GSL which can use an optimized cblas library for even faster computation. Regards, Keean. Simon Peyton-Jones wrote: | Between google searching and looking through the activity | report, I take it that no one has really developed serious | libraries for matrix manipulations, diff eqs, etc. | | Are there any practical reasons for this or is it just a | matter of the haskell community being small and there not | being many people interested in something so specialized? The latter I think, but it's just the sort of thing that a functional language should be good at. Two other difficulties (a) It's hard to compete with existing libraries. The obvious thing is not to compete; instead, just call them. But somehow that doesn't seem to be as motivating. Perhaps some bindings exist though? (b) A concern about efficiency, because numerical computation is typically an area where people really care about how many instructions you take. It's a legitimate concern, but I don't think that it'll turn out to be justified. With unboxed arrays, and/or calling external libraries for the inner loops -- and the potential for aggressive fusion and/or parallelism, there is plenty of upward potential. I also want to work on nested data parallelism (a la NESL, and NEPAL) which fits right in here. I'd love to see a little community of matrix manipulators spinning up. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not usally faster
Chris Kuklewicz <[EMAIL PROTECTED]> writes: > Comparing Haskell to OCaml, Haskell is almost always slower. ...but generally not by much. And for another perspective on speed: Haskell loses tremendously in the knucleotide benchmark. As I mentioned previously, even TCL beats us by a margin of two, and it seems to be the comparatiely worst-performing benchmark regardless of language I compare to. Current GHC score is 4.6% ahead of GCC, weigting knucleotide to 0 gives us a 13% lead. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not usally faster
Stefan Holdermans 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. > > Regards, > > Stefan Point taken. But I think it *has* revealed a lot about Haskell: (1) "The language of Haskell" : It proved that Haskell's syntax allows for a good lead in the lines of code benchmark. If you ignore the 5 benchmarks without a Perl entry, then Haskell still wins and Perl is second. More concise than Perl is something that most people would consider to be non-trivial. (2) "The implementation of GHC 6.4.1": It proved the GHC runtime system is incredibly efficient at concurrency. It proved GHC can beat GCC in some cases. It proved that the memory consumption of lazy+strict Haskell is competitive with explicitly managed memory in c++ (g++) and strict but garbage collected OCaml. (3) "The libraries of GHC 6.4.1": It has emphasized which bits of GHC has to be worked around, where the provided library is simply too inefficient. This is usually not new information, but it does provide an (more) objective benchmark. And now for some perspective on speed: Comparing Haskell to OCaml, Haskell is almost always slower. For CPU time Haskell wins on 5, OCaml wins on 13 benchmarks (OCaml is missing 1 program). But for two of those 5, the thread benchmarks, Haskell is 107x and 129x faster. This amazingly large margin skews the ranking. Aside from threading, OCaml wins on 13 vs 3 for Haskell. Ignoring the these two threaded benchmarks, OCaml is 3rd behind C and D, while Haskell is 8th behind SML MLton. So is Haskell the fastest? No, not unless you need to do an amazing amount threaded processing. Actually, comparing Haskell to C shows C/gcc faster on 10 to 6 with Haskell/GHC faster (C is missing 3 programs). -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Language shootout (reloaded)
Bulat Ziganshin wrote: Hello Immanuel, Friday, February 10, 2006, 12:42:41 PM, you wrote: 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. IL> How to optimize Haskell code: IL> 1) enter it as a test in the great language shootout. IL> 2) wait a few days. IL> 3) download optimized code. someone can develop optimizing compiler implementing this algorithm :))) This is similar to an old algorithm: 1) Submit your program to the GHC team for inclusion in nofib 2) Wait for the next GHC release this algorithm has been little used of late, though. I should really incorporate all the shootout programs into nofib, in fact. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Language shootout (reloaded)
Hello Immanuel, Friday, February 10, 2006, 12:42:41 PM, you wrote: >> 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. >> IL> How to optimize Haskell code: IL> 1) enter it as a test in the great language shootout. IL> 2) wait a few days. IL> 3) download optimized code. someone can develop optimizing compiler implementing this algorithm :))) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: standard poll/select interface
Bulat Ziganshin wrote: Hello Einar, Friday, February 10, 2006, 2:09:08 AM, you wrote: as i understand this idea, transformer implementing async i/o should intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate type FD = Int vGetBuf_async :: FD -> Ptr a -> Int -> IO Int vPutBuf_async :: FD -> Ptr a -> Int -> IO Int EK> Please don't fix FD = Int, this is not true on some systems, EK> and when implementing efficient sockets one usually wants EK> to hold more complex state. the heart of the library is class Stream. both "File" and "Socket" should implement this interface. just now i use plain "FD" to represent files, but that is temporary solution - really file also must carry additional information: filename, open mode, open/closed state. This "File" will be an abstract datatype, what can be based not on FD in other operating systems. The same applies to the "Socket". it can be any type what carry enough information to work with network i/o. implementation of async i/o should have a form of Stream Transformer, which intercepts only the vGetBuf/vPutBuf operations and pass other operations as is: I don't think async I/O is a stream transformer, fitting it into the stream hierarchy seems artificial to me. It is just another way of doing I/O directly to/from file descriptors. If your basic operation to read from an FD is readFD :: FD -> Int -> Ptr Word8 -> IO Int then an async I/O layer simply provides you with the exact same interface, but with an implementation that doesn't block other threads. It is part of the file descriptor interface, not a stream transformer. Also, you probably need readNonBlockingFD :: FD -> Int -> Ptr Word8 -> IO Int isReadyFD :: FD -> IO Bool in fact, I think this should be the basic API, since you can implement readFD in terms of it. (readNonBlockingFD always reads at least one byte, blocking until some data is available). This is used to partially fill an input buffer with the available data, for example. One problem here is that in order to implement readNonBlockingFD on Unix you have to put the FD into O_NONBLOCK mode, which due to misdesign of the Unix API affects other users of the same file descriptor, including other programs. GHC suffers from this problem. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Numerical methods in Haskell
On Fri, 10 Feb 2006, Simon Peyton-Jones wrote: > | Between google searching and looking through the activity > | report, I take it that no one has really developed serious > | libraries for matrix manipulations, diff eqs, etc. > | > | Are there any practical reasons for this or is it just a > | matter of the haskell community being small and there not > | being many people interested in something so specialized? > > The latter I think, but it's just the sort of thing that a functional > language should be good at. Yes, I think lazy functional languages are great for this job! Languages of which other kind can represent power series and (infinite) sequences so easily? > (a) It's hard to compete with existing libraries. The obvious thing is > not to compete; instead, just call them. But somehow that doesn't seem > to be as motivating. Perhaps some bindings exist though? I collected the efforts of matrix libraries seen so far: http://www.haskell.org/hawiki/LinearAlgebra > I'd love to see a little community of matrix manipulators spinning up. Here, here, here! :-) I wrote some little, really very basic modules for me for numerical integration, solving differential equations, approximation with Newton's method and Co., power series manipulation, wrapping GNUPlot for display of numerical data. Due to increasing interest I could make the repository public, but I can't guarantee for a stable interface. Jerzy Karczmarczuk gives a fine overview over how functional lazy languages assist solving mathematical problems: http://www.haskell.org/pipermail/haskell-cafe/2004-May/006197.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Emulating bash pipe/ process lib
Bulat Ziganshin wrote: Hello Donn, Friday, February 10, 2006, 12:47:42 AM, 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) DC> That's part of the idea, it helps keep the data out of buffers where DC> select or whatever can't see it. DC> But then you need functions with semantics that really support unbuffered DC> I/O. When select tells you that the device is readable, you don't know DC> that there is one full line, or how many bytes there are, so hGetLine DC> doesn't apply here, nor would the Haskell equivalent of fread(3) if there DC> were one. The only thing left is hGetChar - one char, then select, then DC> another. (And multi-byte chars cause us to worry about this.) when i think how to implementat LineBuffering, i decided that it is the only possible way - read byte a time and see for a '\n'. i don't know how System.IO implemented but i think that it should do the same Read as much as you can into the buffer without blocking. Line buffering on input is actually implemented exactly the same as block buffering. You might argue that strictly speaking this isn't line buffering, since you can get data from the Handle before the end of line is available. That's true, but I'd argue this is more useful. In fact, we changed block buffering on input handles so that the input buffer doesn't have to be completely full before data can be returned, which is also not strict block buffering, but seems more useful. I suppose conceivably you might want to force a read buffer to be completely full so that you could guarantee to read it all without blocking, but in that case you might as well use hGetBuf & peekArray. Similarly you might want to ensure the buffer contains a complete line before starting to read it, but can use hGetLine anyway. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] standard poll/select interface
Hello Bulat, Thursday, February 09, 2006, 10:24:59 PM, you wrote: >>> if you can make select/poll transformer, at least for testing >>> purposes, that will be really great. JM>> Yeah, I will look into this. the basic select/poll call will have to be JM>> pretty low level, but hopefully it will allow interesting higher level JM>> constructs based on your streams or an evolution of them. sorry, John, as i now see, Einar already implemented select/epoll machinery in the alt-network lib. moreover, now he promised to extract this functionality to make universal async i/o layer library. the only thing that i don't know - whether he is ready to develop universal API for these modules, as you initially proposed. as this universal API will be done, i will roll up the Stream transormer that uses it and therefore allows async i/o both with files and sockets on any platform where this API can be implemented -- 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)
"Stefan Holdermans" <[EMAIL PROTECTED]> writes: > > 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. > How to optimize Haskell code: 1) enter it as a test in the great language shootout. 2) wait a few days. 3) download optimized code. Immanuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hashtable woes
> indicates that it triggers a bug in 6.4.1 Ah, I missed that. For my word counting indexes, I've settled on Data.Map, calculating an Int or Integer hash for each word (depending on word length, which is fixed). I haven't given it nearly the effort the shootout programs have seen, though, so I'm not sure how optimal it is. Other experiences with FiniteMap/Data.Map etc seem to indicate that they are in the same ball park as Python's hashes. > We never pounded on Data.Map, but I suspect it cannot be as bad as > Data.Hashtable. Hmm...perhaps it is worth it, then? The benchmark may specify "hash table", but I think it is fair to interpret it as "associative data structure" - after all, people are using "associative arrays" that (presumably) don't guarantee a hash table underneath, and it can be argued that Data.Map is the canonical way to achieve that in Haskell. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hashtable woes
Ketil Malde wrote: > Chris Kuklewicz <[EMAIL PROTECTED]> writes: > >> Is Jan-Willem Maessen's Hash available anywhere? I could benchmark it. > > Did you ever get around to run the benchmark? I browsed around a bit, > and found that the knucleotide is probably the worst GHC benchmark in > the shootout (even TCL beats GHC by a factor of two!) - which is > disheartening, because I rely a lot on associative data structures > (usually Data.Map) in my programs. > > Or have Adrian Hey's AVL-trees been tried? > > -k No, I did not try it. This message from Simon Marlow > Jan-Willem's HashTable attached. It uses unsafeThaw/unsafeFreeze tricks > to avoid the GC overheads, for this you need an up to date GHC due to a > bug in the garbage collector: grab a STABLE snapshot (6.4.1 won't work). > Or remove the unsafeThaw/unsafeFreeze to use it with 6.4.1, and be > prepared to bump the heap size. > > In GHC 6.6 the unsafeThaw/unsafeFreeze tricks aren't required, because > the GC is essentially doing it for you - we put a write barrier in the > IOArray implementation. indicates that it triggers a bug in 6.4.1, which is what the shootout is using. And I suspected bumping the heap size just won't cut it for the amount of data we are processing. But I did not test that suspicion. We never pounded on Data.Map, but I suspect it cannot be as bad as Data.Hashtable. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Numerical methods in Haskell
| Between google searching and looking through the activity | report, I take it that no one has really developed serious | libraries for matrix manipulations, diff eqs, etc. | | Are there any practical reasons for this or is it just a | matter of the haskell community being small and there not | being many people interested in something so specialized? The latter I think, but it's just the sort of thing that a functional language should be good at. Two other difficulties (a) It's hard to compete with existing libraries. The obvious thing is not to compete; instead, just call them. But somehow that doesn't seem to be as motivating. Perhaps some bindings exist though? (b) A concern about efficiency, because numerical computation is typically an area where people really care about how many instructions you take. It's a legitimate concern, but I don't think that it'll turn out to be justified. With unboxed arrays, and/or calling external libraries for the inner loops -- and the potential for aggressive fusion and/or parallelism, there is plenty of upward potential. I also want to work on nested data parallelism (a la NESL, and NEPAL) which fits right in here. I'd love to see a little community of matrix manipulators spinning up. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Language shootout (reloaded)
Congratulations, guys! An amazing, and (maybe it should have been!) to me surprising, achievement. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Donald Bruce Stewart | Sent: 10 February 2006 01:35 | To: haskell-cafe@haskell.org | Subject: [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=all&lang=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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Betreft: Re: [Haskell-cafe] Elementary HaXml question
> Ah, I see. In the first case, you simply change the tag into > , keeping the tag exactly the same. But in the second case, > you not only want to change into , but also to move the > tag from outside the to inside. Not exactly. In the end I want to turn both tags into one : Hello World and Hello World should both become Hello World The second case works now (cf. my previous post). still appears, but I guess I can deal with that by refining the filters. The current problem is that I can 'find' in but not in , which puzzles me. Regards, Koen. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] standard poll/select interface
Hello Einar,
Friday, February 10, 2006, 2:09:08 AM, you wrote:
>> as i understand this idea, transformer implementing async i/o should
>> intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate
>>
>> type FD = Int
>> vGetBuf_async :: FD -> Ptr a -> Int -> IO Int
>> vPutBuf_async :: FD -> Ptr a -> Int -> IO Int
EK> Please don't fix FD = Int, this is not true on some systems,
EK> and when implementing efficient sockets one usually wants
EK> to hold more complex state.
the heart of the library is class Stream. both "File" and "Socket"
should implement this interface. just now i use plain "FD" to
represent files, but that is temporary solution - really file also
must carry additional information: filename, open mode, open/closed
state. This "File" will be an abstract datatype, what can be based not
on FD in other operating systems.
The same applies to the "Socket". it can be any type what carry enough
information to work with network i/o.
implementation of async i/o should have a form of Stream Transformer,
which intercepts only the vGetBuf/vPutBuf operations and pass other
operations as is:
data AsyncFD = AsyncFD FD ... {-additional fields-}
instance Stream IO AsyncFD where
vIsEOF (AsyncFD h ...) = vIsEOF h
vClose (AsyncFD h ...) = vClose h
vGetBuf (AsyncFD h ...) ptr size = vGetBuf_async h ptr size
as far as i see, the select/epoll don't need to know anything about
file/socket except for its descriptor(FD) ? in this case we can make
the Async transformer universal, compatible with both files and
sockets:
data Async h = Async h ... {-additional fields-}
addAsyncIO h = do
.
return (Async h ...)
instance (Stream IO h) => Stream IO (Async h) where
vIsEOF (Async h ...) = vIsEOF h
vClose (Async h ...) = vClose h
vGetBuf (Async h ...) ptr size = doBlockingOp "read" h $ vGetBuf h ptr size
this transformer can be made universal, supporting select/epoll/...
implementations via additional parameter to the "addAsyncIO", or it
can be a series of transformers, one for each method of async i/o. if
we have developed common API for async i/o as John suggested, then one
universal transformer working via this API can be used
>> 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 :)
EK> I think it is more like "all haskell-prime programs". Seriously,
EK> if we design a new IO subsystem it would be quite nice to be
EK> able to use it from standard conforming programs.
EK> Maybe things can be reformulated in a way that will be compatible
EK> with haskell-prime.
or haskell-prime can be reformulated ;) as h' will be defined in
first iteration, i will check my lib and say to comittee what i will
need to omit from my library to be compatible with this standard.
then we can decide :) just at current moment, support for complex
class hierrachies outside of Hugs/GHC is very poor
>> 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
EK> If you want I can look at getting network-alt to implement the
EK> interface.
please look. basically, Sock should be made an instance of Stream with
implementations of vGetBuf/vPutBuf and other operations, as much as possible.
it should be easy, see the FD/Handle instances of Stream for example
and your support of select/poll should go into the tranformer(s). this
will allow to use async i/o not only for your own Sock type, but for
files, for the sockets from the old library and so on
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[3]: [Haskell-cafe] Emulating bash pipe/ process lib
Hello Donn, Friday, February 10, 2006, 12:47:42 AM, 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) DC> That's part of the idea, it helps keep the data out of buffers where DC> select or whatever can't see it. DC> But then you need functions with semantics that really support unbuffered DC> I/O. When select tells you that the device is readable, you don't know DC> that there is one full line, or how many bytes there are, so hGetLine DC> doesn't apply here, nor would the Haskell equivalent of fread(3) if there DC> were one. The only thing left is hGetChar - one char, then select, then DC> another. (And multi-byte chars cause us to worry about this.) when i think how to implementat LineBuffering, i decided that it is the only possible way - read byte a time and see for a '\n'. i don't know how System.IO implemented but i think that it should do the same DC> Since POSIX read(2) already supports exactly the functions you need for DC> unbuffered I/O, it's simpler, easier and more efficient to leave the whole DC> business right there at the file descriptor level. can you please describe that read(2) does that is better than reading char-at-a-time? DC> I'm sure you can make DC> a non-buffering buffer layer work on top of the file descriptor, but what DC> makes it worth the trouble? if you don't have I/O library that implements what you need, it is indeed simpler to use lower I/O directly. if you have I/O library that does that you need, it is easier to write: (hIn, hOut) <- createUnixPipe vPutStrLn hOut "hello" s <- vGetLine hIn i'm writing such lib now, so i'm interested to know what i need to do so that it will work ok. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
