- Libraries - Haskell.org

RE: Converting things to and from binary
by Simon Marlow 21 May '03

21 May '03

> (2) the York Binary library uses the IO monad, and presumably > various variables within a BinHandle, to keep track of state. > I think this is unnecessary, for example I don't think the > process of converting a value to a byte array should really > have to go through IO. We are supposed to be functional > programmers after all. When writing to a BinMem it would be possible to avoid the IO monad, and use something like the ST monad instead. However, I'm not sure it's worth making this generalisation, since it would necessarily complicate the library quite a bit. Do you have an application where being in the IO monad to do this stuff isn't possible, or is inconvenient? Cheers, Simon

4 8

Re: list monad transformer
by Iavor Diatchki 21 May '03

21 May '03

hello, Andrew J Bromage wrote: > G'day. > > On Fri, May 16, 2003 at 08:45:14AM -0700, Iavor Diatchki wrote: > > >>i would gladly volunteer for the task. in fact i have my own monad >>transformer library which is very simillar to the ghc one in some >>respects, and i have been wanting to merge the two together... > > > I'm also interested in this, as I have some monad transformers of my > own which I'd like to add (the backtracking monad transformer being one > of them). Though I have no particular desire to "own" this part of > the module namespace. :-) when you talk about a backtracking monad transformer which one are you refering to? ralf hinze seems to have a whole bunch of papers on the matter, some of which seem to be a lot like the "Maybe" transformer and some seem very complicated (but presumable are very efficient). > If you need some help doing the merge, please let me know. Or, > alternatively, please let me know when you're ready to accept a > contribution. i don't have access to the repository so i am not really doing anything at the moment. i would be interested at looking at your transformres quite independently of the library... are they available anywhere? i think the main probelm with adding transformers to the library is that the amount of code grows quadratically in the number of transformers (as one has to specify how each one interacts with every other one). but of course if there is some ne wfunctionallity we should add it. bye iavor

2 1

RE: converting things to and from binary
by Simon Marlow 21 May '03

21 May '03

