From naesten at gmail.com Mon Jul 6 17:30:34 2009 From: naesten at gmail.com (Samuel Bronson) Date: Mon Jul 6 17:13:06 2009 Subject: what about moving the record system to an addendum? Message-ID: <878wj1lcsl.wl%naesten@gmail.com> According to , ticket #99 was rejected, but the tickets own page, , says "probably yes". Which is it? I was about to propose this myself, but decided to check the trac just in case it had already been proposed, Haskell being so popular with smart people and all, and was at first rather disappointed and ready to write an angry rant to the list, then rather confused when I noticed the ticket's page said almost the exact opposite of the Status page. In particular, I want records to be considered an extension to Haskell', to be implemented only by compilers that care, and even then only allowed with a LANGUAGE pragma like this: {-# LANGUAGE TraditionalRecordSyntax #-} For pre-Haskell' compilers, we would want something like: {-# LANGUAGE NoTraditionalRecordSyntax #-} which would mean extending the LANGUAGE pragma to support turning extensions off by adding/removing a No from the front of it. Hmm, is it really the case that nobody has proposed LANGUAGE pragmas for Haskell'? I don't see them listed on the Status page. I guess the work involved here is basically: (a) Go through Haskell 98, find all the parts that talk specifically about record syntax, and write up the list of such places. (b) Implement this in GHC: (c) Add support for negating extension names by adding/removing No in front of extension names to Cabal: (d) Add {-# LANGUAGE #-} to Haskell' What do you folks think? From duncan.coutts at worc.ox.ac.uk Mon Jul 6 18:15:42 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jul 6 19:19:31 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <878wj1lcsl.wl%naesten@gmail.com> References: <878wj1lcsl.wl%naesten@gmail.com> Message-ID: <1246918542.22466.163.camel@localhost> On Mon, 2009-07-06 at 17:30 -0400, Samuel Bronson wrote: > According to , > ticket #99 was rejected, but the tickets own page, > , says > "probably yes". Which is it? > > I was about to propose this myself, but decided to check the trac just > in case it had already been proposed, Haskell being so popular with > smart people and all, and was at first rather disappointed and ready > to write an angry rant to the list, then rather confused when I > noticed the ticket's page said almost the exact opposite of the Status > page. > > In particular, I want records to be considered an extension to > Haskell', to be implemented only by compilers that care, and even then > only allowed with a LANGUAGE pragma like this: > > {-# LANGUAGE TraditionalRecordSyntax #-} > > For pre-Haskell' compilers, we would want something like: > > {-# LANGUAGE NoTraditionalRecordSyntax #-} > > which would mean extending the LANGUAGE pragma to support turning > extensions off by adding/removing a No from the front of it. The motivation I suppose is so that people can experiment with other record systems as extensions without having to worry so much about the syntax clashing with the existing syntax. It would have to be clear that it may not be possible to use certain combinations of extensions together. In particular TraditionalRecordSyntax with some future alternative record extension. > Hmm, is it really the case that nobody has proposed LANGUAGE pragmas for > Haskell'? I don't see them listed on the Status page. This we certainly need to do. It's the primary mechanism by which we allow flexibility in the language without breaking all existing code (by letting modules declare which language features they want to turn on or off). For one thing the spec currently says that pragmas cannot change the semantics of the program. That would have to read "apart from the LANGUAGE pragma". Duncan From john at repetae.net Mon Jul 6 21:28:54 2009 From: john at repetae.net (John Meacham) Date: Mon Jul 6 21:11:15 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <878wj1lcsl.wl%naesten@gmail.com> References: <878wj1lcsl.wl%naesten@gmail.com> Message-ID: <20090707012854.GD4430@sliver.repetae.net> Well, without a replacement, it seems odd to remove it. Also, Haskell currently doesn't _have_ a record syntax (I think it was always a misnomer to call it that) it has 'labeled fields'. None of the proposed record syntaxes fit the same niche as labeled fields so I don't see them going away even if a record syntax is added to haskell in the future. I would like to see the simple modifications to the record syntax listed on this page though http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords and a reworking of the standard to not refer to the current system as a 'record syntax' but rather a 'labeled fields' syntax. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From duncan.coutts at worc.ox.ac.uk Tue Jul 7 05:40:04 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jul 7 06:37:41 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <20090707012854.GD4430@sliver.repetae.net> References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> Message-ID: <1246959604.22466.711.camel@localhost> On Mon, 2009-07-06 at 18:28 -0700, John Meacham wrote: > Well, without a replacement, it seems odd to remove it. Also, Haskell > currently doesn't _have_ a record syntax (I think it was always a > misnomer to call it that) it has 'labeled fields'. None of the proposed > record syntaxes fit the same niche as labeled fields so I don't see them > going away even if a record syntax is added to haskell in the future. The people proposing this can correct me if I'm wrong but my understanding of their motivation is not to remove record syntax or immediately to replace it, but to make it easier to experiment with replacements by making the existing labelled fields syntax a modular part of the language that can be turned on or off (like the FFI). I'm not sure that I agree that it's the best approach but it is one idea to try and break the current impasse. It seems currently we cannot experiment with new record systems because they inevitably clash with the current labelled fields and thus nothing changes. Duncan From Malcolm.Wallace at cs.york.ac.uk Tue Jul 7 06:57:46 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Jul 7 06:40:41 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <20090707012854.GD4430@sliver.repetae.net> References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> Message-ID: On 7 Jul 2009, at 02:28, John Meacham wrote: > Haskell currently doesn't _have_ a record syntax (I think it was > always a > misnomer to call it that) it has 'labeled fields'. ... > > and a reworking of the standard to not refer to the current system > as a > 'record syntax' but rather a 'labeled fields' syntax. I strongly agree with the latter. In fact, I was under the impression that the Report already avoided the term "record syntax" completely, but checking just now showed 6 distinct occurrences. Regards, Malcolm From bulat.ziganshin at gmail.com Tue Jul 7 07:12:55 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jul 7 06:55:23 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <1246918542.22466.163.camel@localhost> References: <878wj1lcsl.wl%naesten@gmail.com> <1246918542.22466.163.camel@localhost> Message-ID: <952116244.20090707151255@gmail.com> Hello Duncan, Tuesday, July 7, 2009, 2:15:42 AM, you wrote: > For one thing the spec currently says that pragmas cannot change the > semantics of the program. That would have to read "apart from the > LANGUAGE pragma". sometime ago i've proposed to make a "language" statement a part of haskell. i don't insist on this but at least keep this possibility in mind - making it a pragma is a poor man solution -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From marlowsd at gmail.com Tue Jul 7 10:04:46 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jul 7 09:47:02 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 Message-ID: <4A5355FE.9010901@gmail.com> At last year's Haskell Symposium, it was announced that we would change the Haskell Prime process to make it less monolithic. Since then, everyone has been busy using Haskell (or implementing it), and we haven't made much progress on the standardisation side of things. Well, with ICFP and the Haskell Symposium approaching we felt it was time to get the new process moving and hopefully produce a language revision this year. I've updated the Haskell' wiki with the new information; in particular the process is documented here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process We're aiming to announce the list of accepted proposals at the Haskell Symposium this year. However, owing to the short timescale, the list is going to be correspondingly short, and limited to extensions which are either already fully specified (i.e. the FFI) or are small and well-understood. The following list is very provisional; we'll be making the final decisions next month. ForeignFunctionInterface LineCommentSyntax PatternGuards DoAndIfThenElse Remove n+k patterns RelaxedDependencyAnalysis EmptyDataDeclarations HierarchicalModules NonDecreasingIndentation remove FixityResolution from the context-free grammar change the syntax of QualifiedOperators In the coming weeks we'll be refining proposals in preparation for Haskell 2010. By all means suggest more possibilities; however note that as per the new process, a proposal must be "complete" (i.e. in the form of an addendum) in order to be a candidate for acceptance. I have updated the status page http://hackage.haskell.org/trac/haskell-prime/wiki/Status marking everything except the proposals that have been already implemented in the draft Report as "old". The new process requires a proposal to have an owner or owners in order to make progress; once a proposal has an owner it will move into the "under discussion" state. To take up ownership of an existing proposal, or to start a new proposal, ask on the mailing list. There are other ways you can get involved; some suggestions are on the Haskell' main page: http://hackage.haskell.org/trac/haskell-prime/wiki (hmm, I suppose we should fix that logo too...) Cheers, Simon From ml at isaac.cedarswampstudios.org Tue Jul 7 10:08:08 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Tue Jul 7 09:50:29 2009 Subject: what about moving the record system to an addendum? In-Reply-To: References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> Message-ID: <4A5356C8.2080805@isaac.cedarswampstudios.org> Malcolm Wallace wrote: > > On 7 Jul 2009, at 02:28, John Meacham wrote: > >> Haskell currently doesn't _have_ a record syntax (I think it was always a >> misnomer to call it that) it has 'labeled fields'. ... >> >> and a reworking of the standard to not refer to the current system as a >> 'record syntax' but rather a 'labeled fields' syntax. > > I strongly agree with the latter. In fact, I was under the impression > that the Report already avoided the term "record syntax" completely, but > checking just now showed 6 distinct occurrences. ah hah. Existing extension names: NamedFieldPuns (was erroneously "RecordPuns" in GHC for a release) RecordWildCards, DisambiguateRecordFields this "extension" could be named NamedFields. (then giving the lie to the above new names which maybe ought to be more like FieldWildCards and DisambiguateNamedFields(DisambiguateFieldNames?)) Also there is "ExtensibleRecords" which I guess refers to Hugs' TRex? -Isaac From ravi at bluespec.com Tue Jul 7 10:23:16 2009 From: ravi at bluespec.com (Ravi Nanavati) Date: Tue Jul 7 10:05:30 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <952116244.20090707151255@gmail.com> References: <878wj1lcsl.wl%naesten@gmail.com> <1246918542.22466.163.camel@localhost> <952116244.20090707151255@gmail.com> Message-ID: <7b977d860907070723s7ea25a32ne9d8a008d7767c0c@mail.gmail.com> I've suggested some sort of standardization of the LANGUAGE pragma as well. Given our new modular, yearly approach to standardization, it does seem worth trying to formalize it. - Ravi On Tue, Jul 7, 2009 at 7:12 AM, Bulat Ziganshin wrote: > Hello Duncan, > > Tuesday, July 7, 2009, 2:15:42 AM, you wrote: > >> For one thing the spec currently says that pragmas cannot change the >> semantics of the program. That would have to read "apart from the >> LANGUAGE pragma". > > sometime ago i've proposed to make a "language" statement a part of > haskell. i don't insist on this but at least keep this possibility in > mind - making it a pragma is a poor man solution > > > -- > Best regards, > ?Bulat ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From ravi at bluespec.com Tue Jul 7 10:28:11 2009 From: ravi at bluespec.com (Ravi Nanavati) Date: Tue Jul 7 10:10:26 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <1246959604.22466.711.camel@localhost> References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> <1246959604.22466.711.camel@localhost> Message-ID: <7b977d860907070728i626edd05oed4c37f4f97e6b03@mail.gmail.com> 2009/7/7 Duncan Coutts : > On Mon, 2009-07-06 at 18:28 -0700, John Meacham wrote: >> Well, without a replacement, it seems odd to remove it. Also, Haskell >> currently doesn't _have_ a record syntax (I think it was always a >> misnomer to call it that) it has 'labeled fields'. None of the proposed >> record syntaxes fit the same niche as labeled fields so I don't see them >> going away even if a record syntax is added to haskell in the future. > > The people proposing this can correct me if I'm wrong but my > understanding of their motivation is not to remove record syntax or > immediately to replace it, but to make it easier to experiment with > replacements by making the existing labelled fields syntax a modular > part of the language that can be turned on or off (like the FFI). > > I'm not sure that I agree that it's the best approach but it is one idea > to try and break the current impasse. It seems currently we cannot > experiment with new record systems because they inevitably clash with > the current labelled fields and thus nothing changes. I think it is a powerful approach to try and break the current impasse for the following reasons: 1. Once implemented, Hackage and Cabal will soon give us accurate data on what publicly available Haskell code does and does not depend on NamedFields/TraditionalRecordSyntax/WhateverWeEndUpCallingIt 2. Once deprecated, people will be encouraged to not depend on the traditional record syntax where the cost of avoiding it is small (I'm thinking of situations like the mtl-accessors / run functions where the traditional syntax is saving something like one function definition). 3. Champions of alternative record syntaxes will know what on Hackage they can use out-of-the-box and what things they'd want to consider re-writing as examples of how their approach is superior. Does anyone have a concrete dea of what it would take to carve out the existing syntax as an addendum? Thanks, - Ravi From bulat.ziganshin at gmail.com Tue Jul 7 10:27:42 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jul 7 10:11:18 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <4A5355FE.9010901@gmail.com> References: <4A5355FE.9010901@gmail.com> Message-ID: <1476881543.20090707182742@gmail.com> Hello Simon, Tuesday, July 7, 2009, 6:04:46 PM, you wrote: i can't understand. does this list supposed to be full list of changes in haskell'? it seems to include mainly supplementary syntax changes while even Rank2Types are not here, the same for assoc. types, GADTs and other fundamental type system improvements and btw - from my user's POV, we can just start with common GHC & Hugs subset, remove a few features, add a few GHC-specific features and will become close to what should be named next Haskell standard, standard de-facto of Haskell used in last years. why so much time spent on this process.. > ForeignFunctionInterface > LineCommentSyntax > PatternGuards > DoAndIfThenElse > Remove n+k patterns > RelaxedDependencyAnalysis > EmptyDataDeclarations > HierarchicalModules > NonDecreasingIndentation > remove FixityResolution from the context-free grammar > change the syntax of QualifiedOperators > In the coming weeks we'll be refining proposals in preparation for > Haskell 2010. By all means suggest more possibilities; however note > that as per the new process, a proposal must be "complete" (i.e. in the > form of an addendum) in order to be a candidate for acceptance. > I have updated the status page > http://hackage.haskell.org/trac/haskell-prime/wiki/Status > marking everything except the proposals that have been already > implemented in the draft Report as "old". The new process requires a > proposal to have an owner or owners in order to make progress; once a > proposal has an owner it will move into the "under discussion" state. To > take up ownership of an existing proposal, or to start a new proposal, > ask on the mailing list. There are other ways you can get involved; > some suggestions are on the Haskell' main page: > http://hackage.haskell.org/trac/haskell-prime/wiki > (hmm, I suppose we should fix that logo too...) > Cheers, > Simon > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ravi at bluespec.com Tue Jul 7 10:34:40 2009 From: ravi at bluespec.com (Ravi Nanavati) Date: Tue Jul 7 10:16:54 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <1476881543.20090707182742@gmail.com> References: <4A5355FE.9010901@gmail.com> <1476881543.20090707182742@gmail.com> Message-ID: <7b977d860907070734r7fff5571u6689f3197a9f8960@mail.gmail.com> On Tue, Jul 7, 2009 at 10:27 AM, Bulat Ziganshin wrote: > Hello Simon, > > Tuesday, July 7, 2009, 6:04:46 PM, you wrote: > > i can't understand. does this list supposed to be full list of changes > in haskell'? it seems to include mainly supplementary syntax changes > while even Rank2Types are not here, the same for assoc. types, GADTs > and other fundamental type system improvements This is not a complete list of what would be in a next "major Haskell standard (what we've all been calling Haskell'). The problem of producing a new major standard in one step has proven intractable to date. Instead, given the state of completed addenda beyond Haskell 98, this is a provisional list of features that the Haskell' committee thinks would be feasible to include in a 2010 revision of the Haskell standard. We're *very* open to considering features not on this list (consider the results of the various straw polls, for example), but to be eligible for consideration for Haskell 2010 any additional proposals would need a completed, high-quality addendum by August, so the clock is ticking... - Ravi From Malcolm.Wallace at cs.york.ac.uk Tue Jul 7 10:46:02 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Jul 7 10:28:18 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <7b977d860907070734r7fff5571u6689f3197a9f8960@mail.gmail.com> References: <4A5355FE.9010901@gmail.com> <1476881543.20090707182742@gmail.com> <7b977d860907070734r7fff5571u6689f3197a9f8960@mail.gmail.com> Message-ID: <69692847-7F27-40E6-8729-A97B9DAF434B@cs.york.ac.uk> >> i can't understand. does this list supposed to be full list of >> changes >> in haskell'? > > this is a provisional list of features that the Haskell' committee > thinks would be feasible to include in a 2010 revision of the Haskell > standard. And just to add, the new standardisation process means that there will also be a Haskell 2011, Haskell 2012, etc. If a feature is not completely specified in time for one standard, then it will not need to wait long until it can be accepted in the next one. Eventually, the process might give us a standard that is stable and unchanging, but right now, we need to take it small pieces. Regards, Malcolm From marlowsd at gmail.com Tue Jul 7 11:25:15 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jul 7 11:07:31 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <1476881543.20090707182742@gmail.com> References: <4A5355FE.9010901@gmail.com> <1476881543.20090707182742@gmail.com> Message-ID: <4A5368DB.9050909@gmail.com> On 07/07/2009 15:27, Bulat Ziganshin wrote: > Tuesday, July 7, 2009, 6:04:46 PM, you wrote: > > i can't understand. does this list supposed to be full list of changes > in haskell'? it seems to include mainly supplementary syntax changes > while even Rank2Types are not here, the same for assoc. types, GADTs > and other fundamental type system improvements Perhaps you didn't read the Process page? This is the list of changes that are provisionally in Haskell 2010. Haskell' is an ongoing process, producing a new revision every year. The reason that many extensions are not ready to be in the standard is that they haven't been formally specified; indeed, many of them are still changing (e.g. GADTs). > and btw - from my user's POV, we can just start with common GHC& Hugs > subset, remove a few features, add a few GHC-specific features and > will become close to what should be named next Haskell standard, > standard de-facto of Haskell used in last years. why so much time spent > on this process.. For the language standard, we need to be absolutely precise about what each extension to the language means. Most of the extensions that GHC implements are barely specified at all. How would you go about implementing, say, scoped type variables in another Haskell compiler? Cheers, Simon From claus.reinke at talk21.com Tue Jul 7 11:40:48 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Jul 7 11:23:08 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 References: <4A5355FE.9010901@gmail.com> Message-ID: <5830C8CC26834FFC9706D330E85370F7@cr3lt> > At last year's Haskell Symposium, it was announced that we would change > the Haskell Prime process to make it less monolithic. > .. > In the coming weeks we'll be refining proposals in preparation for > Haskell 2010. Given the incremental nature of the new standards, would it be useful to switch back to version numbers, eg "Haskell 2.0.0 (2010)" instead of "Haskell 2010"? Otherwise, we'll end up with half a dozen more or less current Haskells related by no obvious means. "Haskell'98" was chosen because it projected more permanence than the Haskell 1.x line of Haskell revisions that came before it. Having API instead of date encoded in the name would support deprecations, breaking changes, or additions as well as make it clear whether a new year's version does break anything or not. Btw, once upon a time, there was a discussion about an even more modular approach, standardising language extensions without saying which extensions made up a standard language. That would give support to the status quo, where people want to use, say, Haskell'98+FFI+Hierarchical Modules+MPTC+.. In other words, existing language extensions (LANGUAGE pragmas) ought to be standardized (currently, they mean different things in different implementations), independent of whether or not the committee decides to group them into a Haskell X. Claus From ml at isaac.cedarswampstudios.org Tue Jul 7 11:51:50 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Tue Jul 7 11:34:40 2009 Subject: [Haskell] Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <4A5355FE.9010901@gmail.com> References: <4A5355FE.9010901@gmail.com> Message-ID: <4A536F16.7020808@isaac.cedarswampstudios.org> Simon Marlow wrote: > Remove n+k patterns > remove FixityResolution from the context-free grammar There are a couple sensible removals here. Do we also want to get rid of the useless class contexts on data-declarations? (that look like "data Ord a => Set a = Set ...") -Isaac From ml at isaac.cedarswampstudios.org Tue Jul 7 11:58:09 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Tue Jul 7 11:40:33 2009 Subject: [Haskell] Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <4A536F16.7020808@isaac.cedarswampstudios.org> References: <4A5355FE.9010901@gmail.com> <4A536F16.7020808@isaac.cedarswampstudios.org> Message-ID: <4A537091.4000403@isaac.cedarswampstudios.org> Isaac Dupree wrote: > Simon Marlow wrote: >> Remove n+k patterns oh also -- anything like this that we remove should get a LANGUAGE flag to go along with it. I don't see NPlusKPatterns in Language.Haskell.Extension yet :-) -Isaac From haskell at henning-thielemann.de Tue Jul 7 11:58:54 2009 From: haskell at henning-thielemann.de (haskell@henning-thielemann.de) Date: Tue Jul 7 11:41:13 2009 Subject: Proposal: change to qualified operator syntax Message-ID: Adding to an old thread: http://www.haskell.org/pipermail/haskell-prime/2008-April/002441.html I like to note that I'm against this proposal. The example given in http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators namely [Red..] can be easily resolved by adding a space, thus [Red ..]. I use qualified operators occasionally, since I use NumericPrelude and thus have to import some things from Prelude in a qualified way. As there will appear more and more infix operators in libraries along with more name clashes (e.g. recently discussed List.++ and Monoid.++), qualified operator names will become not so uncommon. Of course, to keep the spirit of infix operators, you will better define custom operators locally, but this is only reasonable if you use an infix operator more than once. The current syntax is also in a way consistent, since e.g. (+) coincides with a two side operator section, which is no longer true with the new proposal. Also (...) and `...` are dual, which is a nice property. From simonpj at microsoft.com Tue Jul 7 15:17:29 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jul 7 14:59:24 2009 Subject: [Haskell] Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <4A536F16.7020808@isaac.cedarswampstudios.org> References: <4A5355FE.9010901@gmail.com> <4A536F16.7020808@isaac.cedarswampstudios.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C344C443A9CD@EA-EXMSG-C334.europe.corp.microsoft.com> | There are a couple sensible removals here. Do we also want to get rid | of the useless class contexts on data-declarations? (that look like | "data Ord a => Set a = Set ...") Yes! Yes! Kill them. (In GHC's source code these contexts are consistently called stupid_theta.) Simon From iavor.diatchki at gmail.com Tue Jul 7 17:33:00 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Jul 7 17:15:19 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <7b977d860907070728i626edd05oed4c37f4f97e6b03@mail.gmail.com> References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> <1246959604.22466.711.camel@localhost> <7b977d860907070728i626edd05oed4c37f4f97e6b03@mail.gmail.com> Message-ID: <5ab17e790907071433m505d8a66j6e455e51f57bbad3@mail.gmail.com> Hello, I do not think that we should remove the current record/named fields syntax, at least for the moment. I use it a lot, and I do not want to add extra pragmas or "extensions" to my cabal file. In fact, one of the purposes of Haskell', the way I understand it, is exactly to just choose a stable set of extensions and give a name to them (so decrease, not increase the number of pragmas). I think that a new reocrd/label system is way beyond the scope of Haskell'. If people want to experiment with new record systems they may already do so, by defining a new extension. A case in point is the Trex record system, which is implemented in Hugs. -Iavor 2009/7/7 Ravi Nanavati : > 2009/7/7 Duncan Coutts : >> On Mon, 2009-07-06 at 18:28 -0700, John Meacham wrote: >>> Well, without a replacement, it seems odd to remove it. Also, Haskell >>> currently doesn't _have_ a record syntax (I think it was always a >>> misnomer to call it that) it has 'labeled fields'. None of the proposed >>> record syntaxes fit the same niche as labeled fields so I don't see them >>> going away even if a record syntax is added to haskell in the future. >> >> The people proposing this can correct me if I'm wrong but my >> understanding of their motivation is not to remove record syntax or >> immediately to replace it, but to make it easier to experiment with >> replacements by making the existing labelled fields syntax a modular >> part of the language that can be turned on or off (like the FFI). >> >> I'm not sure that I agree that it's the best approach but it is one idea >> to try and break the current impasse. It seems currently we cannot >> experiment with new record systems because they inevitably clash with >> the current labelled fields and thus nothing changes. > > I think it is a powerful approach to try and break the current impasse > for the following reasons: > > 1. Once implemented, Hackage and Cabal will soon give us accurate data > on what publicly available Haskell code does and does not depend on > NamedFields/TraditionalRecordSyntax/WhateverWeEndUpCallingIt > 2. Once deprecated, people will be encouraged to not depend on the > traditional record syntax where the cost of avoiding it is small (I'm > thinking of situations like the mtl-accessors / run functions where > the traditional syntax is saving something like one function > definition). > 3. Champions of alternative record syntaxes will know what on Hackage > they can use out-of-the-box and what things they'd want to consider > re-writing as examples of how their approach is superior. > > Does anyone have a concrete dea of what it would take to carve out the > existing syntax as an addendum? > > Thanks, > > ?- Ravi > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From john at repetae.net Tue Jul 7 17:33:57 2009 From: john at repetae.net (John Meacham) Date: Tue Jul 7 17:16:15 2009 Subject: what about moving the record system to an addendum? In-Reply-To: <7b977d860907070728i626edd05oed4c37f4f97e6b03@mail.gmail.com> References: <878wj1lcsl.wl%naesten@gmail.com> <20090707012854.GD4430@sliver.repetae.net> <1246959604.22466.711.camel@localhost> <7b977d860907070728i626edd05oed4c37f4f97e6b03@mail.gmail.com> Message-ID: <20090707213357.GF4430@sliver.repetae.net> On Tue, Jul 07, 2009 at 10:28:11AM -0400, Ravi Nanavati wrote: > 2. Once deprecated, people will be encouraged to not depend on the > traditional record syntax where the cost of avoiding it is small (I'm > thinking of situations like the mtl-accessors / run functions where > the traditional syntax is saving something like one function > definition). > 3. Champions of alternative record syntaxes will know what on Hackage > they can use out-of-the-box and what things they'd want to consider > re-writing as examples of how their approach is superior. Well, that's the problem. I don't want to ever deprecate the named field mechanism as it is completely independent of a record system. You can think of the possibilites as follows. named positional declared LabeledFields DataDeclarations anonymous ???? Tuples So, a record syntax fills the hole of anonymous, named field types. However, we shouldn't do it at the expense of opening another hole with declared, named field types any more than we should dispose of standard data declations in favor of making everything newtypes of tuples. Also, this supports the idea of using parethensis rather than braces for a record mechanism. this would be consistent with tuples in that parens = anonymous. Also, if you just replace braces with parens in the scoped records paper, you get no conflicts with existing syntax. (including named fields) :) John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From john at repetae.net Tue Jul 7 23:04:48 2009 From: john at repetae.net (John Meacham) Date: Tue Jul 7 22:46:59 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: References: Message-ID: <20090708030448.GJ4430@sliver.repetae.net> On Tue, Jul 07, 2009 at 05:58:54PM +0200, haskell@henning-thielemann.de wrote: > > Adding to an old thread: > http://www.haskell.org/pipermail/haskell-prime/2008-April/002441.html > > I like to note that I'm against this proposal. The example given in > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators > namely [Red..] can be easily resolved by adding a space, thus [Red ..]. > I use qualified operators occasionally, since I use NumericPrelude and > thus have to import some things from Prelude in a qualified way. As there > will appear more and more infix operators in libraries along with more > name clashes (e.g. recently discussed List.++ and Monoid.++), qualified > operator names will become not so uncommon. Of course, to keep the spirit > of infix operators, you will better define custom operators locally, but > this is only reasonable if you use an infix operator more than once. > The current syntax is also in a way consistent, since e.g. (+) coincides > with a two side operator section, which is no longer true with the new > proposal. Also (...) and `...` are dual, which is a nice property. Yeah. reading it again, I know this will break my code. I am not sure whether anyone else does it, but a common idiom for me is import List as L import Set as S if S.isEmpty (x S.\\ y) then y L.\\ x or somesuch. Are qualified operators really that uncommon? I would think they would be used fairly often... John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From marlowsd at gmail.com Wed Jul 8 04:06:33 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 8 03:48:47 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <5830C8CC26834FFC9706D330E85370F7@cr3lt> References: <4A5355FE.9010901@gmail.com> <5830C8CC26834FFC9706D330E85370F7@cr3lt> Message-ID: <4A545389.6000906@gmail.com> On 07/07/2009 16:40, Claus Reinke wrote: >> At last year's Haskell Symposium, it was announced that we would >> change the Haskell Prime process to make it less monolithic. .. >> In the coming weeks we'll be refining proposals in preparation for >> Haskell 2010. > > Given the incremental nature of the new standards, would it be > useful to switch back to version numbers, eg "Haskell 2.0.0 (2010)" > instead of "Haskell 2010"? Otherwise, we'll end up with half a > dozen more or less current Haskells related by no obvious means. > "Haskell'98" was chosen because it projected more permanence > than the Haskell 1.x line of Haskell revisions that came before it. The relationship between the versions will be quite clear: each revision will be specified by a set of deltas to the previous one. I think the year-based naming scheme is fine, especially since we're planning to produce annual revisions. An important question though is what we should call the major versions. There it will probably make sense to use "Haskell 2", "Haskell 3", and so on. I imagine the first major version won't be for a few years, though. > Having API instead of date encoded in the name would support > deprecations, breaking changes, or additions as well as make it clear > whether a new year's version does break anything or not. > > Btw, once upon a time, there was a discussion about an even > more modular approach, standardising language extensions > without saying which extensions made up a standard language. > That would give support to the status quo, where people want > to use, say, Haskell'98+FFI+Hierarchical Modules+MPTC+.. > > In other words, existing language extensions (LANGUAGE > pragmas) ought to be standardized (currently, they mean different > things in different implementations), independent of whether > or not the committee decides to group them into a Haskell X. What you're suggesting is not incompatible with Haskell'. In Haskell', each change to the language will be independently specified, as an addendum, before being accepted as part of the language. So a side-effect of the standardisation process is a set of addenda, that you could mix and match. GHC will still support one flag per extension, where it makes sense (there's not much point making a flag for fixes and trivial changes). So in GHC, {-# LANGUAGE Haskell2010 #-} could be expanded to the set of extensions in Haskell 2010, and will probably be implemented that way. Cheers, Simon From marlowsd at gmail.com Wed Jul 8 04:27:09 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 8 04:09:22 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: References: Message-ID: <4A54585D.2070606@gmail.com> On 07/07/2009 16:58, haskell@henning-thielemann.de wrote: > > Adding to an old thread: > http://www.haskell.org/pipermail/haskell-prime/2008-April/002441.html > > I like to note that I'm against this proposal. The example given in > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators > namely [Red..] can be easily resolved by adding a space, thus [Red ..]. > I use qualified operators occasionally, since I use NumericPrelude and > thus have to import some things from Prelude in a qualified way. As > there will appear more and more infix operators in libraries along with > more name clashes (e.g. recently discussed List.++ and Monoid.++), > qualified operator names will become not so uncommon. Of course, to keep > the spirit of infix operators, you will better define custom operators > locally, but this is only reasonable if you use an infix operator more > than once. > The current syntax is also in a way consistent, since e.g. (+) coincides > with a two side operator section, which is no longer true with the new > proposal. Also (...) and `...` are dual, which is a nice property. This proposal cleans up some nastiness in the lexical syntax. For example the M.. M... M.... debacle. How many lexemes in each of those? in Haskell 98 it's 1, 2, and 3 respectively, whereas with the qualified operator proposal they are all 2 lexemes. Yes, you can add spaces to make [Red ..] work. But why should you have to, when [1..] works without a space? Prelude.>>= just doesn't look like an infix operator. The point of infix operators is that they are a lightweight notation, but they lose that advantage when qualified. The qualified operator proposal gives you a nice rule of thumb to rely on when parsing code in your head: if it begins with a letter, it is not infix. The advantages of this shouldn't be underestimated, IMO. Cheers, Simon From marlowsd at gmail.com Wed Jul 8 04:55:43 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 8 04:37:59 2009 Subject: [Haskell] Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C344C443A9CD@EA-EXMSG-C334.europe.corp.microsoft.com> References: <4A5355FE.9010901@gmail.com> <4A536F16.7020808@isaac.cedarswampstudios.org> <638ABD0A29C8884A91BC5FB5C349B1C344C443A9CD@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4A545F0F.8060800@gmail.com> On 07/07/2009 20:17, Simon Peyton-Jones wrote: > | There are a couple sensible removals here. Do we also want to get rid > | of the useless class contexts on data-declarations? (that look like > | "data Ord a => Set a = Set ...") > > Yes! Yes! Kill them. > > (In GHC's source code these contexts are consistently called stupid_theta.) This is listed as "Remove class context on data definitions" in the list of proposals. It doesn't have an owner or a wiki page yet. Any volunteers? Cheers, Simon From marlowsd at gmail.com Wed Jul 8 05:07:21 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 8 04:49:36 2009 Subject: Proposals and owners In-Reply-To: <4A5355FE.9010901@gmail.com> References: <4A5355FE.9010901@gmail.com> Message-ID: <4A5461C9.5020501@gmail.com> As a reminder, here is the provisional list for 2010: > ForeignFunctionInterface > LineCommentSyntax > PatternGuards > DoAndIfThenElse > Remove n+k patterns > RelaxedDependencyAnalysis > EmptyDataDeclarations > HierarchicalModules > NonDecreasingIndentation > remove FixityResolution from the context-free grammar > change the syntax of QualifiedOperators These have already been done, so don't really need owners: > LineCommentSyntax > DoAndIfThenElse > PatternGuards I plan to take ownership of the following: > HierarchicalModules > change the syntax of QualifiedOperators > remove FixityResolution from the context-free grammar That leaves the following proposals needing owners: > ForeignFunctionInterface > Remove n+k patterns > RelaxedDependencyAnalysis > EmptyDataDeclarations > NonDecreasingIndentation Volunteers please! Cheers, Simon On 07/07/2009 15:04, Simon Marlow wrote: > > In the coming weeks we'll be refining proposals in preparation for > Haskell 2010. By all means suggest more possibilities; however note that > as per the new process, a proposal must be "complete" (i.e. in the form > of an addendum) in order to be a candidate for acceptance. > > I have updated the status page > > http://hackage.haskell.org/trac/haskell-prime/wiki/Status > > marking everything except the proposals that have been already > implemented in the draft Report as "old". The new process requires a > proposal to have an owner or owners in order to make progress; once a > proposal has an owner it will move into the "under discussion" state. To > take up ownership of an existing proposal, or to start a new proposal, > ask on the mailing list. There are other ways you can get involved; some > suggestions are on the Haskell' main page: > > http://hackage.haskell.org/trac/haskell-prime/wiki > > (hmm, I suppose we should fix that logo too...) > > Cheers, > Simon From ross at soi.city.ac.uk Wed Jul 8 05:33:28 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jul 8 05:15:41 2009 Subject: Proposals and owners In-Reply-To: <4A5461C9.5020501@gmail.com> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> Message-ID: <20090708093328.GA6162@soi.city.ac.uk> On Wed, Jul 08, 2009 at 10:07:21AM +0100, Simon Marlow wrote: > As a reminder, here is the provisional list for 2010: > > > ForeignFunctionInterface > > LineCommentSyntax > > PatternGuards > > DoAndIfThenElse > > Remove n+k patterns > > RelaxedDependencyAnalysis > > EmptyDataDeclarations > > HierarchicalModules > > NonDecreasingIndentation > > remove FixityResolution from the context-free grammar > > change the syntax of QualifiedOperators > > These have already been done, so don't really need owners: > > > LineCommentSyntax > > DoAndIfThenElse > > PatternGuards > > I plan to take ownership of the following: > > > HierarchicalModules > > change the syntax of QualifiedOperators > > remove FixityResolution from the context-free grammar > > That leaves the following proposals needing owners: > > > ForeignFunctionInterface > > Remove n+k patterns > > RelaxedDependencyAnalysis > > EmptyDataDeclarations > > NonDecreasingIndentation > > Volunteers please! I'll volunteer for RelaxedDependencyAnalysis -- it's mostly done already. From marlowsd at gmail.com Wed Jul 8 10:09:29 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 8 09:51:42 2009 Subject: Haskell 2010: libraries Message-ID: <4A54A899.1030801@gmail.com> This is more of a consistency issue than anything else. We have to decide what to do with the libraries in the Report. Right now, the Haskell Report specifies 15 library modules. Things like Maybe, Char, IO, Time, and Random. The situation is not ideal, for many reasons: - There are a lot more than 15 library modules available to Haskell programmers! The libraries section of the report was a good idea when there were no libraries at all, nowadays it makes a lot less sense. - These modules are using the old non-hierarchical names. Best practice these days is to use the hierarchical versions. - some of these libraries have well-known problems, and some have been superseded by better libraries: Time is a good example. On the other hand, some people like having these modules around, and deliberately use them because they aren't allowed to change. I'm mainly concerned with projecting a consistent picture in the Report, so as not to mislead or confuse people. Here are the options I can see: 1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however. There will be some loose ends where the rest of the report refers to entities from these libraries, e.g. the Prelude refers to Rational from the Ratio library. We just have to fix up these references, moving the appropriate definitions into the Report as necessary. 2. Just drop the obvious candidates (Time, Random, CPUTime, Locale, Complex?), leaving the others. 3. Update the libraries to match what we have at the moment. e.g. rename List to Data.List, and add the handful of functions that have since been added to Data.List. One problem with this is that these modules are then tied to the language definition, and can't be changed through the usual library proposal process. Also it would seem slightly strange to have a seemingly random set of library modules in the report. 4. Combine 2 and 3: drop some, rename the rest. 5. Don't do anything. Note that we have to take into account the FFI libraries too: the FFI addendum includes modules such as Foreign, CForeign, Storable, MarshalError, and so on. The same issues apply: the report needs to mention some of the types and entities exported by these modules. I'm tending towards (1), mainly because it provides a clean break and is likely to be the least confusing for users: they have one place to go looking for library documentation. Please keep discussion focussed: this is about how libraries are presented in the Haskell report, not about library standardisation in general. I'm aware there are much wider issues, but we have some immediate problems to address. Cheers, Simon From bulat.ziganshin at gmail.com Wed Jul 8 10:42:28 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jul 8 10:25:00 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A54A899.1030801@gmail.com> References: <4A54A899.1030801@gmail.com> Message-ID: <547360499.20090708184228@gmail.com> Hello Simon, Wednesday, July 8, 2009, 6:09:29 PM, you wrote: > 3. Update the libraries to match what we have at the moment. > e.g. rename List to Data.List, and add the handful of > functions that have since been added to Data.List. One > problem with this is that these modules are then tied to > the language definition, and can't be changed through > the usual library proposal process. not necessarily. we already apply versioning to these libs, it may be made official in Report too. i.e. Report defines libraries standard for year 2010 (like it defines language standard for only one year), while we continue to improve libraries that will eventually become version standard for year 2011 (or higher) but we probably aren't yet ready to produce Library Standard. it will be great to include in Standard only *versioned* libraries while ATM many features (such as IO) is a part of non-versioned library named "base" well, it' versioned but not very good -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From apfelmus at quantentunnel.de Wed Jul 8 14:41:34 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Wed Jul 8 14:23:44 2009 Subject: Haskell 2010: libraries In-Reply-To: <547360499.20090708184228@gmail.com> References: <4A54A899.1030801@gmail.com> <547360499.20090708184228@gmail.com> Message-ID: Bulat Ziganshin wrote: > Simon Marlow wrote: > >> 3. Update the libraries to match what we have at the moment. >> e.g. rename List to Data.List, and add the handful of >> functions that have since been added to Data.List. One >> problem with this is that these modules are then tied to >> the language definition, and can't be changed through >> the usual library proposal process. > > not necessarily. we already apply versioning to these libs, it may be > made official in Report too. i.e. Report defines libraries standard > for year 2010 (like it defines language standard for only one year), > while we continue to improve libraries that will eventually become > version standard for year 2011 (or higher) If I understand that correctly, this would mean to simply include the particular version of a library that happens to be the current one at the report deadline. In other words, the report specifies that say version 4.1.0.0 of the base library is the standard one for 2010. Since old library versions are archived on hackage, this looks like a cheap and easy solution to me. It's more an embellishment of alternative 1. than a genuine 3. Regards, apfelmus -- http://apfelmus.nfshost.com From bulat.ziganshin at gmail.com Wed Jul 8 14:55:50 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jul 8 14:38:25 2009 Subject: Haskell 2010: libraries In-Reply-To: References: <4A54A899.1030801@gmail.com> <547360499.20090708184228@gmail.com> Message-ID: <1682755888.20090708225550@gmail.com> Hello Heinrich, Wednesday, July 8, 2009, 10:41:34 PM, you wrote: > If I understand that correctly, this would mean to simply include the > particular version of a library that happens to be the current one at > the report deadline. In other words, the report specifies that say > version 4.1.0.0 of the base library is the standard one for 2010. yes, we already do it for Haskell Platform. sometime ago i've proposed to define HP as a set of library versions for every year. i.e. HP 2009 include base4, fps1 and so on. now i shift this idea into Library Report but i should note that on HP level we don't yet make year-wise standards, afair it was consensus to issue next major HP version every 6 monthes or so? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ml at isaac.cedarswampstudios.org Wed Jul 8 15:05:44 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Wed Jul 8 14:48:22 2009 Subject: Haskell 2010: libraries In-Reply-To: References: <4A54A899.1030801@gmail.com> <547360499.20090708184228@gmail.com> Message-ID: <4A54EE08.3050801@isaac.cedarswampstudios.org> Heinrich Apfelmus wrote: > If I understand that correctly, this would mean to simply include the > particular version of a library that happens to be the current one at > the report deadline. In other words, the report specifies that say > version 4.1.0.0 of the base library is the standard one for 2010. > > Since old library versions are archived on hackage, this looks like a > cheap and easy solution to me. It's more an embellishment of alternative > 1. than a genuine 3. It could be a mere informative reference: "the most-community-accepted libraries at the time of publication are:". Keep in mind also that some of the libraries change irrevocably (like base has; with changes like Unicode I/O, or adding the Category class above Arrow. When it is tied to a particular compiler version it's less trivial to support multiple libraries... or even when it's not, version skew can get annoying -Isaac From bulat.ziganshin at gmail.com Wed Jul 8 15:51:20 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jul 8 15:38:30 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A54EE08.3050801@isaac.cedarswampstudios.org> References: <4A54A899.1030801@gmail.com> <547360499.20090708184228@gmail.com> <4A54EE08.3050801@isaac.cedarswampstudios.org> Message-ID: <743818781.20090708235120@gmail.com> Hello Isaac, Wednesday, July 8, 2009, 11:05:44 PM, you wrote: > It could be a mere informative reference: "the most-community-accepted > libraries at the time of publication are:". no, i mean that if we include some library in Haskell-2010, then it means that any compiler declared as H2010-compliant, is obliged to support this library of this exact version final goal is to allow someone to get code and compiler both meeting the same Haskell-20XX standard and be able to use the later on the former for sure. it's because we want to provide some base for learning Haskell, and, it will be great - for its industrial usage too this not necessarily should be bare compiler, but may be some compiler-based distribution like that existing Haskell Platform does for GHC -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Wed Jul 8 17:45:04 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Jul 8 17:27:15 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A54A899.1030801@gmail.com> References: <4A54A899.1030801@gmail.com> Message-ID: <20090708214504.GA13251@matrix.chaos.earth.li> On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: > > 1. Just drop the whole libraries section from the report. The > Report will still define the Prelude, however. > > I'm tending towards (1), mainly because it provides a clean break and is > likely to be the least confusing for users: they have one place to go > looking for library documentation. Sounds good to me. See also http://hackage.haskell.org/trac/haskell-prime/ticket/118 Thanks Ian From dons at galois.com Wed Jul 8 17:44:28 2009 From: dons at galois.com (Don Stewart) Date: Wed Jul 8 17:28:38 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <4A5355FE.9010901@gmail.com> References: <4A5355FE.9010901@gmail.com> Message-ID: <20090708214428.GI24309@whirlpool.galois.com> marlowsd: > At last year's Haskell Symposium, it was announced that we would change > the Haskell Prime process to make it less monolithic. Since then, > everyone has been busy using Haskell (or implementing it), and we > haven't made much progress on the standardisation side of things. Well, > with ICFP and the Haskell Symposium approaching we felt it was time to > get the new process moving and hopefully produce a language revision > this year. Tom Lokhorst suggests[1] Haskell'10 -- Don [1] http://twitter.com/tomlokhorst/statuses/2539313506 From bulat.ziganshin at gmail.com Wed Jul 8 17:55:24 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jul 8 17:37:56 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090708214504.GA13251@matrix.chaos.earth.li> References: <4A54A899.1030801@gmail.com> <20090708214504.GA13251@matrix.chaos.earth.li> Message-ID: <18876506.20090709015524@gmail.com> > On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: >> >> 1. Just drop the whole libraries section from the report. The >> Report will still define the Prelude, however. >> >> I'm tending towards (1), mainly because it provides a clean break and is >> likely to be the least confusing for users: they have one place to go >> looking for library documentation. while Hackage provides good place to look for library docs, it says Nothing about which libraries are standard instead, ghc bundled libs say it, replaced now by Haskell Platform libs. but these are de-facto standards, and i think that Report should support it by defining the same set as standard de-jure so, we will have H2010 as document defining standard and HP2010 as download implementing the standard -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed Jul 8 17:58:36 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jul 8 17:41:06 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <20090708214428.GI24309@whirlpool.galois.com> References: <4A5355FE.9010901@gmail.com> <20090708214428.GI24309@whirlpool.galois.com> Message-ID: <918899270.20090709015836@gmail.com> Hello Don, Thursday, July 9, 2009, 1:44:28 AM, you wrote: > Tom Lokhorst suggests[1] > > Haskell'10 now i understand - Haskell committee was just skipping those unbeautiful one-digit years :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From kahl at cas.mcmaster.ca Wed Jul 8 18:06:30 2009 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Wed Jul 8 17:48:45 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: <4A54585D.2070606@gmail.com> (message from Simon Marlow on Wed, 08 Jul 2009 09:27:09 +0100) References: <4A54585D.2070606@gmail.com> Message-ID: <20090708220630.25114.qmail@schroeder.cas.mcmaster.ca> Simon Marlow replied to Henning Thielemann: > Prelude.>>= just doesn't look like an infix operator. The point of > infix operators is that they are a lightweight notation, but they lose > that advantage when qualified. The qualified operator proposal gives > you a nice rule of thumb to rely on when parsing code in your head: if > it begins with a letter, it is not infix. The advantages of this > shouldn't be underestimated, IMO. Actually, I am another supporter of qualified infix operators. Is see on > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators that with the new proposal, I would have to write `Prelude.(>>=)` which in my opinion only asks for extension of the backquote symtax to arbitrary epressions, like `zipWith (+)` . I frequently run into situations where that would be extremely useful. > the M.. M... M.... debacle I don't think that problems arising from a single character should outlaw a whole lexical category. Better outlaw that character! ;-) The QualifiedOperators page also says: | You might argue that it is inconsistent to allow `(+)` but not allow | (`plus`), but the justification is simply that (..) and `..` are not | dual in this design. I would indeed argue that they should be dual. Back to the original argument: > Prelude.>>= just doesn't look like an infix operator. I think that `Prelude.(>>=)` doesn't really look like an infix operator either. If nobody else finds the time to do it, I'll hack lhs2TeX some day to generate a suscripted presentation, somewhat like |>>=|_{|Prelude|} from whichever variant will be legal at the time, and if the choice is among these two variants, I'd much prefer to type Prelude.>>= in my source code. Wolfram From kahl at cas.mcmaster.ca Wed Jul 8 18:43:01 2009 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Wed Jul 8 18:25:16 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <20090708214428.GI24309@whirlpool.galois.com> (message from Don Stewart on Wed, 8 Jul 2009 14:44:28 -0700) References: <4A5355FE.9010901@gmail.com> <20090708214428.GI24309@whirlpool.galois.com> Message-ID: <20090708224301.25229.qmail@schroeder.cas.mcmaster.ca> Don Stewart wrote: > > Tom Lokhorst suggests[1] > > Haskell'10 > > [1] http://twitter.com/tomlokhorst/statuses/2539313506 How pessimistic. Some people expect Haskell and/or Haskell' not to be around anymore in 2110? Wolfram From bulat.ziganshin at gmail.com Wed Jul 8 18:51:24 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jul 8 18:33:55 2009 Subject: Announcing the new Haskell Prime process, and Haskell 2010 In-Reply-To: <20090708224301.25229.qmail@schroeder.cas.mcmaster.ca> References: <4A5355FE.9010901@gmail.com> <20090708214428.GI24309@whirlpool.galois.com> <20090708224301.25229.qmail@schroeder.cas.mcmaster.ca> Message-ID: <1375438090.20090709025124@gmail.com> Hello kahl, Thursday, July 9, 2009, 2:43:01 AM, you wrote: >> Haskell'10 > Some people expect Haskell and/or Haskell' > not to be around anymore in 2110? it would be Haskell"10 :) ability to accurately count apostrophes is one of the prerequisites to learn Haskell :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From westondan at imageworks.com Thu Jul 9 00:26:21 2009 From: westondan at imageworks.com (Dan Weston) Date: Thu Jul 9 00:08:35 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: <20090708220630.25114.qmail@schroeder.cas.mcmaster.ca> References: <4A54585D.2070606@gmail.com> <20090708220630.25114.qmail@schroeder.cas.mcmaster.ca> Message-ID: <4A55716D.4090605@imageworks.com> kahl@cas.mcmaster.ca wrote: > which in my opinion only asks for extension of the backquote symtax to > arbitrary epressions, like > > `zipWith (+)` > > . I frequently run into situations where that would be extremely useful. What is the fixity and associativity of this infix "operator"? For that matter, in a let expression let (+++++) = (+) in 5 * 2 +++++ 3 - 2 what is the fixity and associativity of (+++++)? Does it inherit these from (+) by virtue of let? If not, then the obvious local workaround of let (>>=) = Prelude.(>>=) in .... >>= ... would not be a drop-in lexical substitution. > The QualifiedOperators page also says: > > | You might argue that it is inconsistent to allow `(+)` but not allow > | (`plus`), but the justification is simply that (..) and `..` are not > | dual in this design. > > I would indeed argue that they should be dual. So lexically, given an opening `, is the closing ` the first one enclosing balanced parentheses? 2 `(`(`(`(+)`)`)`)` 3 == 5 > Back to the original argument: > > > Prelude.>>= just doesn't look like an infix operator. > > I think that > > `Prelude.(>>=)` > > doesn't really look like an infix operator either. Wouldn't it be much cleaner to outlaw all qualified operators in lieu of a top-level import: import Prelude((>>=) as (>>>=), fst as myFst) leaving fixity and associativity of operators intact unless overridden: import Prelude((+) as (++++)) -- assumes infixl 6 as in Prelude infixr 3 ++++ -- but for this file I will change it Dan From marlowsd at gmail.com Thu Jul 9 07:02:56 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jul 9 06:45:16 2009 Subject: Proposals and owners In-Reply-To: <4A5461C9.5020501@gmail.com> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> Message-ID: <4A55CE60.702@gmail.com> We still need owners for: On 08/07/2009 10:07, Simon Marlow wrote: > > Remove n+k patterns > > NonDecreasingIndentation Cheers, Simon From marlowsd at gmail.com Thu Jul 9 07:22:32 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jul 9 07:04:43 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: <20090708220630.25114.qmail@schroeder.cas.mcmaster.ca> References: <4A54585D.2070606@gmail.com> <20090708220630.25114.qmail@schroeder.cas.mcmaster.ca> Message-ID: <4A55D2F8.80109@gmail.com> On 08/07/2009 23:06, kahl@cas.mcmaster.ca wrote: > Simon Marlow replied to Henning Thielemann: > > > Prelude.>>= just doesn't look like an infix operator. The point of > > infix operators is that they are a lightweight notation, but they lose > > that advantage when qualified. The qualified operator proposal gives > > you a nice rule of thumb to rely on when parsing code in your head: if > > it begins with a letter, it is not infix. The advantages of this > > shouldn't be underestimated, IMO. > > Actually, I am another supporter of qualified infix operators. > > Is see on > > > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators > > that with the new proposal, I would have to write > > `Prelude.(>>=)` You don't *have* to write that, you can use the prefix form. The argument that this proposal makes is that when you have to qualify an operator, it has lost most of the advantages of being infix. > . I frequently run into situations where that would be extremely useful. > > > > the M.. M... M.... debacle > > I don't think that problems arising from a single character > should outlaw a whole lexical category. > Better outlaw that character! ;-) Dot is a particularly troublesome character, owing to the decision to use it for qualified operators back in Haskell 1.3. It's really too late to change that now, sadly. > Back to the original argument: > > > Prelude.>>= just doesn't look like an infix operator. > > I think that > > `Prelude.(>>=)` > > doesn't really look like an infix operator either. It does begin with a `, just like `Data.List.map`, or `fmap`. So in that sense it is more like an infix operator than Prelude.>>=. Anyway, thanks for all the comments in this thread. I've tried to summarise the pros/cons on http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators Please let me know if I've missed anything. The committee will review the arguments when we make final decisions. I realise this change is not a clear-cut win. So few things are. It's a question of balancing the advantages against the disadvantages, and reasonable people are very likely to differ. Cheers, Simon From marlowsd at gmail.com Thu Jul 9 07:46:31 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jul 9 07:28:41 2009 Subject: Haskell 2010: libraries In-Reply-To: References: <4A54A899.1030801@gmail.com> <547360499.20090708184228@gmail.com> Message-ID: <4A55D897.6000803@gmail.com> On 08/07/2009 19:41, Heinrich Apfelmus wrote: > Bulat Ziganshin wrote: >> Simon Marlow wrote: >> >>> 3. Update the libraries to match what we have at the moment. >>> e.g. rename List to Data.List, and add the handful of >>> functions that have since been added to Data.List. One >>> problem with this is that these modules are then tied to >>> the language definition, and can't be changed through >>> the usual library proposal process. >> not necessarily. we already apply versioning to these libs, it may be >> made official in Report too. i.e. Report defines libraries standard >> for year 2010 (like it defines language standard for only one year), >> while we continue to improve libraries that will eventually become >> version standard for year 2011 (or higher) > > If I understand that correctly, this would mean to simply include the > particular version of a library that happens to be the current one at > the report deadline. In other words, the report specifies that say > version 4.1.0.0 of the base library is the standard one for 2010. > > Since old library versions are archived on hackage, this looks like a > cheap and easy solution to me. It's more an embellishment of alternative > 1. than a genuine 3. So, just to be clear, you're suggesting that we - remove the whole of the Library Report, - declare a list of packages and versions that we consider to be the standard libraries for Haskell 2010. This would be a bold step, in that we would be effectively standardising a lot more libraries than the current language standard. The base package is a fairly random bag of library modules, for instance. It contains a lot of modules that are only implemented by GHC. It contains backwards compatibility stuff (Control.OldException), and stuff that doesn't really belong (Data.HashTable). Perhaps we could explicitly list the modules that the standard requires. On the other hand, this would be a useful step, in that it gives users a wide base of libraries to rely on. And it's cheap to implement in the report. Any other thoughts? Cheers, Simon From allbery at ece.cmu.edu Thu Jul 9 08:15:51 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Jul 9 07:58:20 2009 Subject: Haskell 2010: libraries In-Reply-To: <18876506.20090709015524@gmail.com> References: <4A54A899.1030801@gmail.com> <20090708214504.GA13251@matrix.chaos.earth.li> <18876506.20090709015524@gmail.com> Message-ID: <4E779C31-A675-4339-994D-BCFD4849DA34@ece.cmu.edu> On Jul 8, 2009, at 17:55 , Bulat Ziganshin wrote: >> On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: >>> >>> 1. Just drop the whole libraries section from the report. The >>> Report will still define the Prelude, however. >>> >>> I'm tending towards (1), mainly because it provides a clean break >>> and is >>> likely to be the least confusing for users: they have one place to >>> go >>> looking for library documentation. > > instead, ghc bundled libs say it, replaced now by Haskell Platform > libs. > but these are de-facto standards, and i think that Report should > support > it by defining the same set as standard de-jure Perhaps the real answer is that the Report should bless the Haskell Platform - not any specific version of it. It occurs to me that the dependency might actually go the other way: a Haskell Platform release specifies which versions of the Haskell standard it complies with. (Including H98.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20090709/ecb20d5f/PGP.bin From bulat.ziganshin at gmail.com Thu Jul 9 08:26:57 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jul 9 08:09:46 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A55D897.6000803@gmail.com> References: <4A54A899.1030801@gmail.com> <547360499.20090708184228@gmail.com> <4A55D897.6000803@gmail.com> Message-ID: <1196585593.20090709162657@gmail.com> Hello Simon, Thursday, July 9, 2009, 3:46:31 PM, you wrote: > This would be a bold step, in that we would be effectively standardising > a lot more libraries than the current language standard. The base > package is a fairly random bag of library modules, for instance. It The base library is under the question, but remaining libs of ghc/HP are in rather good shape of course, without base we can't do even i/o, so questions still remains. in particular, you plan to do something with base in 6.12 although it was not yet decided what exactly so these two discussions (what to do with libs in 6.12 and what to do with libs in Report) may go together ideally, we would split base into smaller and versionable packages. at least in form of interfaces, while implementations will just import everything from base -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From marlowsd at gmail.com Thu Jul 9 08:44:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jul 9 08:27:05 2009 Subject: Haskell 2010: libraries In-Reply-To: <1196585593.20090709162657@gmail.com> References: <4A54A899.1030801@gmail.com> <547360499.20090708184228@gmail.com> <4A55D897.6000803@gmail.com> <1196585593.20090709162657@gmail.com> Message-ID: <4A55E646.7080405@gmail.com> On 09/07/2009 13:26, Bulat Ziganshin wrote: > Hello Simon, > > Thursday, July 9, 2009, 3:46:31 PM, you wrote: > >> This would be a bold step, in that we would be effectively standardising >> a lot more libraries than the current language standard. The base >> package is a fairly random bag of library modules, for instance. It > > The base library is under the question, but remaining libs of ghc/HP > are in rather good shape > > of course, without base we can't do even i/o, so questions still > remains. in particular, you plan to do something with base in 6.12 > although it was not yet decided what exactly > > so these two discussions (what to do with libs in 6.12 and what to do > with libs in Report) may go together > > ideally, we would split base into smaller and versionable packages. at > least in form of interfaces, while implementations will just import > everything from base I feel this discussion is widening a bit too far. The question at hand is how to make the Haskell 2010 Report self-consistent, avoid confusing users, and avoid perpetuating obsolete libraries. The Haskell Report doesn't have to specify libraries, it is not supposed to be a complete specification of the Haskell universe, it is a specification of the language. Remember that we're talking here about a *standard*. The Haskell Platform libraries, while being a hugely useful resource, are not specified to the level of precision we would expect for a Haskell standard. Neither have they undergone the level of scrutiny that we would ideally subject libraries to. So we can't just throw all this stuff in the standard and say "done!". Cheers, Simon From john at galois.com Thu Jul 9 14:06:33 2009 From: john at galois.com (John Launchbury) Date: Thu Jul 9 13:49:38 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: <4A55D2F8.80109@gmail.com> References: <4A54585D.2070606@gmail.com> <20090708220630.25114.qmail@schroeder.cas.mcmaster.ca> <4A55D2F8.80109@gmail.com> Message-ID: <2A57540C-8D23-42AC-BE0B-5F17745C1EA6@galois.com> Simon, Thanks for summarizing the arguments about qualified operators. I continue to be a strong advocate of this approach. IMO, we either have to do this, or disallow . (dot) as an operator, and I think you are right that it is too late to do the latter. In the proposed implementation of this change, you say: > Prelude.(>>=) has to be a single lexeme, because there's no way to > lift the syntax of qualified names into the context-free grammar. So > this forces us to move the syntax for parenthesized operators and > `..` down to the lexical syntax with the consequent behavior that `---` and (---) are not dual. Can you regain duality by *also* providing a definition of `---` and (---) at the level of the context free grammar? John John Launchbury | galois | (503)626-6616 x104 On Jul 9, 2009, at 4:22 AM, Simon Marlow wrote: > On 08/07/2009 23:06, kahl@cas.mcmaster.ca wrote: >> Simon Marlow replied to Henning Thielemann: >> >> > Prelude.>>= just doesn't look like an infix operator. The >> point of >> > infix operators is that they are a lightweight notation, but >> they lose >> > that advantage when qualified. The qualified operator proposal >> gives >> > you a nice rule of thumb to rely on when parsing code in your >> head: if >> > it begins with a letter, it is not infix. The advantages of this >> > shouldn't be underestimated, IMO. >> >> Actually, I am another supporter of qualified infix operators. >> >> Is see on >> >> > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators >> >> that with the new proposal, I would have to write >> >> `Prelude.(>>=)` > > You don't *have* to write that, you can use the prefix form. The > argument that this proposal makes is that when you have to qualify > an operator, it has lost most of the advantages of being infix. > >> . I frequently run into situations where that would be extremely >> useful. >> >> >> > the M.. M... M.... debacle >> >> I don't think that problems arising from a single character >> should outlaw a whole lexical category. >> Better outlaw that character! ;-) > > Dot is a particularly troublesome character, owing to the decision > to use it for qualified operators back in Haskell 1.3. It's really > too late to change that now, sadly. > >> Back to the original argument: >> >> > Prelude.>>= just doesn't look like an infix operator. >> >> I think that >> >> `Prelude.(>>=)` >> >> doesn't really look like an infix operator either. > > It does begin with a `, just like `Data.List.map`, or `fmap`. So in > that sense it is more like an infix operator than Prelude.>>=. > > Anyway, thanks for all the comments in this thread. I've tried to > summarise the pros/cons on > > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators > > Please let me know if I've missed anything. The committee will > review the arguments when we make final decisions. > > I realise this change is not a clear-cut win. So few things are. > It's a question of balancing the advantages against the > disadvantages, and reasonable people are very likely to differ. > > Cheers, > Simon > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090709/9f16969f/attachment.html From alexander.dunlap at gmail.com Thu Jul 9 15:20:25 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Thu Jul 9 15:02:53 2009 Subject: Haskell 2010: libraries In-Reply-To: <4E779C31-A675-4339-994D-BCFD4849DA34@ece.cmu.edu> References: <4A54A899.1030801@gmail.com> <20090708214504.GA13251@matrix.chaos.earth.li> <18876506.20090709015524@gmail.com> <4E779C31-A675-4339-994D-BCFD4849DA34@ece.cmu.edu> Message-ID: <57526e770907091220p3ca2factdb999845ee4e8832@mail.gmail.com> On Thu, Jul 9, 2009 at 5:15 AM, Brandon S. Allbery KF8NH wrote: > On Jul 8, 2009, at 17:55 , Bulat Ziganshin wrote: >>> >>> On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: >>>> >>>> 1. Just drop the whole libraries section from the report. ?The >>>> ? Report will still define the Prelude, however. >>>> >>>> I'm tending towards (1), mainly because it provides a clean break and is >>>> likely to be the least confusing for users: they have one place to go >>>> looking for library documentation. >> >> instead, ghc bundled libs say it, replaced now by Haskell Platform libs. >> but these are de-facto standards, and i think that Report should support >> it by defining the same set as standard de-jure > > > Perhaps the real answer is that the Report should bless the Haskell Platform > - not any specific version of it. ?It occurs to me that the dependency might > actually go the other way: ?a Haskell Platform release specifies which > versions of the Haskell standard it complies with. ?(Including H98.) > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university ? ?KF8NH I agree with this. The goal of the HP is that users are able to say "this package works with HP version X." The Platform should be the central compatibility point, and it should specify the version of the language used in the platform. I think there is an advantage to having just one compatibility layer to track (i.e. the Platform). If the Report specified a version of the Platform, but the Report were only offered half as often as the Platform, then we would get a weird situation with some HP releases being "report-blessed" and some not included in the report at all. Alex From marlowsd at gmail.com Fri Jul 10 05:05:52 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 10 04:48:01 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090708214504.GA13251@matrix.chaos.earth.li> References: <4A54A899.1030801@gmail.com> <20090708214504.GA13251@matrix.chaos.earth.li> Message-ID: <4A570470.2070301@gmail.com> On 08/07/2009 22:45, Ian Lynagh wrote: > On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: >> 1. Just drop the whole libraries section from the report. The >> Report will still define the Prelude, however. >> >> I'm tending towards (1), mainly because it provides a clean break and is >> likely to be the least confusing for users: they have one place to go >> looking for library documentation. > > Sounds good to me. > > See also http://hackage.haskell.org/trac/haskell-prime/ticket/118 Ian, would you like to take ownership for this proposal, and start fleshing out the details in a wiki page? There seems to be support for removing all the libraries in the report. Whether the report also blesses either the Haskell Platform or a set of packages is a separate matter; either way, we still have to extract the existing libraries from the report, and there will be a set of changes to the report necessary to make that happen. The Report should explicitly list all the library entities that it refers to. Cheers, Simon From apfelmus at quantentunnel.de Fri Jul 10 05:08:05 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Fri Jul 10 04:50:22 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A55D897.6000803@gmail.com> References: <4A54A899.1030801@gmail.com> <547360499.20090708184228@gmail.com> <4A55D897.6000803@gmail.com> Message-ID: Simon Marlow wrote: > Heinrich Apfelmus wrote: >> >> If I understand that correctly, this would mean to simply include the >> particular version of a library that happens to be the current one at >> the report deadline. In other words, the report specifies that say >> version 4.1.0.0 of the base library is the standard one for 2010. >> >> Since old library versions are archived on hackage, this looks like a >> cheap and easy solution to me. It's more an embellishment of alternative >> 1. than a genuine 3. > > So, just to be clear, you're suggesting that we > > - remove the whole of the Library Report, > > - declare a list of packages and versions that we consider > to be the standard libraries for Haskell 2010. Yes. > This would be a bold step, in that we would be effectively standardising > a lot more libraries than the current language standard. The base > package is a fairly random bag of library modules, for instance. It > contains a lot of modules that are only implemented by GHC. It contains > backwards compatibility stuff (Control.OldException), and stuff that > doesn't really belong (Data.HashTable). Perhaps we could explicitly > list the modules that the standard requires. Oh, that sounds more bold than I expected it to be. Yes, I agree that we should exclude modules that don't really belong; this should be cheap to implement. > On the other hand, this would be a useful step, in that it gives users a > wide base of libraries to rely on. And it's cheap to implement in the > report. > > Any other thoughts? The way I imagine it is that the libraries thus standardized will *not* be the libraries that most people are going to use; the latest versions of the base library or the Haskell Platform will define a current set of "standard" libraries. Rather, I imagine the libraries standardized in the report to be a reference for writing code that does not need to be updated when base or the HP change. Put differently, if I put the {-# LANGUAGE Haskell'2010 #-} flag into my source code, then I'm assured that it will compile for all eternity because my favorite compiler is going to use the base library specified in the report instead of the newest base library available on hackage. This requires compiler support. In other words, this is option 1. embellished with the cheapest way of blessing a bunch libraries for the purpose of backward compatibility. This may not be the best solution to the backward compatibility VS libraries change dilemma, but I think it reflects current practice. I can write strict H98 if I want to, but most of the time I'm just going to use the latest base anyway. On a side note, if Haskell 2010 gets a library report, then I think this should be in the form of a simple package on hackage, named something like "haskell2010-libraries". Regards, apfelmus -- http://apfelmus.nfshost.com From ross at soi.city.ac.uk Fri Jul 10 06:56:03 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Jul 10 06:38:13 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A54A899.1030801@gmail.com> References: <4A54A899.1030801@gmail.com> Message-ID: <20090710105603.GA5740@soi.city.ac.uk> On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: > 1. Just drop the whole libraries section from the report. The > Report will still define the Prelude, however. > > There will be some loose ends where the rest of the report > refers to entities from these libraries, e.g. the Prelude > refers to Rational from the Ratio library. We just have to > fix up these references, moving the appropriate definitions > into the Report as necessary. Some of the loose ends: The defaulting rules (section 4.3.4) apply to any class "defined in the Prelude or a standard library". The non-Prelude classes involved are Ix and Random. The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16, Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should move to the Prelude when the non-library part of the FFI spec is incorporated into the Report? The Prelude specification imports Char, Numeric and Ratio. It also uses (but does not import) IO(BufferMode(..), hSetBuffering, stdio, stdout). The Numeric specification imports Array, but only uses it for an optimization of 2^n. From chak at cse.unsw.edu.au Fri Jul 10 19:01:52 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Fri Jul 10 18:43:58 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A570470.2070301@gmail.com> References: <4A54A899.1030801@gmail.com> <20090708214504.GA13251@matrix.chaos.earth.li> <4A570470.2070301@gmail.com> Message-ID: Simon Marlow: > On 08/07/2009 22:45, Ian Lynagh wrote: >> On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: >>> 1. Just drop the whole libraries section from the report. The >>> Report will still define the Prelude, however. >>> >>> I'm tending towards (1), mainly because it provides a clean break >>> and is >>> likely to be the least confusing for users: they have one place to >>> go >>> looking for library documentation. >> >> Sounds good to me. >> >> See also http://hackage.haskell.org/trac/haskell-prime/ticket/118 > > Ian, would you like to take ownership for this proposal, and start > fleshing out the details in a wiki page? > > There seems to be support for removing all the libraries in the > report. Whether the report also blesses either the Haskell Platform > or a set of packages is a separate matter; either way, we still have > to extract the existing libraries from the report, and there will be > a set of changes to the report necessary to make that happen. The > Report should explicitly list all the library entities that it > refers to. I don't mind defining libraries separately, but not defining them at all is problematic unless a core set of libraries isn't rigorously defined somewhere else. Manuel From ashley at semantic.org Sat Jul 11 01:06:34 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Jul 11 00:48:54 2009 Subject: Outlaw tabs In-Reply-To: <1232805074.8432.391.camel@localhost> References: <20090124003526.0b8814cf@solaris> <1232805074.8432.391.camel@localhost> Message-ID: Duncan Coutts wrote: > If there is consensus on the tabs issue > then we could ask for -fwarn-tabs to be included in -Wall. Does -fwarn-tabs complain about tabs in "{;}"-style? It should not. -- Ashley Yakeley From ross at soi.city.ac.uk Sat Jul 11 05:01:28 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Jul 11 04:43:32 2009 Subject: Proposals and owners In-Reply-To: <20090708093328.GA6162@soi.city.ac.uk> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> Message-ID: <20090711090128.GA5861@soi.city.ac.uk> I've had a go at #65 RelaxedDependencyAnalysis: http://hackage.haskell.org/trac/haskell-prime/wiki/RelaxedDependencyAnalysis From chak at cse.unsw.edu.au Sat Jul 11 06:54:14 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sat Jul 11 06:36:20 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090710105603.GA5740@soi.city.ac.uk> References: <4A54A899.1030801@gmail.com> <20090710105603.GA5740@soi.city.ac.uk> Message-ID: <03E73F28-E6C1-43F7-84E5-E5AD7E5D0D92@cse.unsw.edu.au> Ross Paterson: > On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: >> 1. Just drop the whole libraries section from the report. The >> Report will still define the Prelude, however. >> >> There will be some loose ends where the rest of the report >> refers to entities from these libraries, e.g. the Prelude >> refers to Rational from the Ratio library. We just have to >> fix up these references, moving the appropriate definitions >> into the Report as necessary. > > Some of the loose ends: > > The defaulting rules (section 4.3.4) apply to any class "defined in > the > Prelude or a standard library". The non-Prelude classes involved are > Ix and Random. > > The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16, > Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they > should move > to the Prelude when the non-library part of the FFI spec is > incorporated > into the Report? If we have these types in the Prelude, the associated functions should be in the Prelude, too, and I'd be reluctant to include operations that are not memory-safe in the Prelude. So, I think, we need at least a standard library for the FFI. (In the FFI spec, we after all went to a lot of trouble to realise as much as possible of the needed functionality as libraries, to change the core language as little as possible.) I understand the desire to cut down on the number of library functions defined in the report, but ultimately, the language needs to provide a basic set of functionality that is the basis for implementing all the other libraries. Otherwise, the usefulness of the standard gets undermined. Apart from the Prelude, I think we should ask the following question to decide whether we can omit some library functionality from the language definition: If we omit the functionality under consideration, can we implement it in a portable manner with what remains in the definition? If that is not the case, we ought to include it. Manuel PS: As a historical anecdote, it was a major shortcoming of Modula-2 over C that Modula-2 didn't define it's basic libraries properly with the language (whereas C did). From ross at soi.city.ac.uk Sat Jul 11 07:14:05 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Jul 11 06:56:08 2009 Subject: Haskell 2010: libraries In-Reply-To: <03E73F28-E6C1-43F7-84E5-E5AD7E5D0D92@cse.unsw.edu.au> References: <4A54A899.1030801@gmail.com> <20090710105603.GA5740@soi.city.ac.uk> <03E73F28-E6C1-43F7-84E5-E5AD7E5D0D92@cse.unsw.edu.au> Message-ID: <20090711111405.GA6550@soi.city.ac.uk> On Sat, Jul 11, 2009 at 08:54:14PM +1000, Manuel M T Chakravarty wrote: > Ross Paterson: >> The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16, >> Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should >> move to the Prelude when the non-library part of the FFI spec is >> incorporated into the Report? > > If we have these types in the Prelude, the associated functions should > be in the Prelude, too, and I'd be reluctant to include operations that > are not memory-safe in the Prelude. So, I think, we need at least a > standard library for the FFI. (In the FFI spec, we after all went to a > lot of trouble to realise as much as possible of the needed > functionality as libraries, to change the core language as little as > possible.) The difference is that the types are used by the core language definition (section 3.2 of the FFI Addendum), and the functions aren't. From ashley at semantic.org Sat Jul 11 16:03:02 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Jul 11 15:45:17 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090710105603.GA5740@soi.city.ac.uk> References: <4A54A899.1030801@gmail.com> <20090710105603.GA5740@soi.city.ac.uk> Message-ID: Ross Paterson wrote: > The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16, > Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should move > to the Prelude when the non-library part of the FFI spec is incorporated > into the Report? > > The Prelude specification imports Char, Numeric and Ratio. It also uses > (but does not import) IO(BufferMode(..), hSetBuffering, stdio, stdout). > The Numeric specification imports Array, but only uses it for an > optimization of 2^n. The Prelude seems to do double duty: * stuff needed to support the language definition, etc. * useful stuff you'll probably want to import Is it worth separating these? -- Ashley Yakeley From igloo at earth.li Sat Jul 11 16:09:15 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jul 11 15:51:17 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A570470.2070301@gmail.com> References: <4A54A899.1030801@gmail.com> <20090708214504.GA13251@matrix.chaos.earth.li> <4A570470.2070301@gmail.com> Message-ID: <20090711200915.GA4807@matrix.chaos.earth.li> On Fri, Jul 10, 2009 at 10:05:52AM +0100, Simon Marlow wrote: > On 08/07/2009 22:45, Ian Lynagh wrote: >> On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: >>> 1. Just drop the whole libraries section from the report. The >>> Report will still define the Prelude, however. >>> >>> I'm tending towards (1), mainly because it provides a clean break and is >>> likely to be the least confusing for users: they have one place to go >>> looking for library documentation. >> >> Sounds good to me. >> >> See also http://hackage.haskell.org/trac/haskell-prime/ticket/118 > > Ian, would you like to take ownership for this proposal, and start > fleshing out the details in a wiki page? OK, will do. Thanks Ian From ashley at semantic.org Sat Jul 11 19:06:06 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Jul 11 18:48:16 2009 Subject: [Proposal] Move most of Control.Monad to Control.Applicative In-Reply-To: <20090321000352.5aefcaad@solaris> References: <07248FD7-D6FD-4BD1-8C7D-9C30E326585D@gmail.com> <20090320230222.35567b6c@solaris> <20090321000352.5aefcaad@solaris> Message-ID: Achim Schneider wrote: > Conal Elliott wrote: > >> Exactly. and <*>, liftA, liftA2, ... >> > I think it's safe to say that there's a general consensus that Functor > not being a superclass of Monad is a regrettable historical ward that > ought to be fixed... the problem with fixing it is that it opens up a > whole can of worms, only starting with whether or not Pointed should be > a class by itself: While the Proper Way might be to include all of > category-extras in the Prelude, the Proper Way might not at all be the > Right Way. I proposed this a year ago, but got no traction because people insisted on some extension called "class aliases" so they wouldn't have to write this piece of code: class Functor MyMonad where fmap = liftM class Applicative MyMonad where <*> = ap See http://thread.gmane.org/gmane.comp.lang.haskell.prime/2641/ -- Ashley Yakeley From ashley at semantic.org Sat Jul 11 19:08:49 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Jul 11 18:52:02 2009 Subject: [Proposal] Move most of Control.Monad to Control.Applicative In-Reply-To: References: <07248FD7-D6FD-4BD1-8C7D-9C30E326585D@gmail.com> <20090320230222.35567b6c@solaris> <20090321000352.5aefcaad@solaris> Message-ID: Oops, I don't seem to be paying attention to dates on posts. -- Ashley Yakeley From haskell at henning-thielemann.de Sun Jul 12 17:32:37 2009 From: haskell at henning-thielemann.de (haskell@henning-thielemann.de) Date: Sun Jul 12 17:14:38 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: References: Message-ID: On Tue, 7 Jul 2009, haskell@henning-thielemann.de wrote: > I like to note that I'm against this proposal. The example given in > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators > namely [Red..] can be easily resolved by adding a space, thus [Red ..]. I > use qualified operators occasionally, since I use NumericPrelude and thus > have to import some things from Prelude in a qualified way. As there will > appear more and more infix operators in libraries along with more name > clashes (e.g. recently discussed List.++ and Monoid.++), qualified operator > names will become not so uncommon. Of course, to keep the spirit of infix > operators, you will better define custom operators locally, but this is only > reasonable if you use an infix operator more than once. > The current syntax is also in a way consistent, since e.g. (+) coincides > with a two side operator section, which is no longer true with the new > proposal. Should the consistency with operator section also be added as 'cons' to http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators ? > Also (...) and `...` are dual, which is a nice property. From crmills_2000 at yahoo.com Sun Jul 12 19:44:24 2009 From: crmills_2000 at yahoo.com (Carlton Mills) Date: Sun Jul 12 19:26:21 2009 Subject: Add units - include furlongs/fortnight in addition to SI units In-Reply-To: References: Message-ID: <359827.58908.qm@web65610.mail.ac4.yahoo.com> I can't see where this has been proposed, so I will propose it. It is clear that programming languages vars/expressions will be required to carry units in addition to the value. A mission to Mars was botched because of units mismatch that was not caught. The languages F# and Fortress include a way to specify units on a variable and value. The compiler enforces unit conformance. I have no idea if automatic conversion is a good idea or not. I have no idea what the proper technical term I should have used; thus the use of furlongs in the subject to get attention. I don't know if this is difficult or not, but I am reasonable sure that compiler enforced units conformance will be required in government and space agency contracts. (Probably will happen a year after M$ has a good implementation available - this could be a competitive advantage). -Carlton Mills, Urbana, Illinois From marlowsd at gmail.com Mon Jul 13 05:40:15 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jul 13 05:22:13 2009 Subject: Haskell 2010: libraries In-Reply-To: <03E73F28-E6C1-43F7-84E5-E5AD7E5D0D92@cse.unsw.edu.au> References: <4A54A899.1030801@gmail.com> <20090710105603.GA5740@soi.city.ac.uk> <03E73F28-E6C1-43F7-84E5-E5AD7E5D0D92@cse.unsw.edu.au> Message-ID: <4A5B00FF.2010408@gmail.com> On 11/07/2009 11:54, Manuel M T Chakravarty wrote: > Ross Paterson: >> On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: >>> 1. Just drop the whole libraries section from the report. The >>> Report will still define the Prelude, however. >>> >>> There will be some loose ends where the rest of the report >>> refers to entities from these libraries, e.g. the Prelude >>> refers to Rational from the Ratio library. We just have to >>> fix up these references, moving the appropriate definitions >>> into the Report as necessary. >> >> Some of the loose ends: >> >> The defaulting rules (section 4.3.4) apply to any class "defined in the >> Prelude or a standard library". The non-Prelude classes involved are >> Ix and Random. >> >> The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16, >> Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should move >> to the Prelude when the non-library part of the FFI spec is incorporated >> into the Report? > > If we have these types in the Prelude, the associated functions should > be in the Prelude, too, and I'd be reluctant to include operations that > are not memory-safe in the Prelude. So, I think, we need at least a > standard library for the FFI. (In the FFI spec, we after all went to a > lot of trouble to realise as much as possible of the needed > functionality as libraries, to change the core language as little as > possible.) The functions don't necessarily have to be in the Prelude too - the point of putting the types there is so that we can specify what a valid foreign import/export declaration is. > I understand the desire to cut down on the number of library functions > defined in the report, but ultimately, the language needs to provide a > basic set of functionality that is the basis for implementing all the > other libraries. Otherwise, the usefulness of the standard gets undermined. The usefulness of the standard is already undermined by specifying a set of libraries that we don't recommend people use, and that differ in confusing ways from the libraries that we do recommend people use (e.g. they have different names, such as CForeign vs. Foreign.C). I'm all for having standard libraries, but we have to think about what we can practically accomplish for Haskell 2010. > Apart from the Prelude, I think we should ask the following question to > decide whether we can omit some library functionality from the language > definition: > > If we omit the functionality under consideration, > can we implement it in a portable manner with what remains in the > definition? > > If that is not the case, we ought to include it. I don't like to think of this in terms of "omitting functionality from the language definition". It's more a case of deferring the standardisation of libraries in the Report, until such time as we can produce a polished library standard. The functionality is still there, in the implementations, well documented, and in the FFI spec. It is also explicitly versioned in the Haskell Platform, so language implementers can all agree on what to provide. To use the above test would mean we could avoid specifying some libraries but not others, based on some criteria that is not important to users. I don't think this is the right way to approach the problem. Some libraries inevitably have non-portable implementations: e.g. Data.Typeable, Control.Exception, Data.IORef. We would be able to leave out Data.List, but not Foreign.StablePtr. Which is more useful? Another option (option (3) in my original mail) is to rename all the FFI libraries to use the hierarchical names and include them in the Report. But what other libraries should we include? I favour this approach slightly less than just leaving out all the libraries, mainly because the result would be an fairly arbitrary collection of library modules, which is of limited use to both users and language implementers. It may serve as a start for a larger collection of standard libraries; however, it would also be quite a lot of work to get this done for Haskell 2010. > PS: As a historical anecdote, it was a major shortcoming of Modula-2 > over C that Modula-2 didn't define it's basic libraries properly with > the language (whereas C did). I completely agree there should be standard libraries. But I don't think that should prevent us from producing a language revision in the short term. Cheers, Simon From alexander.dunlap at gmail.com Mon Jul 13 06:56:35 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Mon Jul 13 06:38:50 2009 Subject: Add units - include furlongs/fortnight in addition to SI units In-Reply-To: <359827.58908.qm@web65610.mail.ac4.yahoo.com> References: <359827.58908.qm@web65610.mail.ac4.yahoo.com> Message-ID: <57526e770907130356s4d0ffe3cv658acc1ade992ac@mail.gmail.com> I think there's a library called "dimensional" or something that does this sort of thing. Alex On Sun, Jul 12, 2009 at 7:44 PM, Carlton Mills wrote: > > ?I can't see where this has been proposed, so I will propose it. It is clear that programming languages vars/expressions will be required to carry units in addition to the value. A mission to Mars was botched because of units mismatch that was not caught. The languages F# and Fortress include a way to specify units on a variable and value. The compiler enforces unit conformance. > > ?I have no idea if automatic conversion is a good idea or not. > > ?I have no idea what the proper technical term I should have used; thus the use of furlongs in the subject to get attention. > > ?I don't know if this is difficult or not, but I am reasonable sure that compiler enforced units conformance will be required in government and space agency contracts. (Probably will happen a year after M$ has a good implementation available - this could be a competitive advantage). > > -Carlton Mills, Urbana, Illinois > > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From marlowsd at gmail.com Mon Jul 13 07:26:32 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jul 13 07:08:29 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: References: Message-ID: <4A5B19E8.3070005@gmail.com> On 12/07/2009 22:32, haskell@henning-thielemann.de wrote: > > On Tue, 7 Jul 2009, haskell@henning-thielemann.de wrote: > >> I like to note that I'm against this proposal. The example given in >> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators >> namely [Red..] can be easily resolved by adding a space, thus [Red >> ..]. I use qualified operators occasionally, since I use >> NumericPrelude and thus have to import some things from Prelude in a >> qualified way. As there will appear more and more infix operators in >> libraries along with more name clashes (e.g. recently discussed >> List.++ and Monoid.++), qualified operator names will become not so >> uncommon. Of course, to keep the spirit of infix operators, you will >> better define custom operators locally, but this is only reasonable if >> you use an infix operator more than once. >> The current syntax is also in a way consistent, since e.g. (+) >> coincides with a two side operator section, which is no longer true >> with the new proposal. > > Should the consistency with operator section also be added as 'cons' to > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators > ? So correct me if I'm wrong; the point you're making is: left section right section prefix unqualified (+ 1) (1 +) (+) Haskell 98 (M.+ 1) (1 M.+) (M.+) proposed (`M.(+)` 1) (1 `M.(+)`) M.(+) or(*) (M.(+) 1) (flip M.(+) 1) (*) only if precedence isn't important, e.g. not in cases like (`M.(+)` x `M.(*)` y). Cheers, Simon From duncan.coutts at worc.ox.ac.uk Mon Jul 13 16:56:50 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jul 13 16:38:52 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A54A899.1030801@gmail.com> References: <4A54A899.1030801@gmail.com> Message-ID: <1247518610.22466.8877.camel@localhost> On Wed, 2009-07-08 at 15:09 +0100, Simon Marlow wrote: > I'm mainly concerned with projecting a consistent picture in the Report, > so as not to mislead or confuse people. Here are the options I can see: > 2. Just drop the obvious candidates (Time, Random, CPUTime, > Locale, Complex?), leaving the others. > > 3. Update the libraries to match what we have at the moment. > e.g. rename List to Data.List, and add the handful of > functions that have since been added to Data.List. One > problem with this is that these modules are then tied to > the language definition, and can't be changed through > the usual library proposal process. Also it would seem > slightly strange to have a seemingly random set > of library modules in the report. > > 4. Combine 2 and 3: drop some, rename the rest. I'd advocate 4. That is, drop the ones that are obviously superseded. Keep the commonly used and uncontroversial (mostly pure) modules and rename them to use the new hierarchical module names. Specifically, I suggest: 1. Ratio keep as Data.Ratio 2. Complex keep as Data.Complex 3. Numeric keep as Numeric (?) 4. Ix keep as Data.Ix 5. Array keep as Data.Array 6. List keep as Data.List 7. Maybe keep as Data.Maybe 8. Char keep as Data.Char 9. Monad keep as Control.Monad 10. IO keep as System.IO 11. Directory drop 12. System drop (superseded by System.Process) 13. Time drop 14. Locale drop 15. CPUTime drop 16. Random drop The slightly odd thing here is keeping System.IO but dropping the other IO libs Directory and System. We obviously have to drop System, because it's more or less a deprecated API and it's superseded by System.Process (which we almost certainly do not want to standardise at this stage). It'd be nice to have a clear dividing line of keeping the pure stuff and dropping the bits for interacting with the system however we have to keep System.IO since bits of it are re-exported through the Prelude (unless we also trim the Prelude). The bits for interacting with the system are of course exactly the bits that are most prone to change and are most in need of improvement. Another quirk is that we never changed the name of the Numeric module. Duncan From haskell at henning-thielemann.de Mon Jul 13 17:00:27 2009 From: haskell at henning-thielemann.de (haskell@henning-thielemann.de) Date: Mon Jul 13 16:42:43 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: <4A5B19E8.3070005@gmail.com> References: <4A5B19E8.3070005@gmail.com> Message-ID: On Mon, 13 Jul 2009, Simon Marlow wrote: > On 12/07/2009 22:32, haskell@henning-thielemann.de wrote: >> >> Should the consistency with operator section also be added as 'cons' to >> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators >> ? > > So correct me if I'm wrong; the point you're making is: > > left section right section prefix > unqualified (+ 1) (1 +) (+) > Haskell 98 (M.+ 1) (1 M.+) (M.+) > proposed (`M.(+)` 1) (1 `M.(+)`) M.(+) > or(*) (M.(+) 1) (flip M.(+) 1) > > (*) only if precedence isn't important, e.g. not in cases like (`M.(+)` x > `M.(*)` y). Yes, that's what I meant. Thanks for working it out! From duncan.coutts at worc.ox.ac.uk Mon Jul 13 16:59:35 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jul 13 18:51:25 2009 Subject: Haskell 2010: libraries In-Reply-To: <1247518610.22466.8877.camel@localhost> References: <4A54A899.1030801@gmail.com> <1247518610.22466.8877.camel@localhost> Message-ID: <1247518775.22466.8879.camel@localhost> On Mon, 2009-07-13 at 21:57 +0100, Duncan Coutts wrote: > On Wed, 2009-07-08 at 15:09 +0100, Simon Marlow wrote: > > > I'm mainly concerned with projecting a consistent picture in the Report, > > so as not to mislead or confuse people. Here are the options I can see: > > > 2. Just drop the obvious candidates (Time, Random, CPUTime, > > Locale, Complex?), leaving the others. > > > > 3. Update the libraries to match what we have at the moment. > > e.g. rename List to Data.List, and add the handful of > > functions that have since been added to Data.List. One > > problem with this is that these modules are then tied to > > the language definition, and can't be changed through > > the usual library proposal process. Also it would seem > > slightly strange to have a seemingly random set > > of library modules in the report. Another thing we can do here is specify that the contents of these modules is a minimum and not a maximum, allowing additions through the usual library proposal process. > > 4. Combine 2 and 3: drop some, rename the rest. > > I'd advocate 4. That is, drop the ones that are obviously superseded. > Keep the commonly used and uncontroversial (mostly pure) modules and > rename them to use the new hierarchical module names. Oh and additionally include the FFI modules under their new names. Duncan From igloo at earth.li Mon Jul 13 19:20:42 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Jul 13 19:02:39 2009 Subject: Haskell 2010: libraries In-Reply-To: <1247518610.22466.8877.camel@localhost> References: <4A54A899.1030801@gmail.com> <1247518610.22466.8877.camel@localhost> Message-ID: <20090713232042.GA7309@matrix.chaos.earth.li> On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: > > I'd advocate 4. That is, drop the ones that are obviously superseded. > Keep the commonly used and uncontroversial (mostly pure) modules and > rename them to use the new hierarchical module names. > > Specifically, I suggest: > > 1. Ratio keep as Data.Ratio > 2. Complex keep as Data.Complex > 3. Numeric keep as Numeric (?) > 4. Ix keep as Data.Ix > 5. Array keep as Data.Array > 6. List keep as Data.List > 7. Maybe keep as Data.Maybe > 8. Char keep as Data.Char > 9. Monad keep as Control.Monad > 10. IO keep as System.IO > 11. Directory drop > 12. System drop (superseded by System.Process) > 13. Time drop > 14. Locale drop > 15. CPUTime drop > 16. Random drop We've been fortunate recently that, because the hierarchical modules haven't been in the standard, we've been able to extend and improve them without breaking compatibility with the language definition. In some cases, such as the changes to how exceptions work, we haven't had this freedom as the relevant functions are exposed by the Prelude, and that has been causing us grief for years. To take one example, since List was immortalised in the H98 report with 104 exports, Data.List has gained an additional 7 exports: foldl' foldl1' intercalate isInfixOf permutations stripPrefix subsequences The last change (making the behaviour of the generic* functions consistent with their non-generic counterparts) was less than a year ago, and the last additions were less than 2. It seems unlikely to me that all these libraries are finally perfect. If we freeze them too solidly then I'm sure that we will regret it. It is true that, with yearly language revisions, we have an annual opportunity to fix any problems. However, we also want the implementations to support several releases at once, and maintaining those old base libraries would be a lot of work and confusion for the minimal amount of benefit they would provide. But to me, the most compelling argument for dropping them from the report is that I can see no benefit to standardising them as part of the language, rather than in a separate "base libraries" standard. We would be able to act as if they were one standard if that were most convenient, but we would have the flexibility to take advantage of them being separate if necessary. Thanks Ian From ganesh.sittampalam at credit-suisse.com Tue Jul 14 02:48:36 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Jul 14 02:30:53 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090713232042.GA7309@matrix.chaos.earth.li> References: <4A54A899.1030801@gmail.com><1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> Ian Lynagh wrote: > On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: >> >> I'd advocate 4. That is, drop the ones that are obviously superseded. >> Keep the commonly used and uncontroversial (mostly pure) modules and >> rename them to use the new hierarchical module names. >> > > We've been fortunate recently that, because the hierarchical modules > haven't been in the standard, we've been able to extend and improve > them without breaking compatibility with the language definition. In > some cases, such as the changes to how exceptions work, we haven't > had this freedom as the relevant functions are exposed by the > Prelude, and that has been causing us grief for years. I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the "real" libraries. Clearly there is the downside that this will be rather verbose, but it should minimise the constraints placed on the faster moving libraries that most people use while still providing a properly standardised and stable set of code. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From bulat.ziganshin at gmail.com Tue Jul 14 03:56:07 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jul 14 03:39:20 2009 Subject: Haskell 2010: libraries In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> References: <4A54A899.1030801@gmail.com><1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> Message-ID: <1714242127.20090714115607@gmail.com> Hello Ganesh, Tuesday, July 14, 2009, 10:48:36 AM, you wrote: > I don't have any strong opinion about whether there should be a library > standard or not, but if there is a standard, how about putting the > entire thing (perhaps including the Prelude) under the prefix > Haskell2010. or similar? Most of it could be implemented by just > re-exporting things from the "real" libraries. we already have PvP mechanism for these things -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Tue Jul 14 03:57:11 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jul 14 03:39:23 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090713232042.GA7309@matrix.chaos.earth.li> References: <4A54A899.1030801@gmail.com> <1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> Message-ID: <1241949339.20090714115711@gmail.com> Hello Ian, Tuesday, July 14, 2009, 3:20:42 AM, you wrote: > We've been fortunate recently that, because the hierarchical modules > haven't been in the standard, we've been able to extend and improve them > without breaking compatibility with the language definition. but breaking compatibility with existing programs. i hate situation when we need to reupload entire hackage every year -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From malcolm.wallace at cs.york.ac.uk Tue Jul 14 03:58:12 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Jul 14 03:40:06 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: References: <4A5B19E8.3070005@gmail.com> Message-ID: <08E7BEF6-E197-45AE-AE7C-187914D21429@cs.york.ac.uk> >> left section right section prefix >> unqualified (+ 1) (1 +) (+) >> Haskell 98 (M.+ 1) (1 M.+) (M.+) >> proposed (`M.(+)` 1) (1 `M.(+)`) M.(+) >> or(*) (M.(+) 1) (flip M.(+) 1) The last line is not correct. (M.(+) 1) captures the first argument of the function, not the second like all the other entries in that column. Likewise the flip variant captures the second arg, where all the others capture the first. Regards, Malcolm From ganesh.sittampalam at credit-suisse.com Tue Jul 14 03:59:00 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Jul 14 03:41:59 2009 Subject: Haskell 2010: libraries In-Reply-To: <1714242127.20090714115607@gmail.com> References: <4A54A899.1030801@gmail.com><1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <1714242127.20090714115607@gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F77A@ELON17P32001A.csfb.cs-group.com> Bulat Ziganshin wrote: > Hello Ganesh, > > Tuesday, July 14, 2009, 10:48:36 AM, you wrote: > >> I don't have any strong opinion about whether there should be a >> library standard or not, but if there is a standard, how about >> putting the entire thing (perhaps including the Prelude) under the >> prefix Haskell2010. or similar? Most of it could be implemented by >> just re-exporting things from the "real" libraries. > > we already have PvP mechanism for these things The PvP isn't (proposed as) part of the standard, and without package qualified imports as implemented by GHC, it wouldn't help anyway. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From bulat.ziganshin at gmail.com Tue Jul 14 04:18:59 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jul 14 04:01:00 2009 Subject: Haskell 2010: libraries In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9F77A@ELON17P32001A.csfb.cs-group.com> References: <4A54A899.1030801@gmail.com><1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <1714242127.20090714115607@gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9F77A@ELON17P32001A.csfb.cs-group.com> Message-ID: <728873153.20090714121859@gmail.com> Hello Ganesh, Tuesday, July 14, 2009, 11:59:00 AM, you wrote: >>> I don't have any strong opinion about whether there should be a >>> library standard or not, but if there is a standard, how about >>> putting the entire thing (perhaps including the Prelude) under the >>> prefix Haskell2010. or similar? Most of it could be implemented by >>> just re-exporting things from the "real" libraries. >> >> we already have PvP mechanism for these things > The PvP isn't (proposed as) part of the standard, and without package > qualified imports as implemented by GHC, it wouldn't help anyway. but package versioning implemented by ghc, hugs and probably other compilers. with your idea we will have two things that address the same problem, and these will be miltiplied - i.e. we will carry several versions of base package, each having Haskell2010.*, Haskell2011.* and so on modules -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From malcolm.wallace at cs.york.ac.uk Tue Jul 14 04:27:22 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Jul 14 04:09:19 2009 Subject: Haskell 2010: libraries In-Reply-To: <1247518610.22466.8877.camel@localhost> References: <4A54A899.1030801@gmail.com> <1247518610.22466.8877.camel@localhost> Message-ID: <42E0EA5E-E4B8-45ED-9EB7-520A5020A702@cs.york.ac.uk> A natural "language" consists of a vocabulary of words, as well as a grammar for stringing them together. If we omit the common basic libraries from the language definition, then are we implicitly reducing the common vocabulary, and encouraging dialects to appear? If I see the function "scanr" in a module, should I expect that it has the semantics of Data.List.scanr? Or is it OK for someone to define their own Data.List with different semantics? > Keep the commonly used and uncontroversial (mostly pure) modules and > rename them to use the new hierarchical module names. I would largely concur with this policy, with the caveat that additions to the API might appear in future. Also, the hierarchical versions of the FFI libraries are essential. > 3. Numeric keep as Numeric (?) I think we could take the opportunity to rename it to Text.Numeric. Why Text? Because it only defines ReadS and ShowS things (with the exception of fromRat, and floatToDigits, sigh, which should be moved elsewhere). > It'd be nice to have a clear dividing line of keeping the pure stuff > and > dropping the bits for interacting with the system ... The bits for > interacting with the system are of course exactly the bits that are > most prone to change and are most in need of improvement. In some ways, it is _more_ important to standardise the difficult bits, i.e. interacting with the system, because otherwise it is desparately difficult to write portable programs. But I agree that the choices made in H'98 and earlier to abstract over the underlying OS were probably rather poor and inflexible, and it is probably unrealistic to be able to propose a new stable API for a couple of years yet. I do think we should set it as a goal for the future however. Regards, Malcolm From ganesh.sittampalam at credit-suisse.com Tue Jul 14 06:16:49 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Jul 14 05:59:20 2009 Subject: Haskell 2010: libraries In-Reply-To: <728873153.20090714121859@gmail.com> References: <4A54A899.1030801@gmail.com><1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <1714242127.20090714115607@gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9F77A@ELON17P32001A.csfb.cs-group.com> <728873153.20090714121859@gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F77E@ELON17P32001A.csfb.cs-group.com> Bulat Ziganshin wrote: > Hello Ganesh, > > Tuesday, July 14, 2009, 11:59:00 AM, you wrote: > >>>> I don't have any strong opinion about whether there should be a >>>> library standard or not, but if there is a standard, how about >>>> putting the entire thing (perhaps including the Prelude) under the >>>> prefix Haskell2010. or similar? Most of it could be implemented by >>>> just re-exporting things from the "real" libraries. >>> >>> we already have PvP mechanism for these things > >> The PvP isn't (proposed as) part of the standard, and without package >> qualified imports as implemented by GHC, it wouldn't help anyway. > > but package versioning implemented by ghc, hugs and probably other > compilers. Do you mean the syntax that allows modules to be imported from a specified package? If so I didn't realise this was implemented by anything more than GHC. > with your idea we will have two things that address the > same problem, Arguably it is the ability to import from a specified package that duplicates the disambiguation mechanism provided by module names. > and these will be miltiplied - i.e. we will carry > several versions of base package, each having Haskell2010.*, > Haskell2011.* and so on modules I'd expect the Haskell2010.* etc to be implemented in a haskell2010 package which depends on the relevant version of base. Obviously it would need to be updated when base was changed incompatibly. Having a library standard implies that implementations must support it for some period of time. I don't see why namespacing the libraries of that standard makes that any harder. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From duncan.coutts at worc.ox.ac.uk Tue Jul 14 07:23:51 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jul 14 07:05:30 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090713232042.GA7309@matrix.chaos.earth.li> References: <4A54A899.1030801@gmail.com> <1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> Message-ID: <1247570631.22466.8945.camel@localhost> On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote: > On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: > > > > I'd advocate 4. That is, drop the ones that are obviously superseded. > > Keep the commonly used and uncontroversial (mostly pure) modules and > > rename them to use the new hierarchical module names. > > > > Specifically, I suggest: > > > > 1. Ratio keep as Data.Ratio > > 2. Complex keep as Data.Complex > > 3. Numeric keep as Numeric (?) > > 4. Ix keep as Data.Ix > > 5. Array keep as Data.Array > > 6. List keep as Data.List > > 7. Maybe keep as Data.Maybe > > 8. Char keep as Data.Char > > 9. Monad keep as Control.Monad > > 10. IO keep as System.IO > > 11. Directory drop > > 12. System drop (superseded by System.Process) > > 13. Time drop > > 14. Locale drop > > 15. CPUTime drop > > 16. Random drop > > We've been fortunate recently that, because the hierarchical modules > haven't been in the standard, we've been able to extend and improve them > without breaking compatibility with the language definition. In some > cases, such as the changes to how exceptions work, we haven't had this > freedom as the relevant functions are exposed by the Prelude, and that > has been causing us grief for years. > > To take one example, since List was immortalised in the H98 report with > 104 exports, Data.List has gained an additional 7 exports: > foldl' > foldl1' > intercalate > isInfixOf > permutations > stripPrefix > subsequences > The last change (making the behaviour of the generic* functions > consistent with their non-generic counterparts) was less than a year > ago, and the last additions were less than 2. Though also note that we have not changed any of the existing ones. Is there a problem with specifying in the libraries section of the report that the exports are a minimum and not a maximum? > But to me, the most compelling argument for dropping them from the > report is that I can see no benefit to standardising them as part of the > language, rather than in a separate "base libraries" standard. Some functions, especially the pure ones are really part of the character of the language (and some are specified as part of the syntax). We have not had major problems with the pure parts of the standard libraries, our problems have almost all been with the system facing parts (handles, files, programs, exceptions). I don't see any particular problem with having some essential (in the sense of being part of the essence of the language) libraries in the main report and some separate libraries report in a year or two's time standardising some of the trickier aspects of libraries for portable programs to interact with the OS (addressing Malcolm's point about the need for this so as to be able to write portable programs). Duncan From igloo at earth.li Tue Jul 14 08:57:34 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Jul 14 08:39:27 2009 Subject: Haskell 2010: libraries In-Reply-To: <1247570631.22466.8945.camel@localhost> References: <4A54A899.1030801@gmail.com> <1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> <1247570631.22466.8945.camel@localhost> Message-ID: <20090714125734.GA17788@matrix.chaos.earth.li> On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote: > On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote: > > On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: > > > > > To take one example, since List was immortalised in the H98 report with > > 104 exports, Data.List has gained an additional 7 exports: > > > > The last change (making the behaviour of the generic* functions > > consistent with their non-generic counterparts) was less than a year > > ago, and the last additions were less than 2. > > Though also note that we have not changed any of the existing ones. Yes we have, less than a year ago: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> Data.List.genericTake (-1) "abc" "*** Exception: List.genericTake: negative argument GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> Data.List.genericTake (-1) "abc" "" > Is there a problem with specifying in the libraries section of the report > that the exports are a minimum and not a maximum? We wouldn't be able to fix the generic* functions, or the way exceptions work. > > But to me, the most compelling argument for dropping them from the > > report is that I can see no benefit to standardising them as part of the > > language, rather than in a separate "base libraries" standard. > > Some functions, especially the pure ones are really part of the > character of the language The Haskell language could be thought of as being composed of "Haskell Language 2010 report" and "Haskell Libraries 1.0 report". > (and some are specified as part of the > syntax) Yes, some types functions may need to be specified by the report as being somewhere for desugaring etc. Although maybe we could even eliminate most of these if rebindable syntax became part of the language? Thanks Ian From igloo at earth.li Tue Jul 14 08:59:55 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Jul 14 08:41:48 2009 Subject: Haskell 2010: libraries In-Reply-To: <1241949339.20090714115711@gmail.com> References: <4A54A899.1030801@gmail.com> <1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> <1241949339.20090714115711@gmail.com> Message-ID: <20090714125955.GB17788@matrix.chaos.earth.li> On Tue, Jul 14, 2009 at 11:57:11AM +0400, Bulat Ziganshin wrote: > Tuesday, July 14, 2009, 3:20:42 AM, you wrote: > > > We've been fortunate recently that, because the hierarchical modules > > haven't been in the standard, we've been able to extend and improve them > > without breaking compatibility with the language definition. > > but breaking compatibility with existing programs. i hate situation > when we need to reupload entire hackage every year Standardising the number of modules we're talking about isn't going to affect whether or not this happens. Also, just because the libraries are standardised separately doesn't mean that we /need/ to change them every year, it just makes it /possible/ to change them. Thanks Ian From marlowsd at gmail.com Tue Jul 14 09:44:59 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jul 14 09:26:56 2009 Subject: Proposal: change to qualified operator syntax In-Reply-To: <08E7BEF6-E197-45AE-AE7C-187914D21429@cs.york.ac.uk> References: <4A5B19E8.3070005@gmail.com> <08E7BEF6-E197-45AE-AE7C-187914D21429@cs.york.ac.uk> Message-ID: <4A5C8BDB.2020606@gmail.com> On 14/07/2009 08:58, Malcolm Wallace wrote: >>> left section right section prefix >>> unqualified (+ 1) (1 +) (+) >>> Haskell 98 (M.+ 1) (1 M.+) (M.+) >>> proposed (`M.(+)` 1) (1 `M.(+)`) M.(+) >>> or(*) (M.(+) 1) (flip M.(+) 1) > > The last line is not correct. (M.(+) 1) captures the first argument of > the function, not the second like all the other entries in that column. > Likewise the flip variant captures the second arg, where all the others > capture the first. oops, I got those the wrong way around. Well spotted. Fixed on the wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators Cheers, Simon From igloo at earth.li Tue Jul 14 10:04:27 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Jul 14 09:46:20 2009 Subject: Haskell 2010: libraries In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> Message-ID: <20090714140427.GA18755@matrix.chaos.earth.li> On Tue, Jul 14, 2009 at 07:48:36AM +0100, Sittampalam, Ganesh wrote: > > I don't have any strong opinion about whether there should be a library > standard or not, but if there is a standard, how about putting the > entire thing (perhaps including the Prelude) under the prefix > Haskell2010. or similar? Most of it could be implemented by just > re-exporting things from the "real" libraries. That would be OK with me, although I still think it would be easier for us to disentangle the library standardisation effort from the language standardisation effort. I'd suggest Haskell.V2010.Data.List (just re-exports from V2011 where possible) Haskell.V2010.Prelude (just re-exports from V2011 where possible) Haskell.V2011.Data.List Haskell.V2011.Prelude with the implicit Prelude import being changed to Haskell.V.Prelude where is that latest the compiler supports, unless you say e.g. -XHaskell2010. Thanks Ian From marlowsd at gmail.com Wed Jul 15 10:39:55 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 15 10:21:50 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090714140427.GA18755@matrix.chaos.earth.li> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <20090714140427.GA18755@matrix.chaos.earth.li> Message-ID: <4A5DEA3B.7040200@gmail.com> On 14/07/2009 15:04, Ian Lynagh wrote: > On Tue, Jul 14, 2009 at 07:48:36AM +0100, Sittampalam, Ganesh wrote: >> I don't have any strong opinion about whether there should be a library >> standard or not, but if there is a standard, how about putting the >> entire thing (perhaps including the Prelude) under the prefix >> Haskell2010. or similar? Most of it could be implemented by just >> re-exporting things from the "real" libraries. > > That would be OK with me, although I still think it would be easier for > us to disentangle the library standardisation effort from the language > standardisation effort. > > I'd suggest > > Haskell.V2010.Data.List (just re-exports from V2011 where possible) > Haskell.V2010.Prelude (just re-exports from V2011 where possible) > Haskell.V2011.Data.List > Haskell.V2011.Prelude > > with the implicit Prelude import being changed to > Haskell.V.Prelude > where is that latest the compiler supports, unless you say > e.g. -XHaskell2010. I find this rather jarring, because it moves versioning from where it should be (in the package metadata) to where it shouldn't be (in the module names). So why can't we use package versioning to do this? Suppose we have a 'haskell-std' package, with versions starting at 2010, providing modules like Data.List. The problem is that haskell-std:Data.List overlaps with base:Data.List. But there's a solution: we could remove the "standard" modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like build-depends: base-4.*, haskell-std-2010 (or does it have to be haskell-std-2010.0?) In some ways this is nice, because we will be able to keep old versions of haskell-std much longer than we can keep old versions of base. And in due course, we can move more modules into haskell-std. That makes an incremental approach to library standardisation possible, in the same way as we have modularised the language standardisation process. So, if we have standard Haskell library modules, then I believe they should be separate at the package level (as they are now). Cheers, Simon From ganesh.sittampalam at credit-suisse.com Wed Jul 15 10:47:33 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Jul 15 10:29:33 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A5DEA3B.7040200@gmail.com> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com><20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F7A0@ELON17P32001A.csfb.cs-group.com> Simon Marlow wrote: > On 14/07/2009 15:04, Ian Lynagh wrote: >> I'd suggest >> >> Haskell.V2010.Data.List (just re-exports from V2011 where >> possible) Haskell.V2010.Prelude (just re-exports from V2011 >> where possible) Haskell.V2011.Data.List >> Haskell.V2011.Prelude >> >> with the implicit Prelude import being changed to >> Haskell.V.Prelude >> where is that latest the compiler supports, unless you say >> e.g. -XHaskell2010. > > I find this rather jarring, because it moves versioning from where it > should be (in the package metadata) to where it shouldn't be (in the > module names). I'd say that versioning of standards is rather different from versioning of packages, which makes it less jarring, but yes, it doesn't feel very nice and it would make porting code forwards annoying. > But there's a solution: we could remove the "standard" modules from > base, and have them only provided by haskell-std (since base will > just be a re-exporting layer on top of base-internals, this will be > easy to do). Most packages will then have dependencies that look > like But this precludes the kind of changes to those modules that Ian described as having happened in the last few years. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From igloo at earth.li Wed Jul 15 10:54:44 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Jul 15 10:36:34 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A5DEA3B.7040200@gmail.com> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> Message-ID: <20090715145444.GA23367@matrix.chaos.earth.li> On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote: > > But there's a solution: we could remove the "standard" modules from > base, and have them only provided by haskell-std (since base will just > be a re-exporting layer on top of base-internals, this will be easy to > do). Most packages will then have dependencies that look like > > build-depends: base-4.*, haskell-std-2010 We'll probably end up with situations where one dependency of a package needs haskell-std-2010, and another needs haskell-std-2011. I don't know which impls support that at the moment. Thanks Ian From marlowsd at gmail.com Wed Jul 15 11:32:25 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 15 11:14:18 2009 Subject: Haskell 2010: libraries In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9F7A0@ELON17P32001A.csfb.cs-group.com> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com><20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9F7A0@ELON17P32001A.csfb.cs-group.com> Message-ID: <4A5DF689.8040101@gmail.com> On 15/07/2009 15:47, Sittampalam, Ganesh wrote: >> But there's a solution: we could remove the "standard" modules from >> base, and have them only provided by haskell-std (since base will >> just be a re-exporting layer on top of base-internals, this will be >> easy to do). Most packages will then have dependencies that look >> like > > But this precludes the kind of changes to those modules that Ian > described as having happened in the last few years. I don't follow. If we have versioned haskell-std packages, surely they can export different APIs? Cheers, Simon From marlowsd at gmail.com Wed Jul 15 11:33:20 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Jul 15 11:15:13 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090715145444.GA23367@matrix.chaos.earth.li> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> <20090715145444.GA23367@matrix.chaos.earth.li> Message-ID: <4A5DF6C0.8050700@gmail.com> On 15/07/2009 15:54, Ian Lynagh wrote: > On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote: >> But there's a solution: we could remove the "standard" modules from >> base, and have them only provided by haskell-std (since base will just >> be a re-exporting layer on top of base-internals, this will be easy to >> do). Most packages will then have dependencies that look like >> >> build-depends: base-4.*, haskell-std-2010 > > We'll probably end up with situations where one dependency of a package > needs haskell-std-2010, and another needs haskell-std-2011. I don't know > which impls support that at the moment. That's the case with base-3/base-4 at the moment. Is it a problem? Cheers, Simon From ganesh.sittampalam at credit-suisse.com Wed Jul 15 11:35:02 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Jul 15 11:17:26 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A5DF689.8040101@gmail.com> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com><20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9F7A0@ELON17P32001A.csfb.cs-group.com> <4A5DF689.8040101@gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F7A3@ELON17P32001A.csfb.cs-group.com> Simon Marlow wrote: > On 15/07/2009 15:47, Sittampalam, Ganesh wrote: > >>> But there's a solution: we could remove the "standard" modules from >>> base, and have them only provided by haskell-std (since base will >>> just be a re-exporting layer on top of base-internals, this will be >>> easy to do). Most packages will then have dependencies that look >>> like >> >> But this precludes the kind of changes to those modules that Ian >> described as having happened in the last few years. > > I don't follow. If we have versioned haskell-std packages, surely > they can export different APIs? I guess if all such changes were treated as candidates for the next version of the library standard, then that would work. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From redbeard0531 at gmail.com Wed Jul 15 12:03:49 2009 From: redbeard0531 at gmail.com (Mathias Stearn) Date: Wed Jul 15 11:45:58 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090715145444.GA23367@matrix.chaos.earth.li> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> <20090715145444.GA23367@matrix.chaos.earth.li> Message-ID: <3d03c0530907150903r36f8b3bdi96da68cd20f9562@mail.gmail.com> Would it be possible for the language to require that implementations support linking multiple versions of packages (at least base and haskell-std) into a single running instance? That would solve the issue of using two libs that depend on different versions. On Wed, Jul 15, 2009 at 10:54 AM, Ian Lynagh wrote: > On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote: >> >> But there's a solution: we could remove the "standard" modules from >> base, and have them only provided by haskell-std (since base will just >> be a re-exporting layer on top of base-internals, this will be easy to >> do). ?Most packages will then have dependencies that look like >> >> ? build-depends: base-4.*, haskell-std-2010 > > We'll probably end up with situations where one dependency of a package > needs haskell-std-2010, and another needs haskell-std-2011. I don't know > which impls support that at the moment. > > > Thanks > Ian > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From dave at zednenem.com Wed Jul 15 13:10:47 2009 From: dave at zednenem.com (David Menendez) Date: Wed Jul 15 12:52:36 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A5DF6C0.8050700@gmail.com> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> <20090715145444.GA23367@matrix.chaos.earth.li> <4A5DF6C0.8050700@gmail.com> Message-ID: <49a77b7a0907151010t12a55102o529ab2d68c75855d@mail.gmail.com> On Wed, Jul 15, 2009 at 11:33 AM, Simon Marlow wrote: > On 15/07/2009 15:54, Ian Lynagh wrote: >> >> On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote: >>> >>> But there's a solution: we could remove the "standard" modules from >>> base, and have them only provided by haskell-std (since base will just >>> be a re-exporting layer on top of base-internals, this will be easy to >>> do). ?Most packages will then have dependencies that look like >>> >>> ? build-depends: base-4.*, haskell-std-2010 >> >> We'll probably end up with situations where one dependency of a package >> needs haskell-std-2010, and another needs haskell-std-2011. I don't know >> which impls support that at the moment. > > That's the case with base-3/base-4 at the moment. ?Is it a problem? Could I use two packages of arrow code which depend on base 3.0.2 and base 3.0.3, respectively, in the same project? -- Dave Menendez From marlowsd at gmail.com Thu Jul 16 04:29:32 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jul 16 04:11:27 2009 Subject: Haskell 2010: libraries In-Reply-To: <3d03c0530907150903r36f8b3bdi96da68cd20f9562@mail.gmail.com> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> <20090715145444.GA23367@matrix.chaos.earth.li> <3d03c0530907150903r36f8b3bdi96da68cd20f9562@mail.gmail.com> Message-ID: <4A5EE4EC.20609@gmail.com> On 15/07/2009 17:03, Mathias Stearn wrote: > Would it be possible for the language to require that implementations > support linking multiple versions of packages (at least base and > haskell-std) into a single running instance? That would solve the > issue of using two libs that depend on different versions. The language definition says nothing about packages. As far as the Haskell standard is concerned, a Haskell program is just a collection of modules, including the Prelude. I'm fairly keen to keep things simple like this. The packaging system can be explained, without modifying the language standard, as a transformation on module names (e.g. prefixing each module name with an identifier representing the package instance it comes from). Cheers, Simon From marlowsd at gmail.com Thu Jul 16 04:36:56 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Jul 16 04:18:53 2009 Subject: Haskell 2010: libraries In-Reply-To: <49a77b7a0907151010t12a55102o529ab2d68c75855d@mail.gmail.com> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> <20090715145444.GA23367@matrix.chaos.earth.li> <4A5DF6C0.8050700@gmail.com> <49a77b7a0907151010t12a55102o529ab2d68c75855d@mail.gmail.com> Message-ID: <4A5EE6A8.4020900@gmail.com> On 15/07/2009 18:10, David Menendez wrote: > On Wed, Jul 15, 2009 at 11:33 AM, Simon Marlow wrote: >> On 15/07/2009 15:54, Ian Lynagh wrote: >>> On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote: >>>> But there's a solution: we could remove the "standard" modules from >>>> base, and have them only provided by haskell-std (since base will just >>>> be a re-exporting layer on top of base-internals, this will be easy to >>>> do). Most packages will then have dependencies that look like >>>> >>>> build-depends: base-4.*, haskell-std-2010 >>> We'll probably end up with situations where one dependency of a package >>> needs haskell-std-2010, and another needs haskell-std-2011. I don't know >>> which impls support that at the moment. >> That's the case with base-3/base-4 at the moment. Is it a problem? > > Could I use two packages of arrow code which depend on base 3.0.2 and > base 3.0.3, respectively, in the same project? No. (though I'm not sure the significance of "arrow code" here). Is there a package that depends on base-3.0.2, and doesn't work with base-3.0.3? Cheers, Simon From apfelmus at quantentunnel.de Thu Jul 16 07:31:41 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Thu Jul 16 07:13:27 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A5DF6C0.8050700@gmail.com> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> <20090715145444.GA23367@matrix.chaos.earth.li> <4A5DF6C0.8050700@gmail.com> Message-ID: Simon Marlow wrote: > Ian Lynagh wrote: >> Simon Marlow wrote: >>> But there's a solution: we could remove the "standard" modules from >>> base, and have them only provided by haskell-std (since base will just >>> be a re-exporting layer on top of base-internals, this will be easy to >>> do). Most packages will then have dependencies that look like >>> >>> build-depends: base-4.*, haskell-std-2010 >> >> We'll probably end up with situations where one dependency of a package >> needs haskell-std-2010, and another needs haskell-std-2011. I don't know >> which impls support that at the moment. > > That's the case with base-3/base-4 at the moment. Is it a problem? I think the issue raised is the diamond import problem, for instance that say the list type from haskell-std-2010 is spuriously different from the one in haskell-std-2011 . This would affect new programs based on the 2011 standard that want to use older libraries based on the 2010 standard; the point being that the latter are "intentionally" not updated to the newer standard. Of course, that's just the base-3 / base-4 issue which can be solved; it's just that it's not automatic but needs explicit work by implementors every time there is a new library standard. Regards, apfelmus -- http://apfelmus.nfshost.com From dave at zednenem.com Thu Jul 16 11:18:02 2009 From: dave at zednenem.com (David Menendez) Date: Thu Jul 16 10:59:55 2009 Subject: Haskell 2010: libraries In-Reply-To: <4A5EE6A8.4020900@gmail.com> References: <20090713232042.GA7309@matrix.chaos.earth.li> <16442B752A06A74AB4D9F9A5FF076E4B03B9F778@ELON17P32001A.csfb.cs-group.com> <20090714140427.GA18755@matrix.chaos.earth.li> <4A5DEA3B.7040200@gmail.com> <20090715145444.GA23367@matrix.chaos.earth.li> <4A5DF6C0.8050700@gmail.com> <49a77b7a0907151010t12a55102o529ab2d68c75855d@mail.gmail.com> <4A5EE6A8.4020900@gmail.com> Message-ID: <49a77b7a0907160818p3d6e04a7kc09832e315823ee5@mail.gmail.com> On Thu, Jul 16, 2009 at 4:36 AM, Simon Marlow wrote: > On 15/07/2009 18:10, David Menendez wrote: >> >> On Wed, Jul 15, 2009 at 11:33 AM, Simon Marlow ?wrote: >>> >>> On 15/07/2009 15:54, Ian Lynagh wrote: >>>> >>>> On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote: >>>>> >>>>> But there's a solution: we could remove the "standard" modules from >>>>> base, and have them only provided by haskell-std (since base will just >>>>> be a re-exporting layer on top of base-internals, this will be easy to >>>>> do). ?Most packages will then have dependencies that look like >>>>> >>>>> ? build-depends: base-4.*, haskell-std-2010 >>>> >>>> We'll probably end up with situations where one dependency of a package >>>> needs haskell-std-2010, and another needs haskell-std-2011. I don't know >>>> which impls support that at the moment. >>> >>> That's the case with base-3/base-4 at the moment. ?Is it a problem? >> >> Could I use two packages of arrow code which depend on base 3.0.2 and >> base 3.0.3, respectively, in the same project? > > No. ?(though I'm not sure the significance of "arrow code" here). ?Is there > a package that depends on base-3.0.2, and doesn't work with base-3.0.3? Any package that defines an Arrow instance can't work with both 3.0.2 and 3.0.3, because they provide incompatible class definitions. (That's where Category was introduced.) It broke at least one package at the time, although I think it's been fixed by now. In , you argued: > We simply *can't* provide the same API as base-3.0.2 without defining > a new Arrow class, and that would kill compatibility with base-4. On the > other hand, we did know this could happen (changes to datatypes also > cause the same problem), it's the tradeoff with trying to provide base-3 > as a compatibility layer over base-4. Which is probably the right call for obscure classes like Arrow, but not more common ones like Num or Monad. -- Dave Menendez -- Dave Menendez From igloo at earth.li Sun Jul 19 12:00:47 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 19 11:42:26 2009 Subject: Haskell 2010: libraries In-Reply-To: <1247570631.22466.8945.camel@localhost> References: <4A54A899.1030801@gmail.com> <1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> <1247570631.22466.8945.camel@localhost> Message-ID: <20090719160047.GA4280@matrix.chaos.earth.li> On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote: > On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote: > > On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: > > > > > > Specifically, I suggest: > > > > > > 4. Ix keep as Data.Ix > > > 5. Array keep as Data.Array > > Though also note that we have not changed any of the existing ones. Is > there a problem with specifying in the libraries section of the report > that the exports are a minimum and not a maximum? Here's another example I've just been looking at: Prelude> Array.listArray (1,4) [1..4] Array.! 5 *** Exception: Ix{Integer}.index: Index (5) out of range ((1,4)) Prelude> Array.listArray ((0,0), (3,3)) (repeat 0) Array.! (0,5) *** Exception: Error in array index Because the "Ix Integer" instance is for a type that we have a "Show" instance for, it can give a nice out-of-bounds error message. But the "Ix (a, b)" instance doesn't know if "(Show a, Show b)" instances exist, so it has to fall back to an unhelpful error message. So one could certainly argue that we should make Show a superclass of Ix, leaving us with a class that is incompatible with the older class definition. Thanks Ian From niklas.broberg at gmail.com Thu Jul 23 07:47:27 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jul 23 07:28:52 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: > Discussion period: 2 weeks Returning to this discussion, I'm surprised that so few people have actually commented yea or nay. Seems to me though that... * Some people are clearly in favor of a move in this direction, as seen both by their replies here and discussion over other channels. * Others are wary of deprecating anything of this magnitude for practical reasons. * No one has commented in true support of the classic existential syntax, only wanting to keep it for "legacy" reasons. I'm in no particular hurry to see this deprecation implemented, and I certainly understand the practical concerns, but I would still very much like us to make a statement that this is the direction we intend to go in the longer run. I'm not sure what the best procedure for doing so would be, but some sort of soft deprecation seems reasonable to me. Further thoughts? Cheers, /Niklas From niklas.broberg at gmail.com Thu Jul 23 07:36:33 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Jul 23 07:38:02 2009 Subject: Proposal: ExplicitForall In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: > Alright, let's set an actual discussion period of 2 weeks for > ExplicitForall. If there is no opposition by then, we can add > ExplicitForall to the registered extensions in cabal as a first step. Slightly more than two weeks later, there has been no voices against and at least a few in favor. The attached patch for Cabal adds ExplicitForall to the Extension datatype, with documentation, and adds it to knownExtensions. Cheers, /Niklas -------------- next part -------------- A non-text attachment was scrubbed... Name: ExplicitForall.dpatch Type: application/octet-stream Size: 41637 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20090723/9e6fd5ac/ExplicitForall-0001.obj From iavor.diatchki at gmail.com Thu Jul 23 12:25:15 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Jul 23 12:06:41 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <5ab17e790907230925g71e23bc0x166ebed50082c85c@mail.gmail.com> Hello, Sorry for responding so late---I just saw the thread. I don't think that we should deprecate the usual way to define existentials. While the GADT syntax is nice in some cases, there are also examples when it is quite verbose. For example, there is a lot of repetition in datatypes that have many constructors, especially if the datatype has parameters and a slightly longer name. Furthermore, I find the type variables in the declaration of the type quite confusing because they have no relation to the type variables in the constructors. Finally, there is quite a lot of literature about the semantics of existential types, while the semantics of GADTs seems quite complex, so it seems a bit risky to mix up the two. -Iavor On Thu, Jul 23, 2009 at 2:47 PM, Niklas Broberg wrote: >> Discussion period: 2 weeks > > Returning to this discussion, I'm surprised that so few people have > actually commented yea or nay. Seems to me though that... > * Some people are clearly in favor of a move in this direction, as > seen both by their replies here and discussion over other channels. > * Others are wary of deprecating anything of this magnitude for > practical reasons. > * No one has commented in true support of the classic existential > syntax, only wanting to keep it for "legacy" reasons. > > I'm in no particular hurry to see this deprecation implemented, and I > certainly understand the practical concerns, but I would still very > much like us to make a statement that this is the direction we intend > to go in the longer run. I'm not sure what the best procedure for > doing so would be, but some sort of soft deprecation seems reasonable > to me. > > Further thoughts? > > Cheers, > > /Niklas > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From ganesh.sittampalam at credit-suisse.com Thu Jul 23 12:36:00 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Jul 23 12:18:02 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <5ab17e790907230925g71e23bc0x166ebed50082c85c@mail.gmail.com> References: <5ab17e790907230925g71e23bc0x166ebed50082c85c@mail.gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F808@ELON17P32001A.csfb.cs-group.com> One can use the following style of GADT definition, which avoids the type variables in the declaration: {-# LANGUAGE GADTs, KindSignatures #-} module GADT where data Foo :: * -> * where Foo :: Int -> Foo Int Iavor Diatchki wrote: > Hello, > > Sorry for responding so late---I just saw the thread. I don't think > that we should deprecate the usual way to define existentials. While > the GADT syntax is nice in some cases, there are also examples when > it is quite verbose. For example, there is a lot of repetition in > datatypes that have many constructors, especially if the datatype has > parameters and a slightly longer name. Furthermore, I find the type > variables in the declaration of the type quite confusing because they > have no relation to the type variables in the constructors. Finally, > there is quite a lot of literature about the semantics of existential > types, while the semantics of GADTs seems quite complex, so it seems > a bit risky to mix up the two. > > -Iavor > > > > > > On Thu, Jul 23, 2009 at 2:47 PM, Niklas > Broberg wrote: >>> Discussion period: 2 weeks >> >> Returning to this discussion, I'm surprised that so few people have >> actually commented yea or nay. Seems to me though that... >> * Some people are clearly in favor of a move in this direction, as >> seen both by their replies here and discussion over other channels. >> * Others are wary of deprecating anything of this magnitude for >> practical reasons. >> * No one has commented in true support of the classic existential >> syntax, only wanting to keep it for "legacy" reasons. >> >> I'm in no particular hurry to see this deprecation implemented, and I >> certainly understand the practical concerns, but I would still very >> much like us to make a statement that this is the direction we intend >> to go in the longer run. I'm not sure what the best procedure for >> doing so would be, but some sort of soft deprecation seems >> reasonable to me. >> >> Further thoughts? >> >> Cheers, >> >> /Niklas >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From iavor.diatchki at gmail.com Thu Jul 23 18:28:00 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Jul 23 18:09:26 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9F808@ELON17P32001A.csfb.cs-group.com> References: <5ab17e790907230925g71e23bc0x166ebed50082c85c@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9F808@ELON17P32001A.csfb.cs-group.com> Message-ID: <5ab17e790907231528r7c2b0f8fkaac94565c89087ba@mail.gmail.com> Hi, True, but then you have to declare the kind manually. -Iavor On Thu, Jul 23, 2009 at 7:36 PM, Sittampalam, Ganesh wrote: > One can use the following style of GADT definition, which avoids the > type variables in the declaration: > > {-# LANGUAGE GADTs, KindSignatures #-} > module GADT where > > data Foo :: * -> * where > ?Foo :: Int -> Foo Int > > Iavor Diatchki wrote: >> Hello, >> >> Sorry for responding so late---I just saw the thread. ?I don't think >> that we should deprecate the usual way to define existentials. ?While >> the GADT syntax is nice in some cases, there are also examples when >> it is quite verbose. For example, there is a lot of repetition in >> datatypes that have many constructors, especially if the datatype has >> parameters and a slightly longer name. ?Furthermore, I find the type >> variables in the declaration of the type quite confusing because they >> have no relation to the type variables in the constructors. ?Finally, >> there is quite a lot of literature about the semantics of existential >> types, while the semantics of GADTs seems quite complex, so it seems >> a bit risky to mix up the two. >> >> -Iavor >> >> >> >> >> >> On Thu, Jul 23, 2009 at 2:47 PM, Niklas >> Broberg wrote: >>>> Discussion period: 2 weeks >>> >>> Returning to this discussion, I'm surprised that so few people have >>> actually commented yea or nay. Seems to me though that... >>> * Some people are clearly in favor of a move in this direction, as >>> seen both by their replies here and discussion over other channels. >>> * Others are wary of deprecating anything of this magnitude for >>> practical reasons. >>> * No one has commented in true support of the classic existential >>> syntax, only wanting to keep it for "legacy" reasons. >>> >>> I'm in no particular hurry to see this deprecation implemented, and I >>> certainly understand the practical concerns, but I would still very >>> much like us to make a statement that this is the direction we intend >>> to go in the longer run. I'm not sure what the best procedure for >>> doing so would be, but some sort of soft deprecation seems >>> reasonable to me. >>> >>> Further thoughts? >>> >>> Cheers, >>> >>> /Niklas >>> _______________________________________________ >>> Haskell-prime mailing list >>> Haskell-prime@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-prime >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > =============================================================================== > ?Please access the attached hyperlink for an important electronic communications disclaimer: > ?http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ?=============================================================================== > > From naesten at gmail.com Fri Jul 24 11:26:58 2009 From: naesten at gmail.com (Samuel Bronson) Date: Fri Jul 24 11:08:21 2009 Subject: Proposal: ExplicitForall In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Thu, Jul 23, 2009 at 7:36 AM, Niklas Broberg wrote: >> Alright, let's set an actual discussion period of 2 weeks for >> ExplicitForall. If there is no opposition by then, we can add >> ExplicitForall to the registered extensions in cabal as a first step. > > Slightly more than two weeks later, there has been no voices against > and at least a few in favor. Huh. I guess I forgot I could reply? In favour I am. (Even if I do live in the US. ) From igloo at earth.li Fri Jul 24 19:14:37 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 18:55:58 2009 Subject: patch applied (haskell-prime-report): Fix indentation in an example Message-ID: <20090724231437.GA30311@haskell.galois.com> Mon Jul 20 17:31:43 PDT 2009 Ian Lynagh * Fix indentation in an example Using tabs doesn't give the correct indentation in the HTML output M ./report/modules.verb -2 +2 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721003143-3fd76-7bde64bacdb9c7a544e888c80f171313b0829658.gz From igloo at earth.li Fri Jul 24 19:14:39 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 18:56:01 2009 Subject: patch applied (haskell-prime-report): Remove a command from "make clean" that breaks in a fresh repo Message-ID: <20090724231439.GA30334@haskell.galois.com> Tue Jul 21 03:38:44 PDT 2009 Ian Lynagh * Remove a command from "make clean" that breaks in a fresh repo M ./report/Makefile -1 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721103844-3fd76-0511779ead8500ad74a68e4f83f196b0c664013b.gz From igloo at earth.li Fri Jul 24 19:14:41 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 18:56:03 2009 Subject: patch applied (haskell-prime-report): Everyone has perl, clean Prelude*.tex too Message-ID: <20090724231440.GA30353@haskell.galois.com> Tue Jul 21 03:39:57 PDT 2009 Ian Lynagh * Everyone has perl, clean Prelude*.tex too M ./report/Makefile -3 +1 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721103957-3fd76-ccdb28273cabb4495bdf0d4c65495cae6156b03b.gz From igloo at earth.li Fri Jul 24 19:14:43 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 18:56:06 2009 Subject: patch applied (haskell-prime-report): Remove duplicate haskell.dvi dependencies Message-ID: <20090724231442.GA30373@haskell.galois.com> Tue Jul 21 03:47:49 PDT 2009 Ian Lynagh * Remove duplicate haskell.dvi dependencies M ./report/Makefile -2 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721104749-3fd76-56eaacd95457f668692292862b7b07915af7635f.gz From igloo at earth.li Fri Jul 24 19:14:45 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 18:56:06 2009 Subject: patch applied (haskell-prime-report): Refactor away old-fashioned make syntax Message-ID: <20090724231444.GA30391@haskell.galois.com> Tue Jul 21 04:03:50 PDT 2009 Ian Lynagh * Refactor away old-fashioned make syntax M ./report/Makefile -7 +5 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721110350-3fd76-a6176df5dc492d5b34cb2dfed4a31f84870272e2.gz From igloo at earth.li Fri Jul 24 19:14:46 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 18:56:10 2009 Subject: patch applied (haskell-prime-report): Tweak rule so make knows how to create haskell.idx Message-ID: <20090724231446.GA30410@haskell.galois.com> Tue Jul 21 04:06:30 PDT 2009 Ian Lynagh * Tweak rule so make knows how to create haskell.idx M ./report/Makefile -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721110630-3fd76-830582c20b8ab7ea571049b4de25b042db91f04f.gz From igloo at earth.li Fri Jul 24 21:02:43 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 24 20:44:05 2009 Subject: NoNPlusKPatterns Message-ID: <20090725010243.GA6989@matrix.chaos.earth.li> Hi all, I've made a ticket and proposal page for removing n+k patterns: http://hackage.haskell.org/trac/haskell-prime/ticket/130 http://hackage.haskell.org/trac/haskell-prime/wiki/NoNPlusKPatterns Should I have also added it to some index page somewhere? Please let me know if there's anything else I should do. By the way, I find all the old tickets and wiki pages make it very hard to understand what is current on the haskell-prime trac. Thanks Ian From igloo at earth.li Sat Jul 25 11:28:47 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jul 25 11:10:09 2009 Subject: NoMonomorphismRestriction Message-ID: <20090725152847.GA31765@matrix.chaos.earth.li> Hi all, I've made a ticket and proposal page for removing the monomorphism restriction: http://hackage.haskell.org/trac/haskell-prime/ticket/131 http://hackage.haskell.org/trac/haskell-prime/wiki/NoMonomorphismRestriction Thanks Ian From igloo at earth.li Sat Jul 25 21:34:59 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jul 25 21:16:17 2009 Subject: StricterLabelledFieldSyntax Message-ID: <20090726013459.GA18475@matrix.chaos.earth.li> Hi all, I've made a ticket and proposal page for making the labelled field syntax stricter, e.g. making this illegal: data A = A {x :: Int} y :: Maybe A y = Just A {x = 5} and requiring this instead: data A = A {x :: Int} y :: Maybe A y = Just (A {x = 5}) http://hackage.haskell.org/trac/haskell-prime/ticket/132 http://hackage.haskell.org/trac/haskell-prime/wiki/StricterLabelledFieldSyntax Thanks Ian From ml at isaac.cedarswampstudios.org Sat Jul 25 21:45:18 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sat Jul 25 21:26:44 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <20090726013459.GA18475@matrix.chaos.earth.li> References: <20090726013459.GA18475@matrix.chaos.earth.li> Message-ID: <4A6BB52E.9020409@isaac.cedarswampstudios.org> Ian Lynagh wrote: > Hi all, > > I've made a ticket and proposal page for making the labelled field > syntax stricter, e.g. making this illegal: > > data A = A {x :: Int} > > y :: Maybe A > y = Just A {x = 5} > > and requiring this instead: > > data A = A {x :: Int} > > y :: Maybe A > y = Just (A {x = 5}) and, as currently, "(f some expression) {x=5}" still requires those parentheses also? Although depending on the surroundings, after this proposal, it might need to become "((f some expression) {x=5})" -Isaac From leather at cs.uu.nl Sun Jul 26 03:40:40 2009 From: leather at cs.uu.nl (Sean Leather) Date: Sun Jul 26 03:22:16 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <20090726013459.GA18475@matrix.chaos.earth.li> References: <20090726013459.GA18475@matrix.chaos.earth.li> Message-ID: <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> > I've made a ticket and proposal page for making the labelled field > syntax stricter > I'm definitely in favor of this change. I only have an issue with calling it "stricter." Maybe it's just me, but strictness doesn't provoke the expected image in this case. More like lower precedence. Would it be useful to add an example with the appropriate parentheses? Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090726/6673b855/attachment.html From jon.fairbairn at cl.cam.ac.uk Sun Jul 26 04:21:06 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sun Jul 26 04:02:39 2009 Subject: StricterLabelledFieldSyntax References: <20090726013459.GA18475@matrix.chaos.earth.li> Message-ID: Ian Lynagh writes: > http://hackage.haskell.org/trac/haskell-prime/wiki/StricterLabelledFieldSyntax I approve of the principle -- the binding level is confusing, but I would far rather make a bigger change, so that rather than being confusable with the binding level of function application, it /has/ the binding level of function application. ie, instead of a{x=42} one would have to write {x=42}a, and "f {x=42} a" would parse as "(f {x=42}) a" -- and be an error because labelled field assignments aren't currently proper functions (but under this change they could be thought of as a restricted kind of function). This would allow a future change that made them first class citizen; "{x=42}" would have type something like (Num a => forall D. D{x::a} -> D{x::a}) (if you can work out the intent of a syntax made up on the spur of the moment). Working out the ramifications of a type system that allowed that is a job for later, but it would be worthwhile to make it possible. Would it be proper to create a counterproposal for this syntax? ReversedLabelledFieldSyntax? -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From igloo at earth.li Sun Jul 26 07:38:04 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 26 07:19:21 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <4A6BB52E.9020409@isaac.cedarswampstudios.org> References: <20090726013459.GA18475@matrix.chaos.earth.li> <4A6BB52E.9020409@isaac.cedarswampstudios.org> Message-ID: <20090726113804.GA22452@matrix.chaos.earth.li> On Sat, Jul 25, 2009 at 09:45:18PM -0400, Isaac Dupree wrote: > Ian Lynagh wrote: >> Hi all, >> >> I've made a ticket and proposal page for making the labelled field >> syntax stricter, e.g. making this illegal: >> >> data A = A {x :: Int} >> >> y :: Maybe A >> y = Just A {x = 5} >> >> and requiring this instead: >> >> data A = A {x :: Int} >> >> y :: Maybe A >> y = Just (A {x = 5}) > > and, as currently, "(f some expression) {x=5}" still requires those > parentheses also? Although depending on the surroundings, after this > proposal, it might need to become "((f some expression) {x=5})" Yes, exactly. I've added this to the wiki page: No additional programs are accepted by this change, and no programs have their behaviour changed. This change only rejects some programs that were previously accepted. Thanks Ian From igloo at earth.li Sun Jul 26 07:41:29 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 26 07:22:46 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> Message-ID: <20090726114129.GB22452@matrix.chaos.earth.li> On Sun, Jul 26, 2009 at 09:40:40AM +0200, Sean Leather wrote: > > I've made a ticket and proposal page for making the labelled field > > syntax stricter > > > > I'm definitely in favor of this change. I only have an issue with calling it > "stricter." Maybe it's just me, but strictness doesn't provoke the expected > image in this case. More like lower precedence. I'm happy with it being given a different name. > Would it be useful to add an example with the appropriate parentheses? I'm not sure I understand what sort of an example you want. Isn't Just (A {x = 5}) one? Thanks Ian From igloo at earth.li Sun Jul 26 07:53:48 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 26 07:35:04 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: References: <20090726013459.GA18475@matrix.chaos.earth.li> Message-ID: <20090726115348.GC22452@matrix.chaos.earth.li> On Sun, Jul 26, 2009 at 09:21:06AM +0100, Jon Fairbairn wrote: > Ian Lynagh writes: > > http://hackage.haskell.org/trac/haskell-prime/wiki/StricterLabelledFieldSyntax > > I approve of the principle -- the binding level is confusing, but I > would far rather make a bigger change, so that rather than being > confusable with the binding level of function application, it /has/ the > binding level of function application. ie, instead of a{x=42} one would > have to write {x=42}a > > This would allow a future change [...] > > Would it be proper to create a counterproposal for this syntax? > ReversedLabelledFieldSyntax? I would claim that, of the existing Haskell code, StricterLabelledFieldSyntax only rejects unclear ("bad") code, and requiring it be changed (to be made clearer) is a good thing. Your proposal would reject /all/ labelled field code, "good" and "bad" alike. That's a much harder sell, especially without the "future change" being fleshed out or agreed upon. All just my opinion, of course! The only way to find out for sure is to make the proposal and see what happens. Thanks Ian From leather at cs.uu.nl Sun Jul 26 09:46:41 2009 From: leather at cs.uu.nl (Sean Leather) Date: Sun Jul 26 09:28:18 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <20090726114129.GB22452@matrix.chaos.earth.li> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> Message-ID: <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> On Sun, Jul 26, 2009 at 13:41, Ian Lynagh wrote: > On Sun, Jul 26, 2009 at 09:40:40AM +0200, Sean Leather wrote: > > > I've made a ticket and proposal page for making the labelled field > > > syntax stricter > > > > > > > I'm definitely in favor of this change. I only have an issue with calling > it > > "stricter." Maybe it's just me, but strictness doesn't provoke the > expected > > image in this case. More like lower precedence. > > I'm happy with it being given a different name. > I don't know... I can't say I'm good at coming up with names. To me, the syntax is not actually stricter, just that the precedence for labeled field construction, update, & pattern is lower. What is the effective new precedence with this change? Previously, it was 11 (or simply "higher than 10"). Is it now equivalent to function application (10)? > Would it be useful to add an example with the appropriate parentheses? > > I'm not sure I understand what sort of an example you want. Isn't > Just (A {x = 5}) > one? > I think an example should be added to the report itself with a mention of the change from the previous edition. (Any reasonable example will do.) Looking through the proposal's "Report Delta," I didn't see such a change, though perhaps it escaped me. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090726/4d5a4ae6/attachment.html From igloo at earth.li Sun Jul 26 10:07:40 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 26 09:48:57 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> Message-ID: <20090726140740.GA25896@matrix.chaos.earth.li> On Sun, Jul 26, 2009 at 03:46:41PM +0200, Sean Leather wrote: > On Sun, Jul 26, 2009 at 13:41, Ian Lynagh wrote: > > > Would it be useful to add an example with the appropriate parentheses? > > > > I'm not sure I understand what sort of an example you want. Isn't > > Just (A {x = 5}) > > one? > > > > I think an example should be added to the report itself with a mention of > the change from the previous edition. (Any reasonable example will do.) > Looking through the proposal's "Report Delta," I didn't see such a change, > though perhaps it escaped me. Ah, I see what you mean. In my opinion the report should just define the language that it defines. One should be able to take the report and implement the language, without being distracted by all the differences between it and other language definitions. I'm assuming that the polished addenda will be kept and linked from the language reports page, for people who want to see what's changed, or who want to add support for the changes to an older implementation. I think that even an example of where parentheses are needed would be noise in the report. I don't think the report generally gives examples for this sort of thing, e.g. I don't think there's an example to demonstrate that this is invalid without parentheses: id if True then 'a' else 'b' If there is a consensus that examples like this should be added then I will add them, though. Thanks Ian From ndmitchell at gmail.com Sun Jul 26 10:24:03 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Jul 26 10:05:20 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <20090726115348.GC22452@matrix.chaos.earth.li> References: <20090726013459.GA18475@matrix.chaos.earth.li> <20090726115348.GC22452@matrix.chaos.earth.li> Message-ID: <404396ef0907260724l68076d14qb7d01d9a1a78db01@mail.gmail.com> Hi >> Would it be proper to create a counterproposal for this syntax? >> ReversedLabelledFieldSyntax? > > I would claim that, of the existing Haskell code, > StricterLabelledFieldSyntax only rejects unclear ("bad") code, and > requiring it be changed (to be made clearer) is a good thing. I haven't seen anyone else claim to use the current more liberal syntax for fields, but I know that I do rather extensively. I would consider: Just A {a = 1} To be confusing, but if you simply omit the space: Just A{a = 1} I now find that perfectly clear and unambiguous. I realise this isn't necessarily a discussion of the merits of the feature, but I don't consider this removal as clear cut as some people are suggesting. Thanks Neil From igloo at earth.li Sun Jul 26 10:44:11 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 26 10:25:26 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <404396ef0907260724l68076d14qb7d01d9a1a78db01@mail.gmail.com> References: <20090726013459.GA18475@matrix.chaos.earth.li> <20090726115348.GC22452@matrix.chaos.earth.li> <404396ef0907260724l68076d14qb7d01d9a1a78db01@mail.gmail.com> Message-ID: <20090726144411.GA26225@matrix.chaos.earth.li> On Sun, Jul 26, 2009 at 03:24:03PM +0100, Neil Mitchell wrote: > > I haven't seen anyone else claim to use the current more liberal > syntax for fields, but I know that I do rather extensively. I would > consider: > > Just A {a = 1} > > To be confusing, but if you simply omit the space: > > Just A{a = 1} > > I now find that perfectly clear and unambiguous. I did consider allowing that, perhaps by making "Foo{" a single token, but I couldn't see a clean way to do it. Personally, I prefer rejecting it anyway. Thanks Ian From ndmitchell at gmail.com Sun Jul 26 12:09:19 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Jul 26 11:50:35 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <20090726144411.GA26225@matrix.chaos.earth.li> References: <20090726013459.GA18475@matrix.chaos.earth.li> <20090726115348.GC22452@matrix.chaos.earth.li> <404396ef0907260724l68076d14qb7d01d9a1a78db01@mail.gmail.com> <20090726144411.GA26225@matrix.chaos.earth.li> Message-ID: <404396ef0907260909h629794afi5d23e32defc60b26@mail.gmail.com> >> I haven't seen anyone else claim to use the current more liberal >> syntax for fields, but I know that I do rather extensively. I would >> consider: >> >> Just A {a = 1} >> >> To be confusing, but if you simply omit the space: >> >> Just A{a = 1} >> >> I now find that perfectly clear and unambiguous. > > I did consider allowing that, perhaps by making "Foo{" a single token, > but I couldn't see a clean way to do it. Just to be explicit, I think Just A{...} is clear for me, but really wouldn't want the parser to depend on the presence or absence of spaces - that's just not very Haskell like. Thanks, Neil From ml at isaac.cedarswampstudios.org Sun Jul 26 13:45:54 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Jul 26 13:27:16 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: References: <20090726013459.GA18475@matrix.chaos.earth.li> Message-ID: <4A6C9652.8050508@isaac.cedarswampstudios.org> Jon Fairbairn wrote: > Ian Lynagh writes: >> http://hackage.haskell.org/trac/haskell-prime/wiki/StricterLabelledFieldSyntax > > I approve of the principle -- the binding level is confusing, but I > would far rather make a bigger change, so that rather than being > confusable with the binding level of function application, it /has/ the > binding level of function application. ie, instead of a{x=42} one would > have to write {x=42}a, we already know which record type it is, because record fields don't have disambiguation. If it's (data D = D { x, y :: Int }) then (x :: D -> Int) and we would have (({x=42}) :: D -> D). Or (data E n = E1 { ex, ey :: n } | E2 { ey :: n } | E3 {ex :: n}), (ey :: E n -> n), (({ex=42}) :: Num n => E n -> E n), but probably not ever allowing to change (E n1 -> E n2) even if it changes both ex and ey. I think it wouldn't be a terrible syntax, ({...}), kind of like infix operators can be made into functions like (+). If you wanted to make a proposal for such an extension. -Isaac From ml at isaac.cedarswampstudios.org Sun Jul 26 13:52:26 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Jul 26 13:33:49 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> Message-ID: <4A6C97DA.4080506@isaac.cedarswampstudios.org> Sean Leather wrote: > To me, the syntax is not actually stricter, just that the precedence for > labeled field construction, update, & pattern is lower. What is the > effective new precedence with this change? Previously, it was 11 (or simply > "higher than 10"). Is it now equivalent to function application (10)? maybe it's equivalent "infix 10" (not infixr/infixl) so that it doesn't associate with function application (or itself) at all, either left- or right- ly. I didn't understand by reading the patch to the report... Ian Lynagh wrote: > I think that even an example of where parentheses are needed would be > noise in the report. I don't think the report generally gives examples > for this sort of thing, e.g. I don't think there's an example to > demonstrate that this is invalid without parentheses: > id if True then 'a' else 'b' Well that's also something that in my opinion there *should* be an example for, because IMHO there's no obvious reason why it's banned (whereas most of the Report's syntax repeats things that should be obvious and necessary to anyone who knows Haskell). -Isaac From iavor.diatchki at gmail.com Sun Jul 26 14:57:56 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Jul 26 14:39:13 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <4A6C97DA.4080506@isaac.cedarswampstudios.org> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> <4A6C97DA.4080506@isaac.cedarswampstudios.org> Message-ID: <5ab17e790907261157x5861de6as9840c09a7fce2915@mail.gmail.com> Hello, I am strongly against this change. The record notation works just fine and has been doing so for a long time. The notation is really not that confusing and, given how records work in Haskell, makes perfect sense (and the notation has nothing to do with the precedence of application because there are no applications involved). In short, I am not sure what problem is addressed by this change, while a very real problem (backwards incompatibility) would be introduced. -Iavor On Sun, Jul 26, 2009 at 8:52 PM, Isaac Dupree wrote: > Sean Leather wrote: >> >> To me, the syntax is not actually stricter, just that the precedence for >> labeled field construction, update, & pattern is lower. What is the >> effective new precedence with this change? Previously, it was 11 (or >> simply >> "higher than 10"). Is it now equivalent to function application (10)? > > maybe it's equivalent "infix 10" (not infixr/infixl) so that it doesn't > associate with function application (or itself) at all, either left- or > right- ly. ?I didn't understand by reading the patch to the report... > > Ian Lynagh wrote: >> >> I think that even an example of where parentheses are needed would be >> noise in the report. I don't think the report generally gives examples >> for this sort of thing, e.g. I don't think there's an example to >> demonstrate that this is invalid without parentheses: >> ? ?id if True then 'a' else 'b' > > Well that's also something that in my opinion there *should* be an example > for, because IMHO there's no obvious reason why it's banned (whereas most of > the Report's syntax repeats things that should be obvious and necessary to > anyone who knows Haskell). > > -Isaac > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From ml at isaac.cedarswampstudios.org Sun Jul 26 15:01:37 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Jul 26 14:43:00 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <5ab17e790907261157x5861de6as9840c09a7fce2915@mail.gmail.com> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> <4A6C97DA.4080506@isaac.cedarswampstudios.org> <5ab17e790907261157x5861de6as9840c09a7fce2915@mail.gmail.com> Message-ID: <4A6CA811.7070509@isaac.cedarswampstudios.org> Iavor Diatchki wrote: > Hello, > I am strongly against this change. The record notation works just > fine and has been doing so for a long time. The notation is really > not that confusing and, given how records work in Haskell, makes > perfect sense (and the notation has nothing to do with the precedence > of application because there are no applications involved). In short, > I am not sure what problem is addressed by this change, while a very > real problem (backwards incompatibility) would be introduced. > -Iavor a different approach to things that look funny, has been to implement a warning message in GHC. Would that be a good alternative? -Isaac From iavor.diatchki at gmail.com Sun Jul 26 15:16:28 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Jul 26 14:57:44 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <4A6CA811.7070509@isaac.cedarswampstudios.org> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> <4A6C97DA.4080506@isaac.cedarswampstudios.org> <5ab17e790907261157x5861de6as9840c09a7fce2915@mail.gmail.com> <4A6CA811.7070509@isaac.cedarswampstudios.org> Message-ID: <5ab17e790907261216p20d0385dn461a5d0b6f934a1b@mail.gmail.com> Hello, On Sun, Jul 26, 2009 at 10:01 PM, Isaac Dupree wrote: > Iavor Diatchki wrote: >> >> Hello, >> I am strongly against this change. ?The record notation works just >> fine and has been doing so for a long time. ?The notation is really >> not that confusing and, given how records work in Haskell, makes >> perfect sense (and the notation has nothing to do with the precedence >> of application because there are no applications involved). ?In short, >> I am not sure what problem is addressed by this change, while a very >> real problem (backwards incompatibility) would be introduced. >> -Iavor > > a different approach to things that look funny, has been to implement a > warning message in GHC. ?Would that be a good alternative? Not for me. I use the notation as is, and so my code would start generating warnings without any valid reason, I think. What would such a warning warn against, anyway? -Iavor From igloo at earth.li Sun Jul 26 16:53:12 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 26 16:34:28 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <5ab17e790907261216p20d0385dn461a5d0b6f934a1b@mail.gmail.com> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> <4A6C97DA.4080506@isaac.cedarswampstudios.org> <5ab17e790907261157x5861de6as9840c09a7fce2915@mail.gmail.com> <4A6CA811.7070509@isaac.cedarswampstudios.org> <5ab17e790907261216p20d0385dn461a5d0b6f934a1b@mail.gmail.com> Message-ID: <20090726205312.GA26415@matrix.chaos.earth.li> On Sun, Jul 26, 2009 at 10:16:28PM +0300, Iavor Diatchki wrote: > > On Sun, Jul 26, 2009 at 10:01 PM, Isaac > Dupree wrote: > > Iavor Diatchki wrote: > >> > >> I am strongly against this change. ?The record notation works just > >> fine and has been doing so for a long time. ?The notation is really > >> not that confusing and, given how records work in Haskell, makes > >> perfect sense (and the notation has nothing to do with the precedence > >> of application because there are no applications involved). ?In short, > >> I am not sure what problem is addressed by this change, while a very > >> real problem (backwards incompatibility) would be introduced. > >> -Iavor > > > > a different approach to things that look funny, has been to implement a > > warning message in GHC. ?Would that be a good alternative? > > Not for me. I use the notation as is, and so my code would start > generating warnings without any valid reason, I think. What would > such a warning warn against, anyway? For context, I looked at the alsa package. All of the (roughly 10) would-be-rejected cases looked like one of the two examples below. I don't really have anything new to say: Some people think these are clear, others find them confusing. Hopefully we'll find a consensus and make a decision. throwAlsa :: String -> Errno -> IO a throwAlsa fun err = do d <- strerror err throwDyn AlsaException { exception_location = fun , exception_description = d , exception_code = err } peek p = do cl <- #{peek snd_seq_addr_t, client} p po <- #{peek snd_seq_addr_t, port} p return Addr { addr_client = cl, addr_port = po } Thanks Ian From ganesh.sittampalam at credit-suisse.com Mon Jul 27 03:27:08 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Jul 27 03:08:38 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <20090726013459.GA18475@matrix.chaos.earth.li> References: <20090726013459.GA18475@matrix.chaos.earth.li> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9F81F@ELON17P32001A.csfb.cs-group.com> Ian Lynagh wrote: > Hi all, > > I've made a ticket and proposal page for making the labelled field > syntax stricter, e.g. making this illegal: > > data A = A {x :: Int} > > y :: Maybe A > y = Just A {x = 5} +1: The precedence here is an ugly wart. It's particularly annoying when teaching Haskell syntax to newbies; the simple rule "juxtaposition binds tighter than everything else" doesn't quite work. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From jon.fairbairn at cl.cam.ac.uk Mon Jul 27 03:38:00 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Mon Jul 27 03:19:26 2009 Subject: StricterLabelledFieldSyntax References: <20090726013459.GA18475@matrix.chaos.earth.li> <20090726115348.GC22452@matrix.chaos.earth.li> <404396ef0907260724l68076d14qb7d01d9a1a78db01@mail.gmail.com> Message-ID: Neil Mitchell writes: > Hi > >>> Would it be proper to create a counterproposal for this syntax? >>> ReversedLabelledFieldSyntax? >> >> I would claim that, of the existing Haskell code, >> StricterLabelledFieldSyntax only rejects unclear ("bad") code, and >> requiring it be changed (to be made clearer) is a good thing. > > I haven't seen anyone else claim to use the current more liberal > syntax for fields, but I know that I do rather extensively. I would > consider: > > Just A {a = 1} > > To be confusing, but if you simply omit the space: > > Just A{a = 1} > > I now find that perfectly clear and unambiguous. I realise this isn't > necessarily a discussion of the merits of the feature, but I don't > consider this removal as clear cut as some people are suggesting. for what it's worth, I do take advantage of the current syntax for functions with default parameters: f defaults{some_option = non_default_value} and like you, I don't put a space. I've long thought that compilers should issue warnings for layout that conflicts with precedence -- everyone knows that 2+2 * 8 means 2 + (2*8), but I'd guess it takes a /tiny/ bit longer to read correctly, and for less familiar operators the misleading layout is more likely a source of misreadings. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From jon.fairbairn at cl.cam.ac.uk Mon Jul 27 04:38:25 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Mon Jul 27 04:19:56 2009 Subject: Proposal: FirstClassFieldUpdates References: <20090726013459.GA18475@matrix.chaos.earth.li> <4A6C9652.8050508@isaac.cedarswampstudios.org> Message-ID: According to the wiki, since I'm not a committee member, I should post proposals here. See below my reply to Isaac's message. Isaac Dupree writes: > Jon Fairbairn wrote: >> Ian Lynagh writes: >> [field update] /has/ the >> binding level of function application. ie, instead of a{x=42} one would >> have to write {x=42}a, > > we already know which record type it is, because record > fields don't have disambiguation. OK, I'd forgotten that. Makes things straightforward. > I think it wouldn't be a terrible syntax, ({...}), kind of > like infix operators can be made into functions like (+). > If you wanted to make a proposal for such an extension. I was wondering how to make it compatible. That looks like a reasonable compromise, so... Proposal: FirstClassFieldUpdates Summary: Add some syntax that makes field updates into functions. Description: On several occasions I've wanted to pass arguments that modified records and been disappointed that I have to use a lambda expression. Parenthesis around updates would make them into functions, ie ({a=1,b=2,...}) would mean the same as (\d -> d{a=1,b=2,...}), but be more concise. This chimes reasonably well with (+) turning an infix operator into a function. ({}) would be the (polymorphic) identity function. This would permit concise calls to functions with default/optional parameters: > data Defaults_for_f = Defaults_for_f {option1::A, option2::B, ...} > defaults_for_f = Defaults_for_f {option1=default1, ...} > f options other arguments = let params = options defaults_for_f in ... allows one to write f ({}) ... (or f id ... if no-one likes ({})) to call f with the default arguments, or f ({option1 = something_else}) ... to go away from the defaults. Discussion: I would rather make {field1=a, field2=b, ...} a function. ie instead of a{thing=1} one would write {thing=1} a. In other words {field1=a, field2=b, ...} would be a notation for the function that is currently written \d -> d{field1=a, field2=b, ...}. Again we would want empty record updates {} to be the identity function. We would then remove the thing{fu=bar} syntax (where thing is a variable). This would simultaneously simplify the syntax, remove the misleading "f x {a=b}" bemoaned in StricterLabelledFieldSyntax and make certain use cases (such as default parameters) more concise. Unfortunately old programmes wouldn't compile any more?, but I think that Haskell' is the place for backwards incompatible changes that simplify things. The difficulty would be what to do about Constructor{fu=bar}, given that Constructor is currently defined to operate both as a function and be used in patterns (there's something fishy about this when the record has named fields). As yet I haven't thought of a good way of doing that, hence the current proposal that adds syntax rather than takes it away. [1] All the errors would be compile time errors. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From marlowsd at gmail.com Mon Jul 27 06:12:37 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jul 27 05:53:55 2009 Subject: [Haskell'-private] NoMonomorphismRestriction In-Reply-To: <20090725152847.GA31765@matrix.chaos.earth.li> References: <20090725152847.GA31765@matrix.chaos.earth.li> Message-ID: <4A6D7D95.6000004@gmail.com> On 25/07/2009 16:28, Ian Lynagh wrote: > I've made a ticket and proposal page for removing the monomorphism > restriction: > http://hackage.haskell.org/trac/haskell-prime/ticket/131 > http://hackage.haskell.org/trac/haskell-prime/wiki/NoMonomorphismRestriction I think if we do this we really have to do http://hackage.haskell.org/trac/haskell-prime/wiki/SpecifyPatternBindingSemantics Which is not strictly speaking a change, but is a necessary clarification if the MR is removed. I believe the conclusion we came to in March/April 2008 was to do this. Cheers, Simon From marlowsd at gmail.com Mon Jul 27 06:15:20 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jul 27 05:56:37 2009 Subject: [Haskell'-private] NoNPlusKPatterns In-Reply-To: <20090725010243.GA6989@matrix.chaos.earth.li> References: <20090725010243.GA6989@matrix.chaos.earth.li> Message-ID: <4A6D7E38.2070602@gmail.com> On 25/07/2009 02:02, Ian Lynagh wrote: > > Hi all, > > I've made a ticket and proposal page for removing n+k patterns: > http://hackage.haskell.org/trac/haskell-prime/ticket/130 > http://hackage.haskell.org/trac/haskell-prime/wiki/NoNPlusKPatterns > > Should I have also added it to some index page somewhere? > > Please let me know if there's anything else I should do. No, that's all you need to do. This link shows the proposals grouped by status, which shows the ones that are actively being worked on: http://hackage.haskell.org/trac/haskell-prime/query?status=new&status=assigned&status=reopened&group=state (that link is available from the home page as "All Proposal Tickets") > By the way, I find all the old tickets and wiki pages make it very hard > to understand what is current on the haskell-prime trac. We could easily make the query ignore the old tickets. Would that help? Cheers, Simon From niklas.broberg at gmail.com Mon Jul 27 08:16:08 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Jul 27 07:57:21 2009 Subject: ExplicitForall Message-ID: Hi all, Per request I've made a ticket and proposal page for adding ExplicitForall to Haskell'2010: http://hackage.haskell.org/trac/haskell-prime/ticket/133 http://hackage.haskell.org/trac/haskell-prime/wiki/ExplicitForall Cheers, /Niklas From ml at isaac.cedarswampstudios.org Mon Jul 27 13:05:56 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Mon Jul 27 12:47:19 2009 Subject: Proposal: FirstClassFieldUpdates In-Reply-To: References: <20090726013459.GA18475@matrix.chaos.earth.li> <4A6C9652.8050508@isaac.cedarswampstudios.org> Message-ID: <4A6DDE74.2060007@isaac.cedarswampstudios.org> Jon Fairbairn wrote: > Parenthesis around updates would make them into functions, ie > ({a=1,b=2,...}) would mean the same as (\d -> d{a=1,b=2,...}), but be > more concise. yes it is, however field updates are occasionally slightly annoying, since they can't change something's type at all, IIRC. Say, data C nx ny = C { x :: nx, y :: ny } x_set :: nx2 -> C nx1 ny -> C nx2 ny --x_set x2 c = c {x = x2} --type error --x_set x2 = ({x = x2}) --still a type error x_set x2 c = C {x = x2, y = y c} --legal Which is possibly a reason to stay away from field-update syntax on some occasions, and therefore not want it to get a more prominent place in the language if it doesn't deserve it yet. -Isaac From igloo at earth.li Mon Jul 27 16:03:34 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Jul 27 15:44:48 2009 Subject: Haskell 2010: libraries In-Reply-To: <20090714125734.GA17788@matrix.chaos.earth.li> References: <4A54A899.1030801@gmail.com> <1247518610.22466.8877.camel@localhost> <20090713232042.GA7309@matrix.chaos.earth.li> <1247570631.22466.8945.camel@localhost> <20090714125734.GA17788@matrix.chaos.earth.li> Message-ID: <20090727200334.GA22796@matrix.chaos.earth.li> On Tue, Jul 14, 2009 at 01:57:34PM +0100, Ian Lynagh wrote: > On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote: > > On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote: > > > On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: > > > > > > > To take one example, since List was immortalised in the H98 report with > > > 104 exports, Data.List has gained an additional 7 exports: > > > > > > The last change (making the behaviour of the generic* functions > > > consistent with their non-generic counterparts) was less than a year > > > ago, and the last additions were less than 2. > > > > Though also note that we have not changed any of the existing ones. > > Yes we have, less than a year ago: Also, we've just had a proposal to change some others: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} http://hackage.haskell.org/trac/ghc/ticket/3399 Both functions are spec in List in haskell98: http://haskell.org/onlinereport/list.html Thanks Ian From jon.fairbairn at cl.cam.ac.uk Tue Jul 28 05:19:49 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Tue Jul 28 05:01:08 2009 Subject: Proposal: FirstClassFieldUpdates References: <20090726013459.GA18475@matrix.chaos.earth.li> <4A6C9652.8050508@isaac.cedarswampstudios.org> <4A6DDE74.2060007@isaac.cedarswampstudios.org> Message-ID: Isaac Dupree writes: > Jon Fairbairn wrote: >> Parenthesis around updates would make them into functions, ie >> ({a=1,b=2,...}) would mean the same as (\d -> d{a=1,b=2,...}), but be >> more concise. > > yes it is, however field updates are occasionally slightly > annoying, since they can't change something's type at all, > IIRC. Say, > data C nx ny = C { x :: nx, y :: ny } > x_set :: nx2 -> C nx1 ny -> C nx2 ny > --x_set x2 c = c {x = x2} --type error If that were the case, it would be a serious wart that needed to be addressed. However, implementation would be fairly straightforward as an "extension" is already present in ghc: let x_set x2 c = c{x=x2} :t x_set x_set :: nx -> C t ny -> C nx ny ;-) (or did I misunderstand you?) -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From nhn at Cs.Nott.AC.UK Tue Jul 28 09:16:00 2009 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Tue Jul 28 09:01:46 2009 Subject: Proposal: FirstClassFieldUpdates In-Reply-To: References: <20090726013459.GA18475@matrix.chaos.earth.li> <4A6C9652.8050508@isaac.cedarswampstudios.org> <4A6DDE74.2060007@isaac.cedarswampstudios.org> Message-ID: <4A6EFA10.5000407@cs.nott.ac.uk> Hi all, Jon Fairbairn wrote: > Isaac Dupree wrote: > > > > yes it is, however field updates are occasionally slightly > > annoying, since they can't change something's type at all, > > IIRC. Say, > > data C nx ny = C { x :: nx, y :: ny } > > x_set :: nx2 -> C nx1 ny -> C nx2 ny > > --x_set x2 c = c {x = x2} --type error > > If that were the case, it would be a serious wart that needed to be > addressed. However, implementation would be fairly straightforward as > an "extension" is already present in ghc: > > let x_set x2 c = c{x=x2} > :t x_set > x_set :: nx -> C t ny -> C nx ny > > ;-) (or did I misunderstand you?) Indeed, field update can change the type, which I guess is the point Jon is making. And Isaac's example above compiles without any problems or extensions. H98 as far as I'm aware. However, there are cases where the current field update facility arguably isn't good enough, namely when there are more than one constructor, some of which do not have certain of the fields. See http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords for examples, in particular "Polymorphic Record Update take II". As an aside, having revisited that discussion, I still think the idea of being able to do an update for constructors that do NOT have certain fields makes a lot of sense. The record wildcard extension, that was mentioned as a possible workaround, seems far less appealing and flexible. I don't even know what it would mean if it's used more than once in a scope, e.g. what about the following: f (C1 {a = 1, ..}) (C2 {b = 2, ..}) = (C1 {a = 10, ..}, C2 {b = 20, ..}) ??? Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From ml at isaac.cedarswampstudios.org Tue Jul 28 21:50:12 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Tue Jul 28 21:31:31 2009 Subject: Proposal: FirstClassFieldUpdates In-Reply-To: References: <20090726013459.GA18475@matrix.chaos.earth.li> <4A6C9652.8050508@isaac.cedarswampstudios.org> <4A6DDE74.2060007@isaac.cedarswampstudios.org> Message-ID: <4A6FAAD4.1050505@isaac.cedarswampstudios.org> Jon Fairbairn wrote: > Isaac Dupree > > writes: > >> Jon Fairbairn wrote: >>> Parenthesis around updates would make them into functions, ie >>> ({a=1,b=2,...}) would mean the same as (\d -> d{a=1,b=2,...}), but be >>> more concise. >> yes it is, however field updates are occasionally slightly >> annoying, since they can't change something's type at all, >> IIRC. Say, >> data C nx ny = C { x :: nx, y :: ny } >> x_set :: nx2 -> C nx1 ny -> C nx2 ny >> --x_set x2 c = c {x = x2} --type error > > If that were the case, it would be a serious wart that needed to be > addressed. However, implementation would be fairly straightforward as > an "extension" is already present in ghc: oh maybe I got confused. (My confusion also could have been the result of a bug that was recently fixed in GHC that affected the type of some cases like that where there are multiple constructors...) -Isaac From sweirich at cis.upenn.edu Wed Jul 29 14:34:26 2009 From: sweirich at cis.upenn.edu (Stephanie Weirich) Date: Wed Jul 29 14:16:02 2009 Subject: Proposals and owners In-Reply-To: <20090711090128.GA5861@soi.city.ac.uk> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> Message-ID: Ok, I've put together a page on EmptyDataDecls: http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls Cheers, Stephanie From Christian.Maeder at dfki.de Thu Jul 30 08:51:07 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jul 30 08:32:14 2009 Subject: empty decls Re: Proposals and owners In-Reply-To: References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> Message-ID: <4A71973B.60807@dfki.de> Stephanie Weirich wrote: > Ok, I've put together a page on EmptyDataDecls: > > http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls This reminds me to the related ticket: http://hackage.haskell.org/trac/ghc/ticket/393 If a dummy definition can be supplied for a function, then also a dummy constructor value can be supplied for a data type. If empty bindings and/or data types are supported the compiler can at least better warn about them. Cheers Christian From marlowsd at gmail.com Fri Jul 31 09:43:03 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 31 09:24:07 2009 Subject: Proposals and owners In-Reply-To: <4A5461C9.5020501@gmail.com> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> Message-ID: <4A72F4E7.8080405@gmail.com> I have fleshed out the report delta for > > remove FixityResolution from the context-free grammar http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution Please take a look and comment. This fixes a nasty bug in the Haskell syntax - albeit one that doesn't cause problems in practice, but still. I think the changes make the grammar look nicer, and help compiler implementers by providing a sample implementation of fixity resolution. We better be sure the sample implementation is correct! I've tested it fairly well, but I wouldn't rule out corner cases being wrong, especially with prefix negation. Cheers, Simon From ndmitchell at gmail.com Fri Jul 31 09:51:22 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jul 31 09:32:24 2009 Subject: Proposals and owners In-Reply-To: <4A72F4E7.8080405@gmail.com> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <4A72F4E7.8080405@gmail.com> Message-ID: <404396ef0907310651k184b7575u1f00c601526d9356@mail.gmail.com> Hi >> ?> remove FixityResolution from the context-free grammar > > http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution > > Please take a look and comment. ?This fixes a nasty bug in the Haskell > syntax - albeit one that doesn't cause problems in practice, but still. ?I > think the changes make the grammar look nicer, and help compiler > implementers by providing a sample implementation of fixity resolution. > > We better be sure the sample implementation is correct! ?I've tested it > fairly well, but I wouldn't rule out corner cases being wrong, especially > with prefix negation. The code in Resolve.hs has been used by HLint for months, and is the basis of the resolution used in haskell-src-exts 1.0.0. In that time I haven't seen any bugs with the fixity resolution. Thanks, Neil From marlowsd at gmail.com Fri Jul 31 10:20:02 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jul 31 10:01:07 2009 Subject: Proposals and owners In-Reply-To: <404396ef0907310651k184b7575u1f00c601526d9356@mail.gmail.com> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <4A72F4E7.8080405@gmail.com> <404396ef0907310651k184b7575u1f00c601526d9356@mail.gmail.com> Message-ID: <4A72FD92.1040809@gmail.com> On 31/07/2009 14:51, Neil Mitchell wrote: > Hi > >>> > remove FixityResolution from the context-free grammar >> >> http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution >> >> Please take a look and comment. This fixes a nasty bug in the Haskell >> syntax - albeit one that doesn't cause problems in practice, but still. I >> think the changes make the grammar look nicer, and help compiler >> implementers by providing a sample implementation of fixity resolution. >> >> We better be sure the sample implementation is correct! I've tested it >> fairly well, but I wouldn't rule out corner cases being wrong, especially >> with prefix negation. > > The code in Resolve.hs has been used by HLint for months, and is the > basis of the resolution used in haskell-src-exts 1.0.0. In that time I > haven't seen any bugs with the fixity resolution. I updated the code on the wiki page: the previous version didn't handle prefix negation - did you implement that yourself in HLint? Cheers, Simon From lennart at augustsson.net Fri Jul 31 11:04:49 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Jul 31 10:45:53 2009 Subject: Proposals and owners In-Reply-To: References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> Message-ID: I think that a natural extension to allowing empty data declarations would be to allow empty case expressions. On Wed, Jul 29, 2009 at 7:34 PM, Stephanie Weirich wrote: > Ok, I've put together a page on EmptyDataDecls: > > http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls > > Cheers, > Stephanie > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From iavor.diatchki at gmail.com Fri Jul 31 11:53:00 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri Jul 31 11:34:01 2009 Subject: Proposals and owners In-Reply-To: References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> Message-ID: <5ab17e790907310853r29222c81t2822579783288919@mail.gmail.com> +1. I completely agree. On Fri, Jul 31, 2009 at 6:04 PM, Lennart Augustsson wrote: > I think that a natural extension to allowing empty data declarations > would be to allow empty case expressions. > > On Wed, Jul 29, 2009 at 7:34 PM, Stephanie > Weirich wrote: >> Ok, I've put together a page on EmptyDataDecls: >> >> http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls >> >> Cheers, >> Stephanie >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime >> > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime >