- Libraries - Haskell.org

Re: 2014 Applicative => Monad proposal
by David Luposchainsky 30 May '13

30 May '13

Hey everyone, here's a short summary of what's happened during the AMP's first week: - Adding `join` to the Monad typeclass introduces a cyclic dependency, leading to an infinite loop if the function definitions are forgotten. Until this is solved, the `join` part of the proposal may not be a good idea. Ticket #7633 solves this problem by introducing compiler warnings if the minimal complete definition is not met. Looking at the Trac page, it's probably going to be in HEAD quite soon. - Apart from the `join` issue, everyone seems to be in favor of the AMP as proposed. (+19/-0 according to Ben's writeup) - A `Pointed` typeclass discussion emerged from the AMP thread with mixed opinions. If necessary, this should be made a separate proposal. - I was asked about MonadFail by multiple people via email. Again, the reason this is not considered in the AMP is that it is orthogonal to the proposed changes; the only similarity is that it changes things in the same typeclass we're already editing. So long, David

1 0

ANN stm-chans 2.1 / 3.0
by wren ng thornton 30 May '13

30 May '13

-------------------------------------------- -- stm-chans 2.1 / 3.0 -------------------------------------------- The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.{TChan,TQueue} but with additional features. -------------------------------------------- -- Changes (since 2.0.0) -------------------------------------------- By popular demand, the functions newBroadcastTMChan{,IO} have been added. However, these rely on newBroadcastTChan{,IO} which are only available in stm >= 2.4 and do not appear to be replicable using the public API of stm < 2.4. Thus, the minimum version of stm is now 2.4, which obviates all the compatibility modules. Version 2.1.0 adds the new functions and issues deprecation warnings about using the compatibility modules. This version is just to help people transition. If you can use this version without warnings (i.e., you don't use the Compat modules directly) then you should be able to use version 3.0 as well. Version 3.0 removes the compatibility modules. -------------------------------------------- -- Long description -------------------------------------------- In particular stm-chans offers the following data types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. * Control.Concurrent.STM.TMQueue: Closeable FIFO queues. Like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. * Control.Concurrent.STM.TBMQueue: Bounded Closeable FIFO queues. Combines the capabilities of TBChan and TMChan. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren

1 0

PolyKinds, Control.Category and GHC 7.6.1
by Edward Kmett 30 May '13

30 May '13

Would it be possible to add something like {-# LANGUAGE CPP #-} #if defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 704 {-# LANGUAGE PolyKinds #-} #endif to the top of Control.Category before the 7.6.1 final release? Control.Category.Category is pretty much the only type in base that directly benefits from PolyKinds without any code changes, but without enabling the extension there nobody can define categories for kinds other than *, and most interesting categories actually have more exotic kinds. I only noticed that it wasn't there in the release candidate just now. -Edward Kmett

5 11

ANN: hsbencher-1.1, with Fusion Table upload
by Ryan Newton 30 May '13

30 May '13

I'm pleased to announce a new benchmarking framework, HSBencher. It's an early prototype, but it's flexible, extensible and uploads benchmark data to Google Fusion Tables. Right now the fusion table upload depends on a pre-release version of "handa-gdata" (0.6.2), which you can get at one of these locations: https://code.google.com/p/hgdata/ https://github.com/rrnewton/hgdata_mirror (It should be released soon.) Here's a blog post explaining HSBencher's usage: http://parfunk.blogspot.com/2013/05/towards-cloud-based-crowd-sourced.html Hackage: http://hackage.haskell.org/package/hsbencher Github (see README) https://github.com/rrnewton/hsbencher

1 0

Re: Who may vote
by wren ng thornton 29 May '13

29 May '13

On 5/26/13 11:40 AM, Joachim Breitner wrote: > I assume that everyone involved here has a hackage account, or would not > mind getting one. How about a small web app on hackage.org that allows > everyone (with an account) to start a poll, or to extend a poll with > additional options, and to vote on the poll. I'm all for making polls, even if just to simplify the bookkeeping rather than to be anything more official. However, adding options to a poll in progress is treacherous; how should pre-change responses be tallied? -- Live well, ~wren

2 1

summary of 2013-05 proposals
by Ben 29 May '13

29 May '13

i just got a new keyboard and i thought i'd break it in by typing up a summary of the proposals that have come on the libraries mailing list in may 2013. i expected this might be a little annoying so i adopted my "don't grade angry" method from my graduate student days, where every time i got frustrated got i'd have a swig of beer. five days and a huge headache later..... i apologize in advance if i've missed a proposal, or an important point, or have misrepresented someone's opinion or vote. i've done my best but the process is entirely manual and i'm sure strewn with errors and miscounts. if you want me to make corrections, please email me (personally) and i'll correct and send again. best, ben as of 2013-05-27 links to the mailing list have an implicit http://www.haskell.org/pipermail/libraries prefix ---------- 2013-05-10 niklas hambüchen proposes "Control.Monad.whenJust :: Monad m => Maybe a -> (a -> m ()) -> m ()" - /2013-May/019775.html ---------- * adam vogt et al : this is a monomorphic Data.Foldable.for_ ** others : for_ is confusing *** gabriel gonzalez : i'll write a tutorial *** petr pudlak : hoogle finds for_, forM_ *** chris seaton : create a dummy module which points people to the polymorphic functions *** gwern branwen : add hlint hints to help people find for_ **** henning thielemann : neil mitchell was hesitant to recommend functions for Data.Foldable ** ben millwood et al : there are import conflicts with Data.Foldable, mtl * andreas abel : links to previous discussions 2013-May/019794.html for : niklas h, kudah k, evan l against : ganesh s, henning t, john w, edward k, simon h, andreas a, ivan m, bardur a, dan d, david l, ben g, merijn v, carter s, oliver c, casey m, felipe l, anthony c, ben l, gershom b, gabriel g, nikita v, vincent h, herbert r, malcolm w, andrea v, ian l, jake m, brandon a, mario b, wren t +3/-30 ---------- 2013-05-13 felipe lessa proposes "Data.Maybe.whenJust :: Monad m => Maybe a -> (a -> m ()) -> m ()" - 2013-May/019793.html ---------- for : felipe l, andreas a +2/-0 ---------- 2013-05-13 wren ng thorton proposes changing newBroadcastTChanIO to match newBroadcastTChan in stm-2.4.2 - 2013-May/019808.html ---------- for : wren t, edward k, john w +3/-0 ---------- 2013-05-15 edward kmett proposes moving Foldable and Traversable into Prelude and retiring their monomorphic counterparts - 2013-May/019815.html ---------- * bas van dijk : immediately change or deprecate and warn? * henning thielemann : it's not backwards compatible; it's better to import from modules instead of adding to Prelude; it's not beginner friendly; there are multiple generalizations; it requires type annotations * gabriel gonzalez : these are not the only generalizations ** edward k : these generalizations are haskell 98, with good type inference * edward k : should not break too much, Applicative => Monad will make a lot of the combinators go away * edward k : Foldable/Traversable don't require heavy machinery * david luposchainsky : provide warnings for not using Foldable/Traversable, Functor / Applicative => Monad? * oliver charles et al : polymorphic functions were easier to learn as a beginner * conrad parker et al : alternative languages / Preludes for beginners? (Helium?) * casey mccann : language should NOT be designed for beginners; Num is already in Prelude * edward k, ian l : can change Prelude but keep haskell98/2010 the same for teachers (split base) * mark lentczner : we should run changes over hackage * mark lentczner et al : mtl reimports suck ** edward k : i'd be happy to change that * edward k : concrete proposal 2013-May/020093.html online poll https://docs.google.com/forms/d/1lKckA0pA6K4uQ-UnnmjRR32PKHph0WeZoQeVTTQJZ4… results https://docs.google.com/forms/d/1lKckA0pA6K4uQ-UnnmjRR32PKHph0WeZoQeVTTQJZ4… for : edward k, bas van d, petr p, david l, john w, andreas a, tom ?, ben l, carter s, dan d, ben g, merijn v, oliver c, casey m, felipe l, anthony c, gershom b, gabriel g, nikita v, vincent h, herbert r, andrea v, jake m, john l (changed), brandon a, mario b, wren t against : henning t, ganesh s, malcolm w, ivan m +27/-4 ---------- 2013-05-15 john lato (rhetorically) proposes making Functor a superclass of Monad - 2013-May/019822.html ---------- for : edward k, carter s, ben l +3/-0 ---------- 2013-05-16 vincent hanquez proposes adding bSwap : a -> a to Bits - 2013-May/019824.html ---------- * henning thielemann : consider "swap" * edward kmett : consider "byteSwap" or "byteswap" * henning thielemann : shouldn't this be an Endian thing instead of Bits? * vincent hanquez : this is to expose new primops (ticket 7902) * ian lynagh : just add the primops and leave the interface to libraries ** vincent hanquez : sounds good to me votes are waiting for new proposal? ---------- 2013-05-16 david luposchainsky proposes adding Applicative/Functor instances to all Monads in GHC - 2013-May/019839.html ---------- * bas van dijk : i did this before (see ticket 4834) * ian lynagh : this doesn't actually help with future proofing ghc * david luposchainsky : can we add a compiler warning for missing instances? for : david l, bas van d, edward k, andreas a, oliver c, john w, gabriel g, carter s, conal e, kazu y, henning t, federico m, wren t neutral : ian l +13/-0 ---------- 2013-05-16 austin seipp revives edward kmett's proposal to add PolyKinds to Control.Category - 2013-May/019845.html ---------- for : austin s, simon p-j, edward k, +3/-0 ---------- 2013-05-18 ian lynagh proposes just removing the monomorphic counterparts to Foldable and Traversable from Prelude - 2013-May/019871.html ---------- for : ian l, john l, herbert r, oliver c, ben l, malcolm w, ivan m, wren t against : henning t, edward k, tom?, dan d, david l, merijn v, carter s, casey m, felipe l, anthony c, gershom b, gabriel g, nikita v, john w, vincent h, herbert r, andrea v, jake m, brandon a, andreas a +8/-20 ---------- 2013-05-20 ben gamari revives gabriel gonzalez's proposal for a stricter WriterT - 2013-May/019898.html ---------- * ross patterson : just deprecate Writer.Strict in favour of State.Strict ? for : ben g, gabriel g, david l +3/-0 ---------- 2013-05-21 wren ng thorton proposes "burning bridges" - 2013-May/019902.html ---------- * wren ng thorton : promote Foldable/Traversable, Applicative => Monad, etc. ** not fixing numeric hierarchy, partial functions in spec, MPTC vs type families, etc. * felipe lessa : need python 3-style refactoring tool * simon peyton-jones : split base should help with backwards compatability shims * mark lentczner : should chunk incompatible changes every couple of years * john lato : someone should write up a single new proposal * ian lynagh : http://hackage.haskell.org/trac/ghc/wiki/HackageTesting * wren t : Prelude exists because the definition of Haskell (e.g. do-notation) is circular for : wren t, conrad p maybe for? : mark l, john l, herbert r, carter s, edward k, against : gabriel g, edward k +7?/-2 ---------- 2013-05-22 ian lynagh reproposes : monomorphic "whenJust", moving Foldable/Traversable into Prelude, removing said from Prelude, doing Nothing - 2013-May/019953.html ---------- * votes will be added to the previously listed proposals votes for doing Nothing : for : malcolm w against : tom ?, edward k, dan d, david l, ben g, merijn v, carter s, oliver c, casey m, felipe l, anthony c, ben l, gershom b, gabriel g, nikita v, john w, vincent h, herbert r, andrea v, jake m, ivan m, john l, brandon a, mario b, andreas a, wren t +1/-26 ---------- 2013-05-23 david luposchainsky proposes Applicative => Monad - 2013-May/020021.html ---------- https://github.com/quchen/articles/blob/master/applicative_monad.md http://hpaste.org/88423 * nicholas trangez : http://hackage.haskell.org/trac/ghc/ticket/7633 can help with "minimal definitions" for : david l, henning t, dan b, edward k, jeremy s, stephen t, ben m, bas van d, ivan m, dan d, john l, bardur a, carter s, ganesh s, petr p, john w, roman c, andreas a, mario b +19/-0 ---------- 2013-05-13 shachaf ben-kiki reminds us of his "minimal instance" proposal - 2013-May/020025.html ---------- http://hackage.haskell.org/trac/ghc/ticket/7633 for: shachaf b-k, henning t, dan b, john lato, petr p, andreas a +6/-0 ---------- 2013-05-23 simon peyton-jones proposes creating a library tsars committee - 2013-May/020006.html ---------- for : simon p-j, edward k, shachaf b-k, andreas a against : tom ? (for Foldable/Traversable) +4/-0 ---------- 2013-05-23 jeremy shaw proposes adding Pointed - 2013-May/020029.html ---------- * ben millwood : http://www.haskell.org/haskellwiki/Why_not_Pointed? for : jeremy s, henning t, andreas a, john l against : ben m, dan b, edward k, roman c, wren t, david l, gabriel g, dan d, john w (changed), petr p +4/-10 ---------- 2013-05-23 jeremy shaw proposes adding MonadFail - 2013-May/020029.html ---------- for : jeremy s, henning t, dan b +3

3 3

Re: Making decisions
by wren ng thornton 29 May '13

29 May '13

On 5/25/13 10:19 AM, Ryan Newton wrote: > I'm a refugee from Scheme-istan. Most important to me are not the specific > technical outcomes, but that a sense of community cohesiveness survives, > avoiding, for example the post-R6RS affair (divergent R7Rs, Racket split). I'm not a Schemer, but I definitely sympathize. FWIW, I've always considered the +1/-1 posts to be more along the lines of reddit; i.e., I dis-/like this proposal but don't have anything substantial to add. However, more recently, the +1/-1 posts have tended to come across as something more like "voting" ...which, as others have mentioned, is problematic at best. I've worked with a few consensus-based nonprofits and co-ops, so I have some feel for the complexities involved in establishing official decision mechanisms, whether they be voting-based or consensus-based. So far, we've gotten by pretty well with the benevolent dictator model of just feeling the community out and then doing stuff. But I wonder if the community has gotten too large for this to continue, which may be why the feeling behind +1/-1 posts has been shifting towards this terminology of "voting". That could also explain why (IMHO) some of the discussions on this list have been getting more contentious--- in voting models people tend to feel like they need to shout louder in order to be heard, while simultaneously feeling like they have less and less of a say in the outcome (which leads to shouting of another sort). This is all just vague musing at the moment. I've always enjoyed the friendliness and conscientiousness of the Haskell community, and it'd be nice to keep that. But maybe it is time to move to a more official mechanism of decision making; if so, then what sort of mechanism do we want? Simon has suggested an extension of the benevolent dictator model, with a small committee making the final call. I've always been a fan of consensus methods since they do a good job of airing different perspectives and coming to decisions that don't fracture the community or encourage partisanship. Most of us are familiar with voting models of various sorts. Each of these models has its ups and downs; regardless, it's something to think about before just picking one. -- Live well, ~wren

2 1

Lista dos aprovados divulgada Batalha
by Edson 29 May '13

29 May '13

Lista dos aprovados divulgada Batalha: Porto Esperidião: ALINE PEREIRA NUNES, LARISSA DE MORAIS VIANA, FERNANDO DA SILVA GUEDELHA, NEDIA ALVES PARRIAO, JOÃO CARLOS MOREIRA DE CARVALHO, CLAUDIO SIMÕES RODRIGUES, MARIA DA CONCEIÇÃO SILVA, ISAIAS JESUS DE ALMEIDA. RUTH KELLY RIPARDO, ELIANE VIRGÍNIO DE SIQUEIRA NASCIMENTO, MATHEUS FRANCO FRAGA, JOSE VITOR LUSTOSA DA SILVA, VIRGINIA GADELHA DOS SANTOS. Jatobá. Batalha, ANA PAULA RODRIGUES DA SILVA, LUCAS ARAUJO GOMES FROTA, GABRIEL VICTOR BARROS FORTE DA SILVA, QUITÉRIA DA SILVA GÓIS, JOÃO CARLOS MOREIRA DE CARVALHO, DAYANA MARIA DE SOUSA TAVARES, MARIA JULIENE CORDEIRO, JOÃO PAULO DA SILVA. TALITA FERNANDES GONCALVES, BRUNO RAMOS FERNANDES, LUIZ HENRIQUE ALVES DAMASCENO, IAGO DA SILVA NOBRE, RITA ANGELA DA SILVA. Cabo Verde. Nilo Peçanha e ANA MARA DE SOUSA PEREIRA, LUANA FERNANDA FERNANDES ANDRADE, FRANCISCO ROGER GARCIA DE ALMEIDA, POLLYANNA DE O, JOÃO CARLOS MOREIRA DE CARVALHO, DANIELLA FERNANDES DA SILVA, MARIA JOSÉ DA SILVA FERREIRA, JÉSSICA VENTURA FREIRE. SOLANGE PAULINO CORREIA, BRUNA KETHEY DA SILVA PEIXOTO, LUIS HENRIQUE FREITAS GOMES, HELIO SOARES DE ARAUJO, RENER QUEIROZ VIEIRA. Itaguaru.

1 0

Re: Etcetera (was Re: Burning bridges)
by wren ng thornton 29 May '13

29 May '13

On 5/26/13 12:38 AM, Mario Blaević wrote: > On 22/05/13 08:12 AM, Ian Lynagh wrote: >> On Wed, May 22, 2013 at 11:49:29AM +0800, John Lato wrote: >>> I suggest that we start a poll for a single, concrete proposal. If the >>> poll forum is by email or similar, I further suggest that replies be >>> limited strictly to +1/-1. >> I think there are 4 things it has been suiggested that we might do: >> * Generalise Prelude.mapM etc > > I've already given my +1 to this proposal, and I'm not likely to > change my opinion. I have to say, though, that the "etc" above is a > little sneaky. Now that the proposal has been overwhelmingly accepted, > can we narrow it down? I can see four different interpretations of the > "etc": > > 0. empty string; > 1. "mapM_, sequence, and sequence_"; > 2. intersection of exports of Prelude, Foldable, and Traversable, which > would include the above and also foldl, foldr, any, all, and, or, sum, > product, maximum(By), minimum(By), concat(Map), elem, and notElem; and > 3. every existing export of Prelude that can be generalized to Foldable > or Traversable, which would be all of the above and then some others > like map, filter, length, null, takeWhile, dropWhile, span, break, take, > drop, splitAt, and probably some more. I agree with Edward Kmett's analysis; i.e., option #2 or thereabouts. Much as I'd like to see some of the others generalized (i.e., map, filter, length, null) I think that goes beyond the wording of the original proposal. Also they're not strictly Foldable/Traversable ideas, but rather belong to other classes. As per Ian Lynagh's comments, I think all the bits of Control.Monad that are restrictions of Foldable/Traversable should also be removed (or generalized as re-exports). That is, we're looking at something like: (Prelude \cup Control.Monad) \cap (Data.Foldable \cup Data.Traversable) As far as the menagerie of fold variants, I'd like to see foldl' and foldr' go along with foldl and foldr; but I don't have any particular opinion on the others. The biggest outstanding issue, I think, is how to deal with build/foldr fusion. That is, we must be sure that with all these changes we do not break fusion. That should be doable with the right incantation of inlining, but it's something we need to be sure still works. -- Live well, ~wren

1 0

Re: foldable flexible bridges (putting foldable+traversable in prelude) Re: Burning bridges
by wren ng thornton 29 May '13

29 May '13

On 5/27/13 9:24 PM, Manuel M T Chakravarty wrote: > As far as beginners and teaching goes, why don't we have two Preludes? > > (1) The real (and somewhat scary) Prelude > (2) A stripped down, less flexible, but easier to comprehend Prelude > > The DrRacket (ex DrScheme) people have language levels. We could have library levels. I'm generally a fan, though again I suggest a tripartite version: (1) The real (and somewhat scary) Prelude required by circularity of the language--- which is kept as minimal as possible, in order to reduce the problems of tight coupling between language and libraries. (2) The "real Prelude" (also somewhat scary) which has all the bells and whistles veteran Haskellers expect, but which can be altered or removed without severe repercussions for the entire ecosystem. (3) A stripped down, less flexible, but easier to comprehend "simple Prelude". -- Live well, ~wren

1 0