> Here's another reason why I think it's better to make the monad > used variable (as with my framework but not Malcolm's). The main > method I use for encoding binary data needs access to a bit of extra > information about what it is encoding it for. This basically > can't be done within Malcolm's framework except by, er, parking > the extra stuff in a global variable and then using another global > lock as otherwise hell will pop when two threads try to use this > mechanism at once. Indeed, this strikes a chord with me since we had exactly this problem in GHC. Fortunately in GHC we're using our own copy of the Binary library, so I was able to hack it to include some extra state in the BinHandle. > This is sufficiently worthwhile to me that I think I shall probably > implement it, and then see whether anyone else is interested in using > it. I don't think you need any extensions apart from FFI and > multi-parameter type-classes, Please take a look at the Binary library posted to the libraries list a while back, it shows how to do this without using the FFI. > AND some way of writing/reading > CChars and CStringLen's to Handles, how do I do this please Simon? > hPutChar/hGetChar/hPutBuf/hGetBuf? Not sure why you want to do that, but hPutBuf can output CStrings. Cheers, Simon

1 0

Re: converting things to and from binary
by George Russell 21 May '03

21 May '03

Here's another reason why I think it's better to make the monad used variable (as with my framework but not Malcolm's). The main method I use for encoding binary data needs access to a bit of extra information about what it is encoding it for. This basically can't be done within Malcolm's framework except by, er, parking the extra stuff in a global variable and then using another global lock as otherwise hell will pop when two threads try to use this mechanism at once. It can be done within my framework, though you need to change it slightly to make the monad in question one of the class variables. Thus you would have class HasBinary a monad Most types (integers, lists and so on) would just instance this for all values of monad. Where you need extra state you would create an extra monad for the purpose, and just instance for that monad. This is sufficiently worthwhile to me that I think I shall probably implement it, and then see whether anyone else is interested in using it. I don't think you need any extensions apart from FFI and multi-parameter type-classes, AND some way of writing/reading CChars and CStringLen's to Handles, how do I do this please Simon? hPutChar/hGetChar/hPutBuf/hGetBuf?

1 0

RE: Converting things to and from binary
by Simon Marlow 21 May '03

21 May '03

> Several tests by SimonM and I have shown > that the bit style is about 20% slower than the byte style. Really? I seem to recall it was more like 250% :-) http://haskell.org/pipermail/libraries/2002-December/000742.html Cheers, Simon

2 1

RE: architecture-dependent types
by Simon Marlow 21 May '03

21 May '03

> Should not Foreign.C.Types, Foreign.C.TypesISO and System.Posix.Types > export their types opaquely? That would make their interface and > documentation architecture-independent. The FFI doesn't explicitly specify whether these types should be exported abstractly or not, but it does say in section 6.2: "... all types exported by \code{CTypes} are represented as type synonyms or \code{newtype}s of basic foreign types ..." we should really decide one way or the other, since this ambiguity will lead to non-portable differences between implementations of CTypes (and hence Foreign.C.Types). Having the types be opaque sounds reasonable to me, and similarly for System.Posix.Types. Cheers, Simon

2 1

RE: Licensing of Haskell code
by Simon Marlow 21 May '03

21 May '03

[ moved to libraries(a)haskell.org ] Ganesh Sittampalam writes: > Another question is what should happen if there are two "competing" > libraries that do the same thing but have different licenses. > For example, > the existing library Foo.Bar is GPL, and someone needs a BSD > version so writes their own. That's a good question. At the moment, we're allowing for one "reference implementation" which also defines the API for each module in the hierarchy. Of course, there may be any number of actual implementations of any given library, but we require that a reference implementation exists and that it be licensed under an OSI approved license. It occurs to me that if the reference implementation is GPL, then this may encumber the definition of the API such that a commercial reimplementation would not be possible. In some cases this is inevitable - for example, System.Console.Readline wraps a GPL library, so there is probably no way to have an unencumbered API definition for this library. However, we want to avoid having "essential" parts of the library definition covered by the GPL. The library document[1] mentions this problem, but doesn't specify exactly what we mean by "essential" - we should really expand on that. Cheers, Simon [1] http://www.haskell.org/~simonmar/libraries/libraries.html

2 1

RE: Converting things to and from binary
by Simon Peyton-Jones 21 May '03

21 May '03

| There was a *long* discussion of this on the libraries list a few months | back. See | | http://haskell.org/pipermail/libraries/2002-November/000691.html | | and the discussion that followed. | | I think that we should | | (a) move this discussion to the libraries list and | (b) work from the point reached by those discussions It would be great if someone took ownership of the discussion and brought it to a conclusion, giving us all a library or libraries we could use. Volunteers, stand forth! Simon

1 0

Re: Converting things to and from binary
by Hal Daume III 20 May '03

20 May '03

I'm going to chime in here for the first time. There was a *long* discussion of this on the libraries list a few months back. See http://haskell.org/pipermail/libraries/2002-November/000691.html and the discussion that followed. I think that we should (a) move this discussion to the libraries list and (b) work from the point reached by those discussions - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume On Tue, 20 May 2003, George Russell wrote: > Derek wrote (snipped) > > What's wrong with NHC's Binary/BinArray library? There seems to be a > > GHC port on the GreenCard page. > > The home page of the York Binary library seems to be > http://www.cs.york.ac.uk/fp/nhc13/libs/Binary.html > Malcolm will doubtless have something to say here. However I would > say not that there's something "wrong" with the Binary/BinArray > library, but that it seems to be addressed towards a different > class of problems (specifically data-compression) to those > I am interested in (blasting data rapidly in and out). The main > differences are > (1) the framework I proposed in the original message: > http://haskell.org/pipermail/glasgow-haskell-users/2003-May/005166.html > is byte-based, while the York Binary framework is bit-based. > I would imagine that this means the York Binary framework would be > very much less efficient at handling long sequences of bytes, > since they will presumably have to be shifted before > being written to the destination. > (2) the York Binary library uses the IO monad, and presumably > various variables within a BinHandle, to keep track of state. > I think this is unnecessary, for example I don't think the > process of converting a value to a byte array should really > have to go through IO. We are supposed to be functional > programmers after all. > (3) the York binary library provides two things you can > write bits to (a Handle, and a fixed area in memory) and a > large set of operations (seek and co), but it would be > difficult for a normal programmer to extend this. (For > example, what about someone in GHC wanting to write to > a Posix Fd?) On the other hand the framework I propose > has only two basic operations for writing, and two for > reading, which means it should be much easier to define > alternative consumers and sources of binary data. > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

2 2

architecture-dependent types
by Ross Paterson 20 May '03

20 May '03

Should not Foreign.C.Types, Foreign.C.TypesISO and System.Posix.Types export their types opaquely? That would make their interface and documentation architecture-independent.

1 0