[Haskell-cafe] Bytestring map/zipWith rationale
Hello all, Something's always bothered me about map and zipWith for ByteString. Why is it map :: (Word8 - Word8) - ByteString - ByteString but zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] ? Obviously they can be transformed into each other with pack/unpack, and as I understand it, the compiler performs sufficient optimizations so that there's no performance hit to doing things like (pack $ zipWith xor a b), but it still seems inconsistent. Is there a deep reason for this? -- Scott Lawrence Linux baidar 3.10.9-1-ARCH #1 SMP PREEMPT Wed Aug 21 13:49:35 CEST 2013 x86_64 GNU/Linux ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestring map/zipWith rationale
On Thu, 12 Sep 2013, Tom Ellis wrote: On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote: Something's always bothered me about map and zipWith for ByteString. Why is it map :: (Word8 - Word8) - ByteString - ByteString but zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] Well, what if you wanted to zipWith a function of type Word8 - Word8 - Foo instead of Word8 - Word8 - Word8? Then I would do what I do with map, and call `unpack` first. Either of the two options is usable: map :: (Word8 - Word8) - ByteString - ByteString zipWith :: (Word8 - Word8 - Word8) - ByteString - ByteString - ByteString (or) map :: (Word8 - a) - ByteString - [a] zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] I just don't understand why we have one from each. -- Scott Lawrence ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestring map/zipWith rationale
On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote: Something's always bothered me about map and zipWith for ByteString. Why is it map :: (Word8 - Word8) - ByteString - ByteString but zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] Well, what if you wanted to zipWith a function of type Word8 - Word8 - Foo instead of Word8 - Word8 - Word8? Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestring map/zipWith rationale
On Thu, 12 Sep 2013 18:24:24 +0400, Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote: Something's always bothered me about map and zipWith for ByteString. Why is it map :: (Word8 - Word8) - ByteString - ByteString but zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] Well, what if you wanted to zipWith a function of type Word8 - Word8 - Foo instead of Word8 - Word8 - Word8? Then why doesn’t map take “Word8 - a”, but only “Word8 - Word8”? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestring map/zipWith rationale
Scott: benchmark the two and you'll see why we have both :-) On Thursday, September 12, 2013, Scott Lawrence wrote: On Thu, 12 Sep 2013, Tom Ellis wrote: On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote: Something's always bothered me about map and zipWith for ByteString. Why is it map :: (Word8 - Word8) - ByteString - ByteString but zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] Well, what if you wanted to zipWith a function of type Word8 - Word8 - Foo instead of Word8 - Word8 - Word8? Then I would do what I do with map, and call `unpack` first. Either of the two options is usable: map :: (Word8 - Word8) - ByteString - ByteString zipWith :: (Word8 - Word8 - Word8) - ByteString - ByteString - ByteString (or) map :: (Word8 - a) - ByteString - [a] zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] I just don't understand why we have one from each. -- Scott Lawrence __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Bytestring map/zipWith rationale
Carter: we don't have both. We have one function from each category. My guess is nobody's ever really needed a really fast zipWith :: (Word8-Word8-Word8) - ByteString - ByteString - ByteString; that's the only reason I can think of for its omission. On Thu, Sep 12, 2013 at 10:45 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Scott: benchmark the two and you'll see why we have both :-) On Thursday, September 12, 2013, Scott Lawrence wrote: On Thu, 12 Sep 2013, Tom Ellis wrote: On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote: Something's always bothered me about map and zipWith for ByteString. Why is it map :: (Word8 - Word8) - ByteString - ByteString but zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] Well, what if you wanted to zipWith a function of type Word8 - Word8 - Foo instead of Word8 - Word8 - Word8? Then I would do what I do with map, and call `unpack` first. Either of the two options is usable: map :: (Word8 - Word8) - ByteString - ByteString zipWith :: (Word8 - Word8 - Word8) - ByteString - ByteString - ByteString (or) map :: (Word8 - a) - ByteString - [a] zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] I just don't understand why we have one from each. -- Scott Lawrence __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestring map/zipWith rationale
I did use that a couple of times (`xor`ing 2 ByteStrings together), and was surprised by the omission back then, but IIRC (can't validate now), there's a specialised zipWith (as proposed) in the module (with some other name, obviously), which is not exported, but used when you 'pack' the result of 'zipWith' when the result is '[Word8]'... You might want to look into that. Nicolas On Sep 12, 2013 8:11 PM, John Lato jwl...@gmail.com wrote: Carter: we don't have both. We have one function from each category. My guess is nobody's ever really needed a really fast zipWith :: (Word8-Word8-Word8) - ByteString - ByteString - ByteString; that's the only reason I can think of for its omission. On Thu, Sep 12, 2013 at 10:45 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Scott: benchmark the two and you'll see why we have both :-) On Thursday, September 12, 2013, Scott Lawrence wrote: On Thu, 12 Sep 2013, Tom Ellis wrote: On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote: Something's always bothered me about map and zipWith for ByteString. Why is it map :: (Word8 - Word8) - ByteString - ByteString but zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] Well, what if you wanted to zipWith a function of type Word8 - Word8 - Foo instead of Word8 - Word8 - Word8? Then I would do what I do with map, and call `unpack` first. Either of the two options is usable: map :: (Word8 - Word8) - ByteString - ByteString zipWith :: (Word8 - Word8 - Word8) - ByteString - ByteString - ByteString (or) map :: (Word8 - a) - ByteString - [a] zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] I just don't understand why we have one from each. -- Scott Lawrence __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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 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] Hackage 2 now available for beta testing
On 09.09.2013 20:24, Duncan Coutts wrote: Well-Typed and the Industrial Haskell Group (IHG) are very pleased to announce that Hackage 2 is now available for public beta testing. [new features]: http://beta.hackage.haskell.org/new-features Package candidates. You may have noticed that package versions are often uploaded in quick succession -- sometimes just minutes apart -- because a mistake is only noticed after the author uploaded. This feature lets you upload a candidate, giving it a URL that others can download from, and gives an opportunity for build bots and documentation builders to try the package out. Once the author is satisfied then they can publish to the main package index. We think this feature is about 90% complete. See issue #41. That sound so good! Thanks for putting out this feature! Andreas On 2013-09-09 20:24, Duncan Coutts wrote: Well-Typed and the Industrial Haskell Group (IHG) are very pleased to announce that Hackage 2 is now available for public beta testing. The plan is to do the final switchover in late September, to coincide with ICFP. http://beta.hackage.haskell.org/ [1] Read on for details of how to help with the public beta, an overview of the new features and what the IHG has been doing to help. Support from the Industrial Haskell Group = The IHG is a consortium of companies that rely on Haskell. The IHG members have funded the effort to get Hackage 2 up to feature parity and get it ready for the switchover. The IHG funded this effort because while the volunteer effort got us the first 90% of the way there (including adding a number of new features) there was still the last 90% to do to get it production ready. The IHG members decided to fund Hackage 2 not just because they are good citizens, but out of enlightened self-interest. Hackage has over 5000 packages written by over 1000 people -- including the world's best Haskell developers. This is a massive resource. The IHG members recognise that improvements to the tools and infrastructure that the community uses helps the community to produce more and better code. This is a benefit to everyone in the community -- including the commercial users. The IHG is keen to increase its membership so that more resources can be dedicated to improving the Haskell development platform. If your organisation relies on Haskell in some way then you may want to consider joining. See the IHG website for more details or contact i...@industry.haskell.org. [IHG website]: http://industry.haskell.org/ [2] Despite the help of the IHG in getting to this point, Hackage is a community project, and its success depends on the community maintaining and further improving the new server. The code is now on github so it is easier to contribute, and now that the server is live there is more immediate gratification for volunteers contributing fixes and new features. Public beta === We would like to encourage you to take part in the public beta testing. We need help both from package authors as well as other users of the site. Please report any problems you find using the issue tracker on the hackage-server github site. [issue tracker]: https://github.com/haskell/hackage-server/issues [3] [github site]: https://github.com/haskell/hackage-server [4] We are mirroring packages from the old server (every 30min) so it is suitable to use as your main hackage server with some caveats: we are allowing package authors to upload (as well as doing the mirroring) so you may find a slightly different set of packages on this server. If you are a package author then you are welcome to poke about and upload packages. We have imported user accounts from the old server (except for a small number of early adopters of the original server who will need to contact an administrator). Note that before we do the final switchover we will *delete everything* from the beta instance and do a fresh import from the old hackage server. Configuring cabal-install - Edit your ~/.cabal/config file. Comment-out the existing remote-repo line near the top of the file and add in a new one like this: --remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive [5] remote-repo: beta.hackage.haskell.org:http://beta.hackage.haskell.org/ [1] New features Though our main priority has been feature parity so that we can switch over, volunteers have contributed several new features, including better package search, a new site theme, improved security, the ability to fix package dependencies after a release, changelogs, and a REST-style interface. See the beta site for more details on these new features, plus details of other features that are partially implemented or are in need of improvement. [new features]: http://beta.hackage.haskell.org/new-features [6]
Re: [Haskell-cafe] Proposal: New syntax for Haskell
+1 Cucumber seems to be great if you mainly want to read your code over the telephone, distribute it via national radio broadcast, or dictate it to your secretary or your voice recognition software. You can program thus without having to use you fingers. You can lie on your back on your sofa, close your eyes, and utter your programs... We could have blind Haskell/Cucumber programming contests... Tons of new possiblilities... Strongly support this proposal. ;-) Andreas On 2013-09-10 22:57, Artyom Kazak wrote: On Wed, 11 Sep 2013 00:20:26 +0400, Thiago Negri evoh...@gmail.com wrote: I hope these jokes do not cause people to be afraid to post new ideas. Agreed. I would also like to clarify that my message was much more a joke on the incomprehensibility of legal acts than on the original proposal. By the way, I am pretty impressed with this piece of Cucumber description/code: Scenario: Mislav creates a valid task with an upload When I go to the Awesome Ruby Yahh task list page of the Ruby Rockstars project When I follow + Add Task And I fill in Task title with Ohhh upload And I follow Attachment When I attach the file features/support/sample_files/dragon.jpg to upload_file And I press Add Task And I wait for 1 second And I should see Ohhh upload as a task name I was much more sceptical when I had only seen the example in Niklas's message. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe [1] -- Andreas Abel Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich http://www.tcs.informatik.uni-muenchen.de/~abel/ Links: -- [1] 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] Proposal: New syntax for Haskell
I've long been interested in a scripting language designed to be spoken. Not interested enough to go about making it happen... but the idea is fascinating and possibly useful. On Thu, Sep 12, 2013 at 2:57 PM, Andreas Abel andreas.a...@ifi.lmu.dewrote: ** +1 Cucumber seems to be great if you mainly want to read your code over the telephone, distribute it via national radio broadcast, or dictate it to your secretary or your voice recognition software. You can program thus without having to use you fingers. You can lie on your back on your sofa, close your eyes, and utter your programs... We could have blind Haskell/Cucumber programming contests... Tons of new possiblilities... Strongly support this proposal. ;-) Andreas On 2013-09-10 22:57, Artyom Kazak wrote: On Wed, 11 Sep 2013 00:20:26 +0400, Thiago Negri evoh...@gmail.com wrote: I hope these jokes do not cause people to be afraid to post new ideas. Agreed. I would also like to clarify that my message was much more a joke on the incomprehensibility of legal acts than on the original proposal. By the way, I am pretty impressed with this piece of Cucumber description/code: Scenario: Mislav creates a valid task with an upload When I go to the Awesome Ruby Yahh task list page of the Ruby Rockstars project When I follow + Add Task And I fill in Task title with Ohhh upload And I follow Attachment When I attach the file features/support/sample_files/dragon.jpg to upload_file And I press Add Task And I wait for 1 second And I should see Ohhh upload as a task name I was much more sceptical when I had only seen the example in Niklas’s message. ___ Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe -- Andreas Abel Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich http://www.tcs.informatik.uni-muenchen.de/~abel/ ___ 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] Proposal: New syntax for Haskell
On Thu, Sep 12, 2013 at 6:00 PM, David Thomas davidleotho...@gmail.comwrote: I've long been interested in a scripting language designed to be spoken. Not interested enough to go about making it happen... but the idea is fascinating and possibly useful. http://en.wikipedia.org/wiki/Shakespeare_(programming_language) ? :) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GLFW not working in Cabal 1.18
On 13-09-10 09:27 PM, Thiago Negri wrote: The package GLFW is not building in Cabal 1.18. Setup.hs [1] depends on `rawSystemStdInOut` [2] that changed signature between 1.16 and 1.18. Consider cabal install --cabal-lib-version=1.16. Replace 1.16 by the correct number. Use ghc-pkg list Cabal to find the correct number. http://www.haskell.org/haskellwiki/PVP allows 1.16-1.18 to change public API. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: New syntax for Haskell
Have you tried AppleScript? I wouldn't say it's pleasant to use, but it's
easy to read.
On Thursday, September 12, 2013, David Thomas wrote:
I've long been interested in a scripting language designed to be spoken.
Not interested enough to go about making it happen... but the idea is
fascinating and possibly useful.
On Thu, Sep 12, 2013 at 2:57 PM, Andreas Abel
andreas.a...@ifi.lmu.dejavascript:_e({}, 'cvml',
'andreas.a...@ifi.lmu.de');
wrote:
**
+1
Cucumber seems to be great if you mainly want to read your code over the
telephone, distribute it via national radio broadcast, or dictate it to
your secretary or your voice recognition software. You can program thus
without having to use you fingers. You can lie on your back on your sofa,
close your eyes, and utter your programs...
We could have blind Haskell/Cucumber programming contests...
Tons of new possiblilities...
Strongly support this proposal. ;-)
Andreas
On 2013-09-10 22:57, Artyom Kazak wrote:
On Wed, 11 Sep 2013 00:20:26 +0400, Thiago Negri evoh...@gmail.com
javascript:_e({}, 'cvml', 'evoh...@gmail.com'); wrote:
I hope these jokes do not cause people to be afraid to post new ideas.
Agreed. I would also like to clarify that my message was much more a joke
on
the incomprehensibility of legal acts than on the original proposal.
By the way, I am pretty impressed with this piece of Cucumber
description/code:
Scenario: Mislav creates a valid task with an upload
When I go to the Awesome Ruby Yahh task list page of the Ruby
Rockstars project
When I follow + Add Task
And I fill in Task title with Ohhh upload
And I follow Attachment
When I attach the file features/support/sample_files/dragon.jpg to
upload_file
And I press Add Task
And I wait for 1 second
And I should see Ohhh upload as a task name
I was much more sceptical when I had only seen the example in Niklas’s
message.
___
Haskell-Cafe mailing listhaskell-c...@haskell.org javascript:_e({}, 'cvml',
'Haskell-Cafe@haskell.org');http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Andreas Abel Du bist der geliebte Mensch.
Theoretical Computer Science, University of Munich
http://www.tcs.informatik.uni-muenchen.de/~abel/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org javascript:_e({}, 'cvml',
'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] dns library version 1.0.0
Hi all, I have released dns library version 1.0.0. This version provides new APIs. Thus, version is now 1.0.0. The design and implementation was done by Michael Orlitzky based on his experience. Enjoy! --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring
On 09/11/13 19:37, John Lato wrote: I didn't see this message and replied privately to Michael earlier, so I'm replicating my comments here. 1. Sooner or later I expect you'll want something like this: class LooseMap c el el' where lMap :: (el - el') - c el - c el' It covers the case of things like hashmaps/unboxed vectors that have class constraints on elements. Although maybe LooseFunctor or LFunctor is a better name. Probably something similar for Traversable would be good also, as would a default instance in terms of Functor. 2. IMHO cMapM_ (and related) should be part of the Foldable class. This is entirely for performance reasons, but there's no downside since you can just provide a default instance. 3. I'm not entirely sure that the length* functions belong here. I understand why, and I think it's sensible reasoning, and I don't have a good argument against it, but I just don't like it. With those, and mapM_-like functions, it seems that the foldable class is halfway to being another monolithic ListLike. But I don't have any better ideas either. If monolithic classes bother you, my monoid-subclasses package manages to break down the functionality into several classes. One big difference is that everything is based off Monoid rather than Foldable, and that has some big effects on the interface. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestring map/zipWith rationale
On Thu, Sep 12, 2013 at 12:44 PM, Nicolas Trangez nico...@incubaid.com wrote: I did use that a couple of times (`xor`ing 2 ByteStrings together), and was surprised by the omission back then, but IIRC (can't validate now), there's a specialised zipWith (as proposed) in the module (with some other name, obviously), which is not exported, but used when you 'pack' the result of 'zipWith' when the result is '[Word8]'... You might want to look into that. This is correct - there is a RULES pragma that rewrites `pack (zipWith f)` into a more efficient `zipWith'` function of the type desired (see the bytestring package). I was very concerned about this when writing lots of bytestring xor code for crypto-api and was pleased to find that, if the syntactic form matches, things get optimized as you desire. Thomas Nicolas On Sep 12, 2013 8:11 PM, John Lato jwl...@gmail.com wrote: Carter: we don't have both. We have one function from each category. My guess is nobody's ever really needed a really fast zipWith :: (Word8-Word8-Word8) - ByteString - ByteString - ByteString; that's the only reason I can think of for its omission. On Thu, Sep 12, 2013 at 10:45 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Scott: benchmark the two and you'll see why we have both :-) On Thursday, September 12, 2013, Scott Lawrence wrote: On Thu, 12 Sep 2013, Tom Ellis wrote: On Thu, Sep 12, 2013 at 09:21:20AM -0400, Scott Lawrence wrote: Something's always bothered me about map and zipWith for ByteString. Why is it map :: (Word8 - Word8) - ByteString - ByteString but zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] Well, what if you wanted to zipWith a function of type Word8 - Word8 - Foo instead of Word8 - Word8 - Word8? Then I would do what I do with map, and call `unpack` first. Either of the two options is usable: map :: (Word8 - Word8) - ByteString - ByteString zipWith :: (Word8 - Word8 - Word8) - ByteString - ByteString - ByteString (or) map :: (Word8 - a) - ByteString - [a] zipWith :: (Word8 - Word8 - a) - ByteString - ByteString - [a] I just don't understand why we have one from each. -- Scott Lawrence ___ 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 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Package compatibility (SemVer, PVP, ECT)
I've just read Semantic Versioning (SemVer) [1], Package Versioning Policy (PVP) [2] and Eternal Compatibility in Theory (ECT) [3]. Is PVP the one that every package on Hackage should use? SemVer seems to make more sense to me. Also, ECT looks very promising, but it is dated back to 2005 and I didn't see any package using it. Why? If Cabal could map the package version number to the versioned module name, there will be no need to uglify the client code. I mean, when I import module A and define in dependencies a == 1.8.3, Cabal would map that to module A_7 and bind that to the A I've imported. We would be locked in with Cabal, but that seems to be a good tradeoff. [1] http://semver.org [2] http://www.haskell.org/haskellwiki/Pvp [3] http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/EternalCompatibilityInTheory ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring
On Thu, Sep 12, 2013 at 2:37 AM, John Lato jwl...@gmail.com wrote:
I didn't see this message and replied privately to Michael earlier, so I'm
replicating my comments here.
Sorry about that, I wrote to you privately first and then thought this
might be a good discussion for the cafe.
1. Sooner or later I expect you'll want something like this:
class LooseMap c el el' where
lMap :: (el - el') - c el - c el'
It covers the case of things like hashmaps/unboxed vectors that have
class constraints on elements. Although maybe LooseFunctor or LFunctor is
a better name.
Probably something similar for Traversable would be good also, as would a
default instance in terms of Functor.
That's interesting. It's quite similar to the CanMap[1] class in
classy-prelude or Each from lens, except it can drop a type parameter and
the fundeps by requiring the container to be polymorphic. If we're willing
to use more exotic extensions, ConstraintKinds could be useful as well:
class ConstrainedMap t where
type MapConstraint t e :: Constraint
cMap :: (MapConstraint t e1, MapConstraint t e2) = (e1 - e2) - t e1
- t e2
instance ConstrainedMap Set.Set where
type MapConstraint Set.Set e = Ord e
cMap = Set.map
One reason I'd definitely not want to call this anything with the name
Functor in it is because Set.map can violate the Functor laws, in
particular:
Set.map (f . g) /= Set.map f . Set.map g
I believe the only law that could be applied to Set.map would be:
Set.map f = Set.fromList . List.map f . Set.toList
I would presume this would generalize to any other possible instance.
One final idea would be to take your LooseMap and apply the same kind of
monomorphic conversion the rest of the library uses:
class MonoLooseMap c1 c2 | c1 - c2, c2 - c1 where
mlMap :: (Element c1 - Element c2) - c1 - c2
instance (Ord e1, Ord e2) = MonoLooseMap (Set.Set e1) (Set.Set e2) where
mlMap = Set.map
Of all of them, ConstrainedMap seems like it would be the most
user-friendly, as error messages would just have a single type parameter.
But I don't have any strong leanings.
[1]
http://haddocks.fpcomplete.com/fp/7.4.2/20130829-168/classy-prelude/ClassyPrelude-Classes.html#t:CanMap
2. IMHO cMapM_ (and related) should be part of the Foldable class. This
is entirely for performance reasons, but there's no downside since you can
just provide a default instance.
Makes sense to me, done. By the way, this can't be done for sum/product,
because those require a constraint on the Element.
3. I'm not entirely sure that the length* functions belong here. I
understand why, and I think it's sensible reasoning, and I don't have a
good argument against it, but I just don't like it. With those, and
mapM_-like functions, it seems that the foldable class is halfway to being
another monolithic ListLike. But I don't have any better ideas either.
I agree here, but like you said in (2), it's a performance concern. The
distinction I'd make from ListLike is that you only have to define
foldr/foldl to get a valid instance (and even that could be dropped to just
foldr, except for conflicts with the default signatures extension).
As to the bikeshed color, I would prefer to just call the classes
Foldable/Traversable. People can use qualified imports to disambiguate
when writing instances, and at call sites client code would never need
Data.{Foldable|Traversable} and can just use these versions instead. I'd
still want a separate name for Functor though, since it's in the Prelude,
so maybe it's better to be consistent. My $.02.
I prefer avoiding the name conflict, for a few reasons:
- In something like ClassyPrelude, we can export both typeclasses
without a proper if they have separate names.
- Error messages and documentation will be clearer. Consider how the
type signature `ByteString - foo` doesn't let you know whether it's a
strict or lazy bytestring.
- I got specific feedback from Edward that it would be easier to include
instances for these classes if the names didn't clash with standard
terminology.
- It leaves the door open for including this concept upstream in the
future, even if that's not the goal for now.
On Wed, Sep 11, 2013 at 3:25 PM, Michael Snoyman mich...@snoyman.comwrote:
That's really funny timing. I started work on a very similar project just
this week:
https://github.com/snoyberg/mono-traversable
It's not refined yet, which is why I haven't discussed it too publicly,
but it's probably at the point where some review would make sense. There's
been a bit of a discussion on a separate Github issue[1] about it.
A few caveats:
- The names are completely up for debate, many of them could be
improved.
- The laws aren't documented yet, but they mirror the laws for the
polymorphic classes these classes are based on.
- The Data.MonoTraversable module is the main module to look at. The
other two are far
Re: [Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring
On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević blama...@acanac.net wrote: On 09/11/13 19:37, John Lato wrote: I didn't see this message and replied privately to Michael earlier, so I'm replicating my comments here. 1. Sooner or later I expect you'll want something like this: class LooseMap c el el' where lMap :: (el - el') - c el - c el' It covers the case of things like hashmaps/unboxed vectors that have class constraints on elements. Although maybe LooseFunctor or LFunctor is a better name. Probably something similar for Traversable would be good also, as would a default instance in terms of Functor. 2. IMHO cMapM_ (and related) should be part of the Foldable class. This is entirely for performance reasons, but there's no downside since you can just provide a default instance. 3. I'm not entirely sure that the length* functions belong here. I understand why, and I think it's sensible reasoning, and I don't have a good argument against it, but I just don't like it. With those, and mapM_-like functions, it seems that the foldable class is halfway to being another monolithic ListLike. But I don't have any better ideas either. If monolithic classes bother you, my monoid-subclasses package manages to break down the functionality into several classes. One big difference is that everything is based off Monoid rather than Foldable, and that has some big effects on the interface. I'd point out what I'd consider a bigger difference: the type signatures have changed in a significant way. With MonoFoldable, folding on a ByteString would be: (Word8 - b - b) - b - ByteString - b With monoid-subclasses, you get: (ByteString - b - b) - b - ByteString - b There's certainly a performance issue to discuss, but I'm more worried about semantics. Word8 tells me something very specific: I have one, and precisely one, octet. ByteString tells me I have anywhere from 0 to 2^32 or 2^64 octets. Yes, we know from context that it will always be of size one, but the type system can't enforce that invariant. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
