http://permalink.gmane.org/gmane.comp.lang.haskell.libraries hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19362 <pre> That would be slightly less transparent than the other transformers, and it wouldn't be perfectly parallel to the existing versions of WriterT: - the Applicative and Alternative instances would have different contexts - there would be no Foldable or Traversable instances On Tue, Mar 19, 2013 at 08:33:37PM -0400, Edward Kmett wrote: There are several packages like this, that pass various stuff through all the transformers. Relatively few seem to use the strict writer for itself: alms darcswatch ghc-heap-view Glob GPipe-Collada Haschoo hbayes nemesis satchmo shake storable XmlHtmlWriter I wonder if these users were expecting the linear behaviour that Gabriel was exploring. So perhaps the best thing would be to deprecate Writer.Strict in favour of State.Strict. </pre> Ross Paterson 2013-05-20T15:17:46 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19361 <pre>I agree. We might optionally consider combining two changes to `transformers`: * Adding the stricter `WriterT` * Adding `EitherT` </pre> Gabriel Gonzalez 2013-05-20T15:00:15 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19360 <pre>The question was about a Writer that basically calls seq on the mappend operation if I recall correctly? I'd be in on that. A practical example that I frequently come across is having Reader+State, but I can't use RWS because of the "mappend ()" thunk buildup when using "RWS r () s". +1 David </pre> David Luposchainsky 2013-05-20T14:01:52 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19359 <pre> It seems that this thread has died an unfortunate premature death. I, for one, would love to see this make its way upstream. Will this be happening? Cheers, - Ben </pre> Ben Gamari 2013-05-20T13:11:40 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19358 <pre> I think the conclusion of the base splitting discussion was that we should split base up, and make a new 'base' package that re-exports things from the split-up packages. Perhaps we should take this opportunity to slim down the Prelude, putting the slimmed-down version in one of the split packages, but leaving the current Prelude in the 'base' package. That way packages will continue to be able to depend on base, and get the existing Prelude, but when they switch to the split versions they will need to add imports and resolve ambiguities as necessary. Thanks Ian </pre> Ian Lynagh 2013-05-20T11:40:50 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19357 <pre> On Mon, 20 May 2013, Andreas Abel wrote: I think the Hackage category Prelude gives a good overview over such projects: http://hackage.haskell.org/package/#cat:prelude </pre> Henning Thielemann 2013-05-20T11:31:41 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19356 <pre>Maybe instead of fiddling with the current Prelude (which might break backwards compatibility), we should design a new prelude which is not automatically loaded but contains roughly the current prelude (with the list functions generalized to collections) plus the "modern" type class stack: Functor, Applicative, Monad, Foldable, Traversable, Monoid etc. I am willing to write {-# LANGUAGE NoImplicitPrelude #-} import Base if I get a decent, "modern" standard set of functions that could be considered as the base vocabulary of modern Haskell programmers... I just do not want to think about the democratic process involved in this design... Cheers, Andreas On 20.05.13 9:35 AM, Henning Thielemann wrote: </pre> Andreas Abel 2013-05-20T11:26:05 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19355 <pre> The issue here is that his would make it very hard to write backward compatible code. We already have seen this by removing Prelude.catch. GHC HQ mitigated this by making a "hidden import" a warning. But if you want -Wall-sane code you still need to always import Control.Exception qualified. Personally I'm strongly against removing the monomorphic versions without providing suitable alternatives. Cheers, Simon </pre> Simon Hengel 2013-05-20T09:47:52 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19354 <pre> On Sun, 19 May 2013, Anthony Cowley wrote: I also consider the proposal to be a pretty big thing. I am not sure that all people who are affected are aware of this discussion, especially since it happens under the subject "add whenJust". Changing the Prelude was only done for 'catch' as far as I remember. Moving Traversable and Foldable to Prelude is for me a precedent. It has more implications: I think it must also go into the Haskell 201x specification. It would mean that Traversable and Foldable are immediately in scope in every module. And what is the long-term goal? Shall Prelude contain all classes, that generalize Prelude's types? Applicative? Category? Monoid? MonadPlus? Semigroup? If you think this out, you may want not to do the first step in this direction. The reason for the proposal is really only to save writing some "import" statements for people who prefer the unqualified import style, right? I still think it is much simpler to achieve this by putting more effort in alternativ</pre> Henning Thielemann 2013-05-20T07:35:05 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19353 <pre>Well, it so far has definitely put the preponderance of weight of opinion on just replacing the definitions in the Prelude with Foldable and Traversable definitions. I do think we should probably move it to another topic, as we're definitely not talking about whenJust. (In particular a +1 on this stuff is effectively a -1 on the original topic!) On Sun, May 19, 2013 at 7:00 PM, Carter Schonwald &lt; carter.schonwald&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Edward Kmett 2013-05-20T01:15:08 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19352 <pre>Good idea, though each channel / fora seems to have slightly disjoint sub communities. On Sunday, May 19, 2013, Anthony Cowley wrote: _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Carter Schonwald 2013-05-19T23:54:54 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19351 <pre> I think this issue may be too big to rely on mailing list +1s. Is there any precedent for having a web-based poll of some sort? We often get more engagement in debates on IRC and /r/haskell than the mailing list, so let's not let the choice of forum drive the result. Anthony _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Anthony Cowley 2013-05-19T23:25:53 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19350 <pre>Do the additional votes on foldable / traversable change the outcome? On Sunday, May 19, 2013, Edward Kmett wrote: _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Carter Schonwald 2013-05-19T23:00:51 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19349 <pre>Another +1, specifically on swapping in definitions from Foldable and Traversable. To address the concern of "more trouble for beginners," it's important to note that lots of functions are defined differently in the prelude than how they're explained in intro texts. Haskell's becoming a language with excellent support for many different collection types, and imo it's almost old-fashioned to have so much in base defined as if lists are of much greater importance. Tom El May 19, 2013, a las 12:33 PM, Edward Kmett &lt;ekmett&lt; at &gt;gmail.com&gt; escribió: _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> amindfv< at >gmail.com 2013-05-19T21:46:54 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19348 <pre>+1 for Functor/Monad On May 19, 2013, at 1:59 PM, Carter Schonwald wrote: </pre> Ben 2013-05-19T21:03:50 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19347 <pre> On Sun, 19 May 2013, Carter Schonwald wrote: Can you please change the subject when you start a new discussion? It will be really hard to follow later. The discussion started with whenJust and now we are at the third or fourth proposal, depending on whether you count Ian's comment as an individual proposal. </pre> Henning Thielemann 2013-05-19T21:03:50 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19346 <pre>+1 on that functor monad bit On Thursday, May 16, 2013, Edward Kmett wrote: _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Carter Schonwald 2013-05-19T20:59:37 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19345 <pre>+1 to this proposal. On Wednesday, May 15, 2013, Edward Kmett wrote: _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Carter Schonwald 2013-05-19T20:07:35 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19344 <pre>i'm not even sure if i'm allowed to vote on proposals, having spent some time on the wiki trying to find out. also it seems i'm a few hours too late, but i feel it would be a shame for this proposal to die. i'm personally agnostic between the two positive proposals but i'll vote for the first one (fixing the Prelude) if that's what it takes to get plurality. so, if my vote counts for anything, +1 "for just fixing the Prelude to swap in the definitions from Foldable and Traversable." best, ben On May 19, 2013, at 9:33 AM, Edward Kmett wrote: </pre> Ben 2013-05-19T19:23:24 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19343 <pre>The main utility in removing the crippled versions entirely is that you don't wind up with conflict, but if they are already gone then there is no conflict (within base) in moving the existing Foldable and Traversable interfaces into the Prelude. I did say when I made the suggestion that I didn't think it'd make it past the objections, though. I'm personally against removing the existing mapM, etc. definitions from the Prelude without replacing them with the combinators from Foldable/Traversable as it would break strictly more code, and breaks a lot more combinators than you would think, concat, sum, product, etc. are all redefined in Foldable to be more general. 5 +1 votes for just fixing the Prelude to swap in the definitions from Foldable and Traversable. 3 +1 votes for removing everything that conflicts with Foldable and Traversable from the Prelude. And 2 votes against doing anything. At this point it is clear that no position has won more than a plurality of the popular opinion, so I resignedly r</pre> Edward Kmett 2013-05-19T16:33:30 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19342 <pre> I'm not sure that beginners being introduced to Monad operations will start using the sequence :: Monad m =&gt; [m a] -&gt; m [a] sequence_ :: Monad m =&gt; [m a] -&gt; m () mapM :: Monad m =&gt; (a -&gt; m b) -&gt; [a] -&gt; m [b] mapM_ :: Monad m =&gt; (a -&gt; m b) -&gt; [a] -&gt; m () operations and not need an 'import Control.Monad' real soon afterwards anyway IMHO OTOH, having those four names above defined in the global Prelude namespace makes it more cumbersome to introduce beginners to Traversable/Foldable, as you'd have to explain them how to workaround the symbol clashes by using qualified imports or Prelude-hiding imports... cheers, hvr </pre> Herbert Valerio Riedel 2013-05-19T08:56:07 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.libraries