Re: [Haskell-cafe] Data.Binary Endianness
Stefan O'Rear wrote: packages is only for those libraries that are shipped with GHC. It is? This is news to me. An obvious counter example seems to be the collections package which has been put here. This is not shipped with ghc and I'm not aware of any plans to do this. Perhaps if this is the intention it would be better to call it ghc-packages. But darcs.haskell.org does seem to be a real mess and I do have a hard time figuring out what's what here and how it's organised (or even if it is organised :-) Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Tuesday 11 September 2007 09:17, Don Stewart wrote: Just in case people didn't see, the `binary' package lives on http://darcs.haskell.org/binary/ However, Lennart Kolmodin, Duncan and I are actively maintaining and reviewing patches, so send them to one (or all) of us for review. Is there any deep reason why binary is not below packages like almost all other packages? The toplevel directory is already a complete mess, so a little bit more structure would be good. So I propose the following: Move binary to packages/binary, update any references to the old URL and use a symlink on darcs.haskell.org for backwards compatibility (this should be nuked in a few months or so). Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Sat, Sep 15, 2007 at 01:20:57PM +0200, Sven Panne wrote: On Tuesday 11 September 2007 09:17, Don Stewart wrote: Just in case people didn't see, the `binary' package lives on http://darcs.haskell.org/binary/ However, Lennart Kolmodin, Duncan and I are actively maintaining and reviewing patches, so send them to one (or all) of us for review. Is there any deep reason why binary is not below packages like almost all other packages? The toplevel directory is already a complete mess, so a little bit more structure would be good. So I propose the following: Move binary to packages/binary, update any references to the old URL and use a symlink on darcs.haskell.org for backwards compatibility (this should be nuked in a few months or so). packages is only for those libraries that are shipped with GHC. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Saturday 15 September 2007 20:09, Stefan O'Rear wrote:
packages is only for those libraries that are shipped with GHC.
First of all, this fact would be new to me, furthermore this would be a highly
volatile categorization. Should URLs change when a package suddenly gets into
or was thrown out of boot-/extra-packages? I don't think so. The fact what is
shipped and what not is explicit in the ghc/libraries/{boot,extra}-libraries,
not in the structure of darcs.haskell.org. Packages which are hosted there
should be below, well, packages. The toplevel directory is currently a bit
crowded and unstructured...
Cheers,
S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Monday 10 September 2007 19:50, Thomas Schilling wrote: [...] instance Binary MP3 where get = MP3 $ getHeader * getData -- [*] where getHeader = do magic - getWord32le case magic of ... Of course this works in the sense that it compiles, but Binary is conceptually the wrong class to use. to read a (IEEE) double you use do x - (get :: Double); ... :Where is IEEE mentioned in the docs? Does it use LE/BE/host order? Plain get/put on Float/Double are useless for reading IEEE floating numbers. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
sven.panne: On Monday 10 September 2007 19:50, Thomas Schilling wrote: [...] instance Binary MP3 where get = MP3 $ getHeader * getData -- [*] where getHeader = do magic - getWord32le case magic of ... Of course this works in the sense that it compiles, but Binary is conceptually the wrong class to use. I wouldn't go as far as saying `wrong', for protocol-specific data types it seems reasonable for the Haskell serialisation to use an agreed-upon external format, via a Binary instance. It's cute, anyway. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Tuesday 11 September 2007 08:14, Don Stewart wrote: sven.panne: On Monday 10 September 2007 19:50, Thomas Schilling wrote: [...] instance Binary MP3 where get = MP3 $ getHeader * getData -- [*] where getHeader = do magic - getWord32le case magic of ... Of course this works in the sense that it compiles, but Binary is conceptually the wrong class to use. I wouldn't go as far as saying `wrong', for protocol-specific data types it seems reasonable for the Haskell serialisation to use an agreed-upon external format, via a Binary instance. The question is: What is the *human reader* suggested when he sees a signature like foo :: Binary a = ... - a - ...? This should probably mean foo is using some portable (de-)serialization, but doesn't care about the actual representation, at least this is how I understand Binary's contract from the Haddock docs. The example above means something completely different, so I propose to add another class (e.g. ExternalBinary, better name needed) to the binary package for such uses. This class wouldn't have any instances in the package itself, but at least it would set a standard, so things are crystal clear when one sees a signature like blah :: ExternalBinary a = ... - a - This situation is very similar to the OO-world, where class inheritance is often overused, just because it looks so handy when written initially and delegation/aggregation/... would be the conceptually right way (i.e. implementation hierarchy vs. interface hierarchy). Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Monday 10 September 2007 19:26, Don Stewart wrote: Yep, just send a patch. Or suggest what needs to happen. OK, I'll see what I can do next weekend, currently I'm busy with packaging/fixing GHC. I have similar code lying around in various places, and it would be nice if there was a more officially sanctioned place to put this. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
sven.panne: On Monday 10 September 2007 19:26, Don Stewart wrote: Yep, just send a patch. Or suggest what needs to happen. OK, I'll see what I can do next weekend, currently I'm busy with packaging/fixing GHC. I have similar code lying around in various places, and it would be nice if there was a more officially sanctioned place to put this. Just in case people didn't see, the `binary' package lives on http://darcs.haskell.org/binary/ However, Lennart Kolmodin, Duncan and I are actively maintaining and reviewing patches, so send them to one (or all) of us for review. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Tue, 2007-09-11 at 09:10 +0200, Sven Panne wrote: foo :: Binary a = ... - a - ...? This should probably mean foo is using some portable (de-)serialization, but doesn't care about the actual representation, I'm probably missing something, but: How can the format be portable if the representation isn't unambigously defined? And if it is unabmigously defined, what's wrong with using it for externally defined data formats? -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
Ketil Malde wrote: On Tue, 2007-09-11 at 09:10 +0200, Sven Panne wrote: foo :: Binary a = ... - a - ...? This should probably mean foo is using some portable (de-)serialization, but doesn't care about the actual representation, I'm probably missing something, but: How can the format be portable if the representation isn't unambigously defined? And if it is unabmigously defined, what's wrong with using it for externally defined data formats? It's portable because it works on other machines also running that exact version of Data.Binary, regardless of their CPU architecture (in particular, word size or endianness). That is the precise sense of 'portable' used here. The actual format used by Data.Binary is not explicitly described in any standard (although in most cases it's moderately obvious, and anyone can read the code), and it's not formally guaranteed that it will never change in a later version (although the maintainers will no doubt try very hard to ensure it doesn't); nor does it contain any automatic support for version-stamping to ensure backwards compatibility in the face of later unlooked-for format changes. For these reasons, although it is very cool, I don't think it can be recommended as a basis for long-term file format definitions. (All of the above speaks of the 'high-level' Data.Binary not the 'low-level'.) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Tue, 2007-09-11 at 12:01 +0100, Jules Bean wrote: How can the format be portable if the representation isn't unambigously defined? And if it is unabmigously defined, what's wrong with using it for externally defined data formats? It's portable because it works on other machines also running that exact version of Data.Binary, regardless of their CPU architecture (in particular, word size or endianness). That is the precise sense of 'portable' used here. Okay. Data.Binary is not for persistence, then (since the format may change between versions of the library, and presumably between different compilers/RTS), but merely for transient serializing, as over a network connection. This isn't so obvious from the documentation (I myself have blatantly used it for persistence and for reading in externally specified data), and the functions involving FilePaths also tend confusing the issue here. Perhaps it could be made clearer? Another way to avoid abuse of Data.Binary would be to add a unique magic number to each stream, and throw an exception when a mismatching magic number is encountered. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
Ketil Malde wrote: On Tue, 2007-09-11 at 12:01 +0100, Jules Bean wrote: How can the format be portable if the representation isn't unambigously defined? And if it is unabmigously defined, what's wrong with using it for externally defined data formats? It's portable because it works on other machines also running that exact version of Data.Binary, regardless of their CPU architecture (in particular, word size or endianness). That is the precise sense of 'portable' used here. Okay. Data.Binary is not for persistence, then (since the format may change between versions of the library, and presumably between different compilers/RTS), but merely for transient serializing, as over a network connection. I probably came over stronger than I intended. It is intended for persistence, too. My point is that, should a bug be discovered in Data.Binary, the maintainers may be forced to change the format and there is no mechanism in place for coping with that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Sep 11, 2007, at 7:01 , Jules Bean wrote: The actual format used by Data.Binary is not explicitly described in any standard (although in most cases it's moderately obvious, and anyone can read the code), and it's not formally guaranteed that it will never change in a later version (although the maintainers will no doubt try very hard to ensure it doesn't); nor does it contain any automatic support for version-stamping to ensure backwards compatibility in the face of later unlooked-for format changes. I will just point out that, while this is one extreme, the other extreme is ASN.1. I think we want to walk the middle path instead -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
So the answer for persistence is Data.Binary - ASN.1 converter that can be used in extrema? On 11/09/2007, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On Sep 11, 2007, at 7:01 , Jules Bean wrote: The actual format used by Data.Binary is not explicitly described in any standard (although in most cases it's moderately obvious, and anyone can read the code), and it's not formally guaranteed that it will never change in a later version (although the maintainers will no doubt try very hard to ensure it doesn't); nor does it contain any automatic support for version-stamping to ensure backwards compatibility in the face of later unlooked-for format changes. I will just point out that, while this is one extreme, the other extreme is ASN.1. I think we want to walk the middle path instead -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ 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] Data.Binary Endianness
Jules Bean wrote: For these reasons, although it is very cool, I don't think it can be recommended as a basis for long-term file format definitions. Indeed, the authors have never claimed that this is what it's for. Unfortunately, because the authors haven't *disclaimed* this as a purpose, people have fairly reasonably assumed that this *is* the intent of the package. In conversations with Don and Duncan, they've always been quite clear that Data.Binary is intended to shovel bits rapidly and with a reasonable interface. All of the things of which you speak, and more useful ones such as RTTI and representation of cyclic data, ought to live in a higher-level library. Said library merely hasn't been written yet. (All of the above speaks of the 'high-level' Data.Binary not the 'low-level'.) Data.Binary *is* the low-level Data.Binary :-) b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
Bryan O'Sullivan wrote: (All of the above speaks of the 'high-level' Data.Binary not the 'low-level'.) Data.Binary *is* the low-level Data.Binary :-) I was distinguishing between these two levels: (1) High-level = Binary typeclass. Contains instances for many, many useful common types, the internals of which you don't need to understand to use them. But then you wont' understand the format used. Which doesn't matter if all you want to do is pipe stuff around. (2) Low-level = Get and Put typeclasses. Allow you to shovel bytes as you wish, including bundling them up into words of various sizes with explicit endian-ness control. You can sensibly use this to define file formats precisely with some reasonable expectation of speed. You could for example write a TIFF reader (and writer [*]) using these primitives. Jules [*] - exercise for the reader: Can you write a TIFF reader and writer simultaneously, in the sense that you define the file format once and get Get and Put instances for free? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
Don Stewart wrote: Just in case people didn't see, the `binary' package lives on http://darcs.haskell.org/binary/ However, Lennart Kolmodin, Duncan and I are actively maintaining and reviewing patches, so send them to one (or all) of us for review. Right. And this is the real binary package then? (I've seen references to seemingly half a dozen binary packages, some obsolete, some not... It's rather confusing out there!) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
andrewcoppin: Don Stewart wrote: Just in case people didn't see, the `binary' package lives on http://darcs.haskell.org/binary/ However, Lennart Kolmodin, Duncan and I are actively maintaining and reviewing patches, so send them to one (or all) of us for review. Right. And this is the real binary package then? (I've seen references to seemingly half a dozen binary packages, some obsolete, some not... It's rather confusing out there!) Yep. Look on hackage to get a sense of what is current. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
Adrian Neumann wrote: For example, the internet states, that the magic number, that puts 'BM' in the first two bytes of the file is 19778. But when I put (19778::Word16) I get 'MB' instead. I read on the german Wikipedia, that bmp uses little endian encoding, but Data.Binary uses big endian. Obviously this can't work. Data.Binary is two different things. This is not as well explained as it could be. It is (a) a binary read/write layer for haskell types, which uses its own formats you have no right to complain about (b) a simple efficient binary bitstream layer You don't want to use (a), which takes great care to use compatible endianness to make sure its output can be read on other architectures. (b) however lets you choose your endianness. http://www.cse.unsw.edu.au/~dons/binary/Data-Binary-Put.html The docs are not as well interlinked as you might hope. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Mon, 2007-09-10 at 11:10 +0100, Jules Bean wrote: The docs are not as well interlinked as you might hope. In fact, the docs on hackage are interlinked nicely. That is, for packages for which the documentation builds. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
Thomas Schilling wrote: On Mon, 2007-09-10 at 11:10 +0100, Jules Bean wrote: The docs are not as well interlinked as you might hope. In fact, the docs on hackage are interlinked nicely. That is, for packages for which the documentation builds. On the documentation page: http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html I see no links to Data.Binary.Put, nor anything to make me even suspect that there is another page I should be reading. Nor anythign to suggest that Data.Binary is split into two levels in the way I outlined in my earlier message. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Monday 10 September 2007 17:17, Jules Bean wrote:
On the documentation page:
http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html
[...]
Just a small hint: That page seems to be out of date compared to:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.3
The library looks quite nice, but I'm missing support for reading/writing
Int{8,16,32,64} and Float/Double (in IEEE format, currently *the* binary
representation in most formats I know) in LE/BE/host byte order. Have I
overlooked something? Using unsafeCoerce# and friend there are probably
workarounds for this, but having it in the official API would be quite
helpful for I/O of real-world formats.
Cheers,
S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Mon, 2007-09-10 at 16:17 +0100, Jules Bean wrote: Thomas Schilling wrote: On Mon, 2007-09-10 at 11:10 +0100, Jules Bean wrote: The docs are not as well interlinked as you might hope. In fact, the docs on hackage are interlinked nicely. That is, for packages for which the documentation builds. On the documentation page: http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html I see no links to Data.Binary.Put, nor anything to make me even suspect that there is another page I should be reading. Nor anythign to suggest that Data.Binary is split into two levels in the way I outlined in my earlier message. Jules No offence was intended. I was simply mentioning a feature that might be overlooked by many. If you look at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.3 You can find links to the various modules provided by that package and will notice that links to parts exported by other packages work nicely. (In this case it is only base-2.0, I think.) Your clarification is probably worth including into the package documentation, but I think you have to talk to dons for that to happen. / Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Mon, 2007-09-10 at 18:11 +0200, Sven Panne wrote:
On Monday 10 September 2007 17:17, Jules Bean wrote:
On the documentation page:
http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html
[...]
Just a small hint: That page seems to be out of date compared to:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.3
The library looks quite nice, but I'm missing support for reading/writing
Int{8,16,32,64}
maybe this?
http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/Data-Binary-Get.html#v%3AgetWord8
Also note that many Haskell standard types are instances of the Binary
class. I might have misunderstood what you're asking for, though...
and Float/Double (in IEEE format, currently *the* binary
representation in most formats I know) in LE/BE/host byte order. Have I
overlooked something? Using unsafeCoerce# and friend there are probably
workarounds for this, but having it in the official API would be quite
helpful for I/O of real-world formats.
Cheers,
S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Monday 10 September 2007 18:21, Thomas Schilling wrote:
On Mon, 2007-09-10 at 18:11 +0200, Sven Panne wrote:
[...]
The library looks quite nice, but I'm missing support for reading/writing
Int{8,16,32,64}
maybe this?
http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/Data-Binary
-Get.html#v%3AgetWord8
Of course I can *implement* everything on top of this, but this is not the
point. The binary library should have builtin support for more data types,
and this is probably not hard to implement.
Also note that many Haskell standard types are instances of the Binary
class. I might have misunderstood what you're asking for, though...
Again a confusion of the 2 things the binary package offers (I was confused
initially as well): The Binary class is totally useless for reading/writing
existing formats, simply because that's not its task. To read/write an
existing format (BMP, MP3, WAV, Quake BSP, etc.) you have to use the
getFoo/readFoo functions. So what I was asking for is:
getInt32be, putIEEEFloatLe, getIEEEDoubleHost, ...
Type classes might be used to get a slightly smaller API, but I am unsure
about the performance impact and how much this would really buy us in terms
of the ease of use of the API.
Cheers,
S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
sven.panne:
On Monday 10 September 2007 18:21, Thomas Schilling wrote:
On Mon, 2007-09-10 at 18:11 +0200, Sven Panne wrote:
[...]
The library looks quite nice, but I'm missing support for reading/writing
Int{8,16,32,64}
maybe this?
http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/Data-Binary
-Get.html#v%3AgetWord8
Of course I can *implement* everything on top of this, but this is not the
point. The binary library should have builtin support for more data types,
and this is probably not hard to implement.
Yeah, just send patches against the darcs repo for either Binary instances for
more
basic types, or primops if necessary (e.g. for Float)
Also note that many Haskell standard types are instances of the Binary
class. I might have misunderstood what you're asking for, though...
Again a confusion of the 2 things the binary package offers (I was confused
initially as well): The Binary class is totally useless for reading/writing
existing formats, simply because that's not its task. To read/write an
existing format (BMP, MP3, WAV, Quake BSP, etc.) you have to use the
getFoo/readFoo functions. So what I was asking for is:
getInt32be, putIEEEFloatLe, getIEEEDoubleHost, ...
Right.
Type classes might be used to get a slightly smaller API, but I am unsure
about the performance impact and how much this would really buy us in terms
of the ease of use of the API.
Yeah, performance is the big thing here: we spent weeks cranking it up to
hundred+ M/sec throughput. I'd hate to lose that, and the API is pretty simple
anyway.
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
nominolo: On Mon, 2007-09-10 at 16:17 +0100, Jules Bean wrote: Thomas Schilling wrote: On Mon, 2007-09-10 at 11:10 +0100, Jules Bean wrote: The docs are not as well interlinked as you might hope. In fact, the docs on hackage are interlinked nicely. That is, for packages for which the documentation builds. On the documentation page: http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html I see no links to Data.Binary.Put, nor anything to make me even suspect that there is another page I should be reading. Nor anythign to suggest that Data.Binary is split into two levels in the way I outlined in my earlier message. Jules No offence was intended. I was simply mentioning a feature that might be overlooked by many. If you look at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.3 You can find links to the various modules provided by that package and will notice that links to parts exported by other packages work nicely. (In this case it is only base-2.0, I think.) Your clarification is probably worth including into the package documentation, but I think you have to talk to dons for that to happen. Yep, just send a patch. Or suggest what needs to happen. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Mon, 2007-09-10 at 18:40 +0200, Sven Panne wrote:
Type classes might be used to get a slightly smaller API, but I am unsure
about the performance impact and how much this would really buy us in terms
of the ease of use of the API.
There shouldn't be any problem w.r.t. performance, the compiler can
specialize and inline. What's the problem with reading custom data?
data MP3 = MP3 { ... }
instance Binary MP3 where
get = MP3 $ getHeader * getData -- [*]
where getHeader = do magic - getWord32le
case magic of
...
...
put = ...
to read a (IEEE) double you use
do x - (get :: Double); ...
but most of the time the right type will be inferred from the context.
If there are serious performance problems it'd could probably be
attacked using some more use of inline declarations or maybe use of
compiler rewrite rules (in the library). I don't expect things to work
as smoothly as they maybe could (the package is in version 0.3), but so
far things don't seem too bad. Did you do any benchmarks?
/ Thomas
[*] .. note that $ .. * is just a more convenient way of writing:
do hdr - getHeader
dat - getData
return (MP3 hdr dat)
Those operators live in Control.Applicative and are included in
recent versions of the 'base' package. (
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
Don Stewart wrote: sven.panne: Of course I can *implement* everything on top of this, but this is not the point. The binary library should have builtin support for more data types, and this is probably not hard to implement. Yeah, just send patches against the darcs repo for either Binary instances for more basic types, or primops if necessary (e.g. for Float) Ah, the famous open source process we all hear so much hype about... This is probably the first time I've actually seen it in action though. Refreshing. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
