[Haskell] MonadPlus vs. Monoid
I was wondering, in the MonadPlus documentation it says that: * mzero is the identity of mplus (and some extra conditions) * mplus is an associative operation While for Monoid we have: * mempty is identity of mappend * mappend is an associative operation MonadPlus is of course a 'stronger' assertion. But why is not every instance of MonadPlus also an instance of Monoid? > instance MonadPlus m => Monoid (m a) where >mempty = mzero >mappend = mplus The only type that is an instance of both is [a]. But I see no reason why it there should not be a Monoid instance for other MonadPlus types. In particular, an instance for Maybe could be useful with a writer monad when you are only interested in the first result. Twan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] IO == ST RealWorld
Is there any reason why IO should not be defined as: > type IO a = ST RealWorld a in implementations that support ST? This way IORef/STRef and IOArray/STArray can be merged. I know under the hood they already share code, but this way they can also share an interface. Twan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Data.CompactString 0.1 - my attempt at a Unicode ByteString
Hello all, I would like to announce my attempt at making a Unicode version of Data.ByteString. The library is named Data.CompactString to avoid conflict with other (Fast)PackedString libraries. The library uses a variable length encoding (1 to 3 bytes) of Chars into Word8s, which are then stored in a ByteString. The structure is very much based on Data.ByteString, most of the implementation is copied from there. Hopefully this means that fusion rules could be copied as well. This is kind of a pre-release, many functions are still missing, and I have not benchmarked yet. I am releasing this in the hopes of getting some feedback on the general idea. Homepage: http://twan.home.fmf.nl/compact-string/ Haddock: http://twan.home.fmf.nl/compact-string/doc/html/ Source:darcs get http://twan.home.fmf.nl/repos/compact-string Twan van Laarhoven ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Data.CompactString 0.1 - my attempt at a Unicode ByteString
Chris Kuklewicz wrote: Can I be among the first to ask that any Unicode variant of ByteString use a recognized encoding? In reading all the poke/peek function I did not see anything that your tag bits accomplish that the tag bits in utf-8 do not, except that you want to write only a single routine for the poke/peek forwards and backwards operations instead of two routines. It is definitely more compact in the worst case, and more "Once And Only Once", but at a very high cost of incompatibility. The reason for inventing my own encoding is that it is easier to use and takes less space than UTF-8. The only advantage UTF-8 has is that it can be read and written directly. I guess this is a trade off, faster manipulation and smaller storage compared to simpler and faster io. I have not benchmarked it either way, so it is just guesswork for now. Fortunately the entire library can be easily converted to use a different encoding by just changing the peekChar/pokeChar functions. One of the biggest wins with with a Unicode ByteString will be the ability to transfer the buffer directly to and from the disk and network. Your code will always need the data to be rewritten both incoming and outgoing. The most ideal case would be the ability to load different encodings via import statements while using the same API. I was hoping that there would be only a single string type, with different encodings handled by functions: > encode :: CompactString -> ByteString > decode :: ByteString -> CompactString This is important if it is not know beforehand how a file is encoded. For example on windows Unicode files are either UTF-8 or UTF-16, identified by a byte order mark. Twan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Data.CompactString 0.2 - now with 100% more UTF-8
John Meacham wrote: I would highly highly recommend using utf8. inventing new formats without very clear and pervasive benefits is just not good practice and I wouldn't want to see it in standard libraries. I still think it should not matter what the library uses *internally*. The only way the user can see the encoding is through unsafeTo/FromByteString functions. However, I have decided to make a UTF-8 version of the library. Fortunately the only things that change are the encoding functions, which means that the library could potentially be used for all sorts of variable length encodings. This new version is available from: http://twan.home.fmf.nl/compact-string/ By the way, many more functions are implemented now, and there are also QuickCheck tests for everything. not to mention that utf8 was designed so things like sorting a raw bytestring with utf8 in it produces the exact same result as decoding it, then sorting it. a _very_ large win for the 'Ord' instance for CompactString. You are right, using UTF-8 here makes some things a lot easier. It is quite possible that UTF-8 is a net win over my custom encoding in most common use cases. Twan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Data.CompactString 0.3 - Unicode ByteString with different encodings
Hello all, I would like to announce version 0.3 of my Data.CompactString library. Data.CompactString is a wrapper around Data.ByteString that represents a Unicode string. This new version supports different encodings, as can be seen from the data type: > data Encoding a => CompactString a Currently the following encodings are supported: - UTF-8, UTF-16 and UTF-32 (both big and little endian) - ASCII - ISO-8859-1 (latin1) - A custom compact encoding Conversion between different encodings, and between CompactStrings and ByteStrings is possible. There are also functions to automatically detect the encoding of files based on a byte order mark. Just this part of CompactString could be used as an encoding library for ByteStrings. In addition to overloaded functions like > length :: Encoding a => CompactString a -> Int, there are also modules Data.CompactString.UTF8, Data.CompactString.UTF16, etc. which are restricted to a single encoding: > length :: CompactString UTF8 -> Int I expect that these will be more useful in most cases. The library is now feature complete, but it has not been optimized yet. There are also some problems with I/O functions, since it is difficult to determine what kind of encoding should be used given a Handle. Homepage: http://twan.home.fmf.nl/compact-string/ Haddock: http://twan.home.fmf.nl/compact-string/doc/html/ Source:darcs get http://twan.home.fmf.nl/repos/compact-string Twan van Laarhoven ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: ParseP library 0.1
Hi, Mostly for fun, and to see how well it would work, I made a generalized/improved variant of the ReadP parser library. Unlike ReadP ParseP can handle any type of token, and actually generates error messages in case something goes wrong. It is also possible to use things other then a list as an input stream, for example ByteStrings. In addition to the unbiased choice provided by ReadP, and a 'greedy' choice operator similar to the behavior of Parsec (when using try), there is also what I call a 'soft biased' choice. This operator prefers the left alternative, but not if it leads to parse errors later on. For example > runParser ((lit 'a' <<|> return ()) >> lit 'a') "a" will not lead to errors, while it would be an error with other biased choice operators. An obvious advantage of ParseP over Parsec is that you don't have to mess with 'try'. Also, all alternatives are parsed in parallel, so no backtracking is needed. But I have no idea how the performance would compare in practice. Also, I am not to happy about the name, does anyone has any other suggestions? Homepage: http://twan.home.fmf.nl/parsep/ Source: darcs get http://twan.home.fmf.nl/repos/parsep Haddock: http://twan.home.fmf.nl/parsep/doc/html/ Twan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANN: IOSpec 0.1
Wouter Swierstra wrote: Test.IOSpecVersion 1.0 Shouldn't that be 0.1? * Test.IOSpec.Teletype: a specification of getChar and putChar. You use Dynamic for the data type in IORefs, this has the unfortunate consequence of needing Typeable constraints. You could try to use unsafeCoerce instead, > type Data = () > unsafeToData :: a -> Data > unsafeToData = unsafeCoerce > unsafeFromData :: Data -> a > unsafeFromData = unsafeCoerce I think this should be just as safe as Dynamic, since internally Dynamic uses unsafeCoerce as well. Just steal the details from there. Twan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: multiset 0.1
Hello, I have just uploaded version 0.1 of the multiset library to hackage. This package provides Data.MultiSet and Data.IntMultiSet modules. A multiset or bag is like a set, but it can contain multiple copies of the same element. The library is already pretty much finished, maybe I should have called it 1.0. It implements the same interface as Data.Set, with some additional functions specific to multisets. Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multiset-0.1 Haddock: http://twan.home.fmf.nl/multiset/doc/ Darcs: http://twan.home.fmf.nl/repos/multiset/ Twan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
