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/19392 <pre>The Mac OS X RC3 installers are up: Haskell Platform 2013.2.0.0 32bit rc3.signed.pkg&lt;http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2032bit%20rc3.signed.pkg&gt; Haskell Platform 2013.2.0.0 64bit rc3.signed.pkg&lt;http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2064bit%20rc3.signed.pkg&gt; Only difference in these from RC2 is that the missing documentation for network, random, and primitive has been restored. These will be the final, barring any catastrophic issue. — Mark 15dd8762c9800308cb7cfdd16ea1a8e74988e06a Haskell Platform 2013.2.0.0 32bit rc3.signed.pkg 89e6fb747816af69acabc5c04cee103257855614 Haskell Platform 2013.2.0.0 64bit rc3.signed.pkg _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Mark Lentczner 2013-05-21T16:15:58 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19391 <pre>One potentially palatable option would be to just note that incorporating these into the a Prelude can be done while leaving the haskell98 and haskell2010 packages with the current behavior. Really, it would have to. This means that in the bizarre circumstance that someone relies on the exact current behavior for teaching purposes, there is a path forward for them. -Edward On May 21, 2013, at 11:02 AM, Casey McCann &lt;cam&lt; at &gt;uptoisomorphism.net&gt; wrote: </pre> Edward Kmett 2013-05-21T15:20:28 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19390 <pre>On Tue, May 21, 2013 at 6:22 AM, Henning Thielemann &lt;lemming&lt; at &gt;henning-thielemann.de&gt; wrote: Notwithstanding that anyone having trouble with a monomorphic foldr is unlikely to be significantly worse off with the Data.Foldable version, and notwithstanding also that I've seen redundant monomorphic functions create more confusion than they seem to avoid, the base objection here is and always has been misguided at best. Being a beginner is by definition an ephemeral state; the entire purpose of being a beginner is to eventually stop being one. Don't design a language (or anything else) around the needs of beginners unless you intend that only beginners will use it, in which case one wonders why they're even bothering. - C. </pre> Casey McCann 2013-05-21T15:02:26 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19389 <pre>On Tue, May 21, 2013 at 3:20 PM, Oliver Charles &lt;ollie&lt; at &gt;ocharles.org.uk&gt; wrote: Hear hear! I am unclear why beginners can't be taught the same way as today, but only giving examples where the data types are normal lists, and then in a more advanced chapter saying "actually, mapM (or whatever) works on more data types...". That said, if 100% backward compatibility is an issue (isn't it always? :-), perhaps having a *standard* "no training wheels" prelude would solve the problem? Assuming it was trivial to switch to it in the cabal package file and not in the sources themselves. I know there is a whole bunch of prelude replacements, but that's the problem - there is a whole bunch of them. As SPJ pointed out, the "burning bridges" phrase was about switching to new libraries, not to a new language/compiler. Would it be a "flexible bridge" if there was an official community effort to create a standard prelude 2.0 file? Oren. _______________________________________________ Libraries mailing list Libraries&lt; at &gt;ha</pre> Oren Ben-Kiki 2013-05-21T14:36:04 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19388 <pre> I would be interested to see a real example of existing code of anywhere near production quality that would break due to type inference issues. For breakage to happen, the combinators must be used in such a way that [] cannot be inferred by other means and an appropriate Foldable/Traversable constraint cannot simply be inferred instead. Neither class provides a means for constructing values of an instance type ex nihilo and lacking anything like an Unfoldable class the "show . read" situation is unlikely. Anything applied to a list will be inferred in the usual manner. Definitions with no type signature, subject to the DMR, and not used in the module that defines them should be excluded by "anywhere near production quality". Short of folding a list which was constructed entirely by way of MonadPlus or similar I can't see where problems would arise. Am I missing something here? Beyond that, the argument that having redundant, less-polymorphic versions of standard combinators is helping beginners has not b</pre> Casey McCann 2013-05-21T14:33:33 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19387 <pre>On Tue, May 21, 2013 at 12:26 PM, Henning Thielemann &lt;lemming&lt; at &gt;henning-thielemann.de&gt; wrote: Then you've never done this, at least not in combination with the mtl. You need at least two imports to import the generalized mapM_ etc: import Prelude hiding (mapM_) import Data.Foldable (mapM_) With mtl (one of the most used packages in the Haskell ecosystem, I'd guess) you additionally need: import Control.Monad.State hiding (mapM_) import Control.Monad.Reader hiding (mapM_) Etcetera etcetera. It's definitely not impossible, but it's a lot harder than 'just, that you import the first one and not the other'. Another difficulty is that if you make an 'alternative prelude' including the generalized mapM_ etc, you have to use NoImplicitPrelude, whereas if your alternative prelude is just an addition, you can just import it. These are all small things, but they add up if you do day to day Haskell programming. Erik </pre> Erik Hesselink 2013-05-21T12:56:32 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19386 <pre> Perhaps such novice programmers should be taught using a Haskell subset or different language, such as Helium or Elm. Conrad. </pre> Conrad Parker 2013-05-21T12:24:58 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19385 <pre>On 21 May 2013 11:35, "Henning Thielemann" &lt;lemming&lt; at &gt;henning-thielemann.de&gt; wrote: fact, i've encountered *many* more are all list specific than i've seen 'fold' being higher order functions. As a Haskell beginner I actually found in confusing that once I'd learnt the prelude functions I had to learn more functions again to get to the generalised functions. I would have rather been taught the general functions in the specific frame of lists, and then show why the type signature is more general than one for lists - ocharles _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Oliver Charles 2013-05-21T12:20:06 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19384 <pre> On Tue, 21 May 2013, Carter Schonwald wrote: The Haskell beginners I know, even have problems with 'map' and even more 'fold' being higher order functions. </pre> Henning Thielemann 2013-05-21T10:22:47 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19383 <pre> On Tue, 21 May 2013, Carter Schonwald wrote: I still don't see, why Data.Foldable is less standard than Prelude. Both are in 'base'. The difference is just, that you have to import the first one and not the other one. If this is too much effort - why can't you teach your smart beginners using one of the alternative prelude projects? </pre> Henning Thielemann 2013-05-21T10:26:27 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19382 <pre> I agree with those points, however they are a little (for the lack of a better word) single-cased, therefore I'm not sure how well they transfer to new scenarios. The catch/Num transitions are on a much smaller scale than what has been discussed here after all. I think the main issue we'll have to address here is inertia, more specifically how much more people value inertia over the proposed changes, no matter how good they are. I'm just going to throw this idea out there: what would you think about adding warnings to GHC specifically for the transition, think of meta-deprecations? Examples: - Use the (more) polymorphic functions from Foldable/Traversable - Please also define Functor/Applicative for your Monad Potential benefits: - During the GHCi-based workflow that I use, as I am sure many others do, this would help me not to forget or ignore doing these things. Sometimes it may be more convenient just to take what Prelude gives me (call it the "whatever, it works for now" attitude), but when a war</pre> David Luposchainsky 2013-05-21T09:31:46 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19381 <pre>well said, On Tue, May 21, 2013 at 2:57 AM, Edward Kmett &lt;ekmett&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Carter Schonwald 2013-05-21T07:25:58 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19380 <pre>I raised the issue mostly to remind everyone that it still existed and that the status quo is quite awkward. I was going to let this rest, but as it seems to still be stirring up a passionate response, I felt it necessary to reply again. I do strongly believe that bringing Foldable and Traversable into the Prelude and replacing the monomorphic variants would actually be a fairly painless change. During the transition some people would be forced to manage explicit import lists for their packages. We've paid for this with 'catch', the 'Num' transition, 'Bits', etc. and we're pretty good at managing this sort of change by now. Type inference has been raised as a factor, but I respectfully disagree that is is a problem in practice with (the bulk of) this proposal. A case may definitely be made that perhaps a few of the combinators, e.g. concat and concatMap should remain monomorphic, but by and large I feel it would dramatically reduce import confusion to only have *base* only contain one version of each comb</pre> Edward Kmett 2013-05-21T06:57:14 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19379 <pre>The issue with a more generalized Functor is that inference _does_ suffer for it and moreover it takes you outside of Haskell 98/2010/prime by requiring MPTCs (and to be honest, fundeps/TFs to make it suck less.) The very loose proposal put forward remains entirely within the 98+2010 garden precisely to avoid the type inference bogeyman. -Edward On Tue, May 21, 2013 at 2:06 AM, Gabriel Gonzalez &lt;gabriel439&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-21T06:34:01 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19378 <pre>| I'm generally a staunch advocate of backward compatibility. However, | these issues are ones where we've known the right answer for a long time | (unlike refactoring the numeric type class hierarchy), and we've simply | been unwilling to burn bridges in order to do the right thing. I love | Haskell, and I respect the haskell' committee, but I think it's time to | just burn it all down. ... | With all that has changed in the last 15 years, I think it's high time | to fork Haskell, tear off all the bandaids, and begin afresh. I'm not sure what you are proposing, concrete, by "fork Haskell". I think you are simply proposing some non-backward compatible library changes. Correct? And yes, it seems reasonable to do that every now and again. Indeed there's an active thread on splitting the base package http://hackage.haskell.org/trac/ghc/wiki/SplitBase, partly to make it easier to build a backward-compatible shim package. So how non-backward-compatible would it all be? I assume you guys have talked this to</pre> Simon Peyton-Jones 2013-05-21T06:22:59 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19377 <pre>Sorry, I made yet another mistake. The implementation and type should be: mapM :: (a -&gt; m b) -&gt; ListT m a -&gt; ListT m b mapM f m = m &gt;&gt;= lift . f That will not leak and is almost always what people actually want when they use `mapM`, whether or not they use `pipes` to implement `ListT`. It also obeys a different set of functor laws: mapM return = id mapM (f &gt;=&gt; g) = mapM f . mapM g Anyways, sorry for the spam. This is just to show that there are many ways you can generalize something and `Foldable`/`Traversable` are not the last word. _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Gabriel Gonzalez 2013-05-21T06:24:43 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19376 <pre> Sorry, I meant to say in my last e-mail that `mapM` would be analogous to `fmap` when using the `pipes`-based `ListT`, not `lift`. _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Gabriel Gonzalez 2013-05-21T06:09:51 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19375 <pre>For example, mapM defines a functor in the Kleisli category: mapM return = return mapM (f &gt;=&gt; g) = mapM f &gt;=&gt; mapM g So then why not have a generalized Functor class that works on arbitrary categories: class CFunctor c f where cmap :: c a b -&gt; c (f a) (f b) instance (Traversable t) =&gt; CFunctor Kleisli t where ... Or consider that `mapM` leaks space for large traversables. Another alternative generalization that doesn't leak space is to use pipes. This is not as far-fetched as it sounds, considering that `pipes` are `ListT` done right when viewed through the `RespondT` newtype: </pre> Gabriel Gonzalez 2013-05-21T06:06:13 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19374 <pre>could you elaborate on the other useful generalizations please? :-) On Tue, May 21, 2013 at 1:41 AM, Gabriel Gonzalez &lt;gabriel439&lt; at &gt;gmail.com&gt;wrote: _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Carter Schonwald 2013-05-21T05:41:29 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19373 <pre>I want to apologize to wren (and everybody else). I was tired and overreacted when the discussion started veering into making more breaking changes. I don't mind the Foldable changes too much. My main concerns are: * loss of monomorphism makes teaching more difficult * They can be generalized in other useful ways However, I don't consider those concerns show-stoppers. </pre> Gabriel Gonzalez 2013-05-21T05:41:31 http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/19372 <pre>of course things will break. Things also break in easily fixable ways every major ghc version (and that doesn't stop each new GHC major version from being progressively more awesom). And thats ok. "all of hackage" isnt an informative test. Its ok, we have a type system, we'll know exactly what to change to make it all better again, thats kinda a big upside to having a type system after all. Mostly just adding some ":: [sometypehere]" constraints and then problems solved. thats a wonderfully easy breakage, an eminently patchable one even. There will no doubt be much patching of many actively maintained libs around ghc 7.8's release anyways, so why not amortize that effort to improve prelude while we're at it? Thats a great time to improve things. On Tue, May 21, 2013 at 1:18 AM, Krzysztof Skrzętnicki &lt;gtener&lt; at &gt;gmail.com&gt;wrote: _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Carter Schonwald 2013-05-21T05:28:19 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.libraries