From bulat.ziganshin at gmail.com Wed Nov 1 02:53:45 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 1 03:11:12 2006 Subject: [Hugs-users] Record puns, time for removal? In-Reply-To: <9235EC6F-2F51-4E90-8A2A-DA707BB2B351@augustsson.net> References: <404396ef0610270857v23da104bmad3299563440aab3@mail.gmail.com> <8F85FE95-5C5A-4777-8F43-3A45F05FDCDF@comcast.net> <036EAC76E7F5EC4996A3B3C3657D4116070D5BF4@EUR-MSG-21.europe.corp.microsoft.com> <1348702319.20061031002058@gmail.com> <9235EC6F-2F51-4E90-8A2A-DA707BB2B351@augustsson.net> Message-ID: <534990334.20061101105345@gmail.com> Hello Lennart, Tuesday, October 31, 2006, 1:16:43 AM, you wrote: > Funny that you should mention this idea. I spent last night and this > morning implementing it in ghc. But I use '..' instead of '*'. thank you a lot! it's sad that we not discussed this earlier :) > The punning is available both for expressions and patterns. that you mean? thing mentioned by Iavor?: f Record1 {..} = let a = 1 b = 2 in Record2 {..} > I am of two minds about this extension. It introduces bound > variables without mentioning the variable at the binding site. This > can be error prone. (But 'import' has similar problems.) > Dubious as it is, when using large records it reduces the amount of > boiler place code significantly. exactly. and you name it - _boilerplate_ code. i can distinguish the things that is essential for understanding algorithm from things that just eats the space. and describing which options i'm going to use in this function is not the best job. ultimately, field selection operator will be enough, but it's beyound of our current abilities -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Wed Nov 1 04:10:44 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Nov 1 04:10:46 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: <20061030051714.GI2239@momenergy.repetae.net> References: <20061005135618.1ADCD3242DE@www.haskell.org><45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> Message-ID: <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> The thread about "stand-alone" deriving is long-ish now, so I have summarised the issues here: http://haskell.org/haskellwiki/GHC/StandAloneDeriving Perhaps those who are interested can add their thoughts? Bjorn is busy at the moment, but I think he'll get back to the implementation in a while, so now is a good time to refine the design. I've tried to note all the issues that came up by email, but I might have missed. I put it on the GHC wiki, because I'm not proposing it for Haskell'. (Someone else is free to do so, of course.) Simon | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | John Meacham | Sent: 30 October 2006 05:17 | To: haskell-prime@haskell.org | Subject: Re: Proposal for stand-alone deriving declarations? | | On Fri, Oct 06, 2006 at 10:39:39AM -0500, Michael Shulman wrote: | > On 10/6/06, John Hughes wrote: | > >deriving (Eq Foo, Ord Foo) | > > | > >instead of | > > | > >deriving (Eq, Ord) for Foo | > | > So what does | > | > newtype Foo a = Foo a | > newtype Bar b = Bar b | > class C a b | > deriving (C (Foo a) (Bar b)) | > | > mean? I could see it meaning any or all of the following: | > | > instance (C (Foo a) b) => (C (Foo a) (Bar b)) | > instance (C a (Bar b)) => (C (Foo a) (Bar b)) | > instance (C a b) => (C (Foo a) (Bar b)) | | | this is why we should make this explicit when deriving "complex" newtype | instances, so we would write exactly the instance we want to derive: | | > deriving (C (Foo a) b) => (C (Foo a) (Bar b)) | > deriving (C a (Bar b)) => (C (Foo a) (Bar b)) | > deriving (C a b) => (C (Foo a) (Bar b)) | | respectively. | | John | | -- | John Meacham - ?repetae.net?john? | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime From lennart at augustsson.net Wed Nov 1 07:57:49 2006 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Nov 1 07:58:12 2006 Subject: [Hugs-users] Record puns, time for removal? In-Reply-To: <534990334.20061101105345@gmail.com> References: <404396ef0610270857v23da104bmad3299563440aab3@mail.gmail.com> <8F85FE95-5C5A-4777-8F43-3A45F05FDCDF@comcast.net> <036EAC76E7F5EC4996A3B3C3657D4116070D5BF4@EUR-MSG-21.europe.corp.microsoft.com> <1348702319.20061031002058@gmail.com> <9235EC6F-2F51-4E90-8A2A-DA707BB2B351@augustsson.net> <534990334.20061101105345@gmail.com> Message-ID: On Nov 1, 2006, at 02:53 , Bulat Ziganshin wrote: > Hello Lennart, > >> The punning is available both for expressions and patterns. > > that you mean? thing mentioned by Iavor?: > > f Record1 {..} = let a = 1 > b = 2 > in Record2 {..} Yes, exactly. I will send a patch for ghc as soon as I have cleaned it up and managed to test it some. (At the moment ghc HEAD cannot bootstrap itself on my MacBook so I can't test so well.) -- Lennart From brianlsmith at gmail.com Wed Nov 1 13:30:31 2006 From: brianlsmith at gmail.com (Brian Smith) Date: Wed Nov 1 13:30:24 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: On 11/1/06, Simon Peyton-Jones wrote: > > The thread about "stand-alone" deriving is long-ish now, so I have > summarised the issues here: > http://haskell.org/haskellwiki/GHC/StandAloneDeriving I think it is difficult to discuss things via a Wiki. I tried to add my comments to the page and it took a lot of edits due to a collision with BrianH's edit. Plus, it is not clear to me how agreement is to be indicated. For example, I think that Brian H's idea really good. Basically, the syntax for instances and derived instances would be identical, but derived instances would just omit the "where" clause, while non-derived instances would need the "where" clause. For that to work, the rules for when a context is required need to be the same for derived and non-derived instances, which I also think is a good idea. It is a much better idea than my "derive instance" suggestion, and I no longer support it. - Brian Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20061101/d6981d62/attachment.htm From ross at soi.city.ac.uk Wed Nov 1 14:08:33 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Nov 1 14:08:35 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <20061101190833.GA17903@soi.city.ac.uk> On Wed, Nov 01, 2006 at 12:30:31PM -0600, Brian Smith wrote: > I think it is difficult to discuss things via a Wiki. Yes, a mailing list is much better for discussion. In response to your point about duplicate derived instances, yes, it would make derived instances different from explicit ones, but as I've argued before, I think it's unavoidable: http://www.haskell.org/pipermail/haskell-prime/2006-October/thread.html#1739 If you accept that this is the primary use of the standalone feature, such conflicts will happen all the time. From simonpj at microsoft.com Wed Nov 1 14:12:49 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Nov 1 14:12:22 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: <20061101190833.GA17903@soi.city.ac.uk> Message-ID: <036EAC76E7F5EC4996A3B3C3657D411607130324@EUR-MSG-21.europe.corp.microsoft.com> | > I think it is difficult to discuss things via a Wiki. | | Yes, a mailing list is much better for discussion. I agree. But the Wiki is an excellent place to specify alternative designs, and summarise their advantages and disadvantages. Otherwise alternative designs can get lost in the twists and turns of a long thread. So: discuss by email, record outcomes and articulate alternative design choices on the Wiki Simon From brianlsmith at gmail.com Wed Nov 1 16:15:38 2006 From: brianlsmith at gmail.com (Brian Smith) Date: Wed Nov 1 16:15:29 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: <20061101190833.GA17903@soi.city.ac.uk> References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> <20061101190833.GA17903@soi.city.ac.uk> Message-ID: On 11/1/06, Ross Paterson wrote: > > On Wed, Nov 01, 2006 at 12:30:31PM -0600, Brian Smith wrote: > In response to your point about duplicate derived instances, yes, it > would make derived instances different from explicit ones, but as I've > argued before, I think it's unavoidable: > > > http://www.haskell.org/pipermail/haskell-prime/2006-October/thread.html#1739 > > If you accept that this is the primary use of the standalone feature, > such conflicts will happen all the time. How an instance is defined (explicitly or derived) should have nothing to do with how it is imported/exported in a module. In particular, I think having features like : import M1 hiding (instance C T) and module M hiding (instance C T) would eliminate the need for special-case handling of derived instances (if two imported modules happen to derive the same instances, you can just hide the instances from one of them). Instance hiding is an important feature in its own right. - Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20061101/960808c3/attachment.htm From Malcolm.Wallace at cs.york.ac.uk Wed Nov 1 16:46:43 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Nov 1 16:46:34 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <20061101214643.23d76f2f.Malcolm.Wallace@cs.york.ac.uk> "Brian Smith" writes: > > http://haskell.org/haskellwiki/GHC/StandAloneDeriving > > Basically, the syntax > for instances and derived instances would be identical, but derived > instances would just omit the "where" clause, while non-derived instances > would need the "where" clause. This is a really _bad_ idea for readability. In a year's time, when this discussion is forgotten, who would be able to tell at a glance the deep and real semantic difference between the following two instance decls? instance Num (Bar z) where and instance Num (Bar z) The former declares that _no_ methods are defined (except for defaults), and the latter, with your proposal, that _all_ methods are defined. The real killer is that both of these decls are already valid in Haskell'98, but they mean the _same_ thing (the former, if you were wondering). This is a sure recipe for introducing new and subtle bugs into existing bug-free programs. Regards, Malcolm From brianlsmith at gmail.com Wed Nov 1 17:04:19 2006 From: brianlsmith at gmail.com (Brian Smith) Date: Wed Nov 1 17:04:11 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: <20061101214643.23d76f2f.Malcolm.Wallace@cs.york.ac.uk> References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> <20061101214643.23d76f2f.Malcolm.Wallace@cs.york.ac.uk> Message-ID: On 11/1/06, Malcolm Wallace wrote: > > "Brian Smith" writes: > > > > http://haskell.org/haskellwiki/GHC/StandAloneDeriving > > > > Basically, the syntax > > for instances and derived instances would be identical, but derived > > instances would just omit the "where" clause, while non-derived > instances > > would need the "where" clause. > > This is a really _bad_ idea for readability. In a year's time, when > this discussion is forgotten, who would be able to tell at a glance the > deep and real semantic difference between the following two instance > decls? > > instance Num (Bar z) where > and > instance Num (Bar z) > > The former declares that _no_ methods are defined (except for defaults), > and the latter, with your proposal, that _all_ methods are defined. The > real killer is that both of these decls are already valid in Haskell'98, > but they mean the _same_ thing (the former, if you were wondering). > > This is a sure recipe for introducing new and subtle bugs into existing > bug-free programs. Malcolm, thank you for pointing that out. To be honest, I had not read this sentence of the report (section 4.3.2 of http://haskell.org/onlinereport/decls.html): "If no binding is given for some class method then the corresponding default class method in the class declaration is used (if present); if such a default does not exist then the class method of this instance is bound to undefined and no compile-time error results." Personally, I think that the part after the semicolon is the part that leads to subtle bugs, not Brian H's proposal. Why is this not considered a compile-time error? There was a previous mention of it on the list [1] but there was no explanation given. I think it would be better if the report stated this instead: "If no binding is given for some class method then the corresponding default class method in the class declaration is used (if present); if such a default does not exist then a compile-time error results." [1] http://www.haskell.org/pipermail/haskell/2003-May/011899.html - Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20061101/9d9276f1/attachment-0001.htm From john at repetae.net Wed Nov 1 18:51:57 2006 From: john at repetae.net (John Meacham) Date: Wed Nov 1 18:51:28 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> <20061101190833.GA17903@soi.city.ac.uk> Message-ID: <20061101235157.GA12614@momenergy.repetae.net> On Wed, Nov 01, 2006 at 03:15:38PM -0600, Brian Smith wrote: > How an instance is defined (explicitly or derived) should have nothing to do > with how it is imported/exported in a module. > > In particular, I think having features like : > import M1 hiding (instance C T) > and > module M hiding (instance C T) > would eliminate the need for special-case handling of derived instances (if > two imported modules happen to derive the same instances, you can just hide > the instances from one of them). Instance hiding is an important feature in > its own right. selective importing and exporting of instances is a really tricky technical issue for a lot of reasons, and a bad idea for many others. For a quick example, imagine a Set created with some operations using one Ord instance and other operations using another. the globalness of instance declarations is a great tool. Fortunately, newtype deriving (hopefully extended as I have mentioned on this thread) and rank-n polymorphism make it pretty much unneeded. John -- John Meacham - ?repetae.net?john? From basvandijk at home.nl Wed Nov 1 18:54:10 2006 From: basvandijk at home.nl (Bas van Dijk) Date: Wed Nov 1 18:54:01 2006 Subject: Importing and Exporting Instance Declarations Message-ID: <200611020054.10180.basvandijk@home.nl> Hello, Can anybody explain or point me to previous discussions about why it isn't allowed to import and export instance declarations? See: section 5.4 of http://haskell.org/onlinereport/modules.html I don't want to propose this for Haskell' (yet) because I think there has to be some very good reasons why this seemingly very obvious feature is missing. regards, Bas van Dijk From bulat.ziganshin at gmail.com Thu Nov 2 02:56:06 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 2 05:53:42 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> <20061101190833.GA17903@soi.city.ac.uk> Message-ID: <659263286.20061102105606@gmail.com> Hello Brian, Thursday, November 2, 2006, 12:15:38 AM, you wrote: > In particular, I think having features like : > ???? import M1 hiding (instance C T) > and > ??? module M hiding (instance C T) > would eliminate the need for special-case handling of derived > instances (if two imported modules happen to derive the same > instances, you can just hide the instances from one of them). > Instance hiding is an important feature in its own right. i vote for this feature too. in my AltBinary library, there are many different ways to serialize strings, for example. i want to provide default "instance Binary String" for quick&dirty use and ability to hide just this instance in the case when user need to overwrite it. now i forced to put all instance declarations in separate file and suggest user to copy this file into his project and make appropriate edits! also, expicit instance imports was in prewvious Haskell versions. so i think it will be great to use implicit importing of all instances by default but allow to hide all instances or specific instance and import just the instance required: import M (instance Binary String) -- hides all other Binary instances module M hiding (instance Binary) -- hides all Binary instances -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Thu Nov 2 03:04:06 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 2 05:53:50 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: <20061101214643.23d76f2f.Malcolm.Wallace@cs.york.ac.uk> References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> <20061101214643.23d76f2f.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <1202012071.20061102110406@gmail.com> Hello Malcolm, Thursday, November 2, 2006, 12:46:43 AM, you wrote: > instance Num (Bar z) where > and > instance Num (Bar z) > The former declares that _no_ methods are defined (except for defaults), > and the latter, with your proposal, that _all_ methods are defined. The i join to this note. moreover, currently GHC supports "generics for the masses" that may mean very subtle semantic changes between code generated by these two forms :)) i think it will be better to use derive/deriving/derived prepended to the former: derive instance Num (Bar z) derive instance Num z => Num (Bar z) and allow generics/TH/other forms of user-specified deriving to catch such declarations and provide alternative to compiler-wired deriving mechanism. so we can imagine that we discuss some general deriving syntax that in future will be reused by new Haskell extensions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Malcolm.Wallace at cs.york.ac.uk Thu Nov 2 06:16:04 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Nov 2 06:19:08 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: <659263286.20061102105606@gmail.com> References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> <20061101190833.GA17903@soi.city.ac.uk> <659263286.20061102105606@gmail.com> Message-ID: <20061102111604.6415f721.Malcolm.Wallace@cs.york.ac.uk> Bulat Ziganshin wrote: > > import M1 hiding (instance C T) > > i vote for this feature too. > also, expicit instance imports was in prewvious Haskell versions. I'm fairly confident that Haskell has never historically permitted the explicit import and export of instances. It is not semantically sound, unless you are able to name the instances separately, but Haskell has always had anonymous instances, with only one instance permitted per concrete type. However, if Haskell' gets PolymorphicComponents in records, then at last you will be able to construct dictionaries explicitly, have more than one per type, name them, and pass them around. (But the downside is that if you do dictionaries explicitly, you will no longer have access to the class machinery to do predicate resolution and simplification for you - that would become a manual process. But you only pay the price if you want the explicitness.) Regards, Malcolm From ross at soi.city.ac.uk Thu Nov 2 06:19:58 2006 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Nov 2 06:19:49 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: <20061101235157.GA12614@momenergy.repetae.net> References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> <20061101190833.GA17903@soi.city.ac.uk> <20061101235157.GA12614@momenergy.repetae.net> Message-ID: <20061102111958.GA31723@soi.city.ac.uk> On Wed, Nov 01, 2006 at 03:51:57PM -0800, John Meacham wrote: > On Wed, Nov 01, 2006 at 03:15:38PM -0600, Brian Smith wrote: > > Instance hiding is an important feature in its own right. > > selective importing and exporting of instances is a really tricky > technical issue for a lot of reasons, and a bad idea for many others. As an example of the technical difficulties, recall that with ghc -fglasgow-exts and hugs -98 defer reducing contexts using instances until forced to (see FlexibleContexts). If instances can come and go, this will be even more confusing. From brianlsmith at gmail.com Fri Nov 3 12:12:25 2006 From: brianlsmith at gmail.com (Brian Smith) Date: Fri Nov 3 12:12:12 2006 Subject: Proposal for stand-alone deriving declarations? In-Reply-To: <1202012071.20061102110406@gmail.com> References: <20061005135618.1ADCD3242DE@www.haskell.org> <45262803.50901@cs.chalmers.se> <20061030051714.GI2239@momenergy.repetae.net> <036EAC76E7F5EC4996A3B3C3657D41160712FDB9@EUR-MSG-21.europe.corp.microsoft.com> <20061101214643.23d76f2f.Malcolm.Wallace@cs.york.ac.uk> <1202012071.20061102110406@gmail.com> Message-ID: On 11/2/06, Bulat Ziganshin wrote: > > Hello Malcolm, > > Thursday, November 2, 2006, 12:46:43 AM, you wrote: > > > instance Num (Bar z) where > > and > > instance Num (Bar z) > > > The former declares that _no_ methods are defined (except for defaults), > > and the latter, with your proposal, that _all_ methods are defined. The > > i join to this note. moreover, currently GHC supports "generics for > the masses" that may mean very subtle semantic changes between code > generated by these two forms :)) Thank you guys for your responses. Effectively, every class method has a default implementation: if the programmer does not supply a default implementation, then the the "default" default implementation is undefined. But, does it make sense to create a class with default methods, but which is also derivable, such that the derived instance declarations are different than if the default implementations are chosen? When would it make sense to allow: derive instance A B and instance A B and have them both be valid (not at the same time, of course), but mean totally different things? I think it would be very confusing, especially for the innocent user who simply forgets the "derive" psudo-keyword. Would it be possible to make deriving a special case of defaulting? That is, could we define every derivable class so that every method defaulted, instead of to undefined, to some "deriving magic," perhaps expressible in Template Haskell? Perhaps we could say that all classes that have all their methods defaulted are then derivable? - Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20061103/ae7e0bf3/attachment.htm From Benjamin.Rudiak-Gould at cl.cam.ac.uk Sat Nov 4 13:45:56 2006 From: Benjamin.Rudiak-Gould at cl.cam.ac.uk (Ben Rudiak-Gould) Date: Sat Nov 4 13:45:56 2006 Subject: Importing and Exporting Instance Declarations In-Reply-To: <200611020054.10180.basvandijk@home.nl> References: <200611020054.10180.basvandijk@home.nl> Message-ID: Bas van Dijk wrote: > Can anybody explain or point me to previous discussions about why it isn't > allowed to import and export instance declarations? With the exception of instance declarations, the module system deals only with names, not scope. Importing a module just gives new names to things that were (in principle) already in scope. Instance declarations are an unfortunate special case, because (like type signatures and fixity declarations) they don't introduce any identifiers, but (unlike those declarations) they aren't tied to identifiers introduced in the same module. As a result, their very existence destroys the purity of import declarations. I think that this problem could have been prevented by requiring that every instance declaration mention in its head a type or class that was declared in the same module, but I doubt that would go over well -- people already complain enough about the fact that you can't use "deriving" across modules. So explicit import/export of instance declarations would not be a very natural extension. Even if a semantics could be worked out, it would presumably be necessary to preserve the current rules against overlapping instances, meaning that you couldn't do things like hide the Prelude definition of Num Int and define your own locally. -- Ben From bulat.ziganshin at gmail.com Sat Nov 4 01:59:38 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 4 16:45:02 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: <454BF5D3.60705@imageworks.com> References: <002001c6efa4$c8372510$1cf52950@osmet> <22523.213.84.177.94.1161000771.squirrel@webmail.xs4all.nl> <5ce89fb50610160731ja2de0d8l23903e914dcfe8da@mail.gmail.com> <984680831.20061016195414@gmail.com> <454BF5D3.60705@imageworks.com> Message-ID: <706781845.20061104095938@gmail.com> Hello Dan, Saturday, November 4, 2006, 5:07:15 AM, you wrote: > Here's an idea that (I think) is useful and backwards compatible: > fractional and negative fixity. yes, i think the same. for example, once i've tried to define postfix 'when' operator like those in perl/ruby print msg `on` mode==debug but failed because my code frequently contains '$' and there is no way to define operation with a lower precedence really, there is another alternative to solve my particular problem: make `op` applications having fixed -1 precedence. such applications look "heavyweight" and once i have a wonderful debugging story just because for my eyes it was obvious that (a `div` b+1) means "do add before div" -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Mon Nov 6 12:07:17 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Nov 6 16:44:07 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: References: <002001c6efa4$c8372510$1cf52950@osmet> <22523.213.84.177.94.1161000771.squirrel@webmail.xs4all.nl> <5ce89fb50610160731ja2de0d8l23903e914dcfe8da@mail.gmail.com> <984680831.20061016195414@gmail.com> <454BF5D3.60705@imageworks.com> <706781845.20061104095938@gmail.com> Message-ID: <1809061187.20061106200717@gmail.com> Hello Henning, Monday, November 6, 2006, 1:27:54 PM, you wrote: >> print msg `on` mode==debug >> >> but failed because my code frequently contains '$' and there is no way >> to define operation with a lower precedence > This could be solved by the solutions proposed in this thread: > > http://www.haskell.org/pipermail/haskell-cafe/2006-October/018923.html it's too complex for my purposes. -1 priority is enough -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From haskell at henning-thielemann.de Tue Nov 7 06:00:37 2006 From: haskell at henning-thielemann.de (Henning Thielemann) Date: Tue Nov 7 06:01:29 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: <1809061187.20061106200717@gmail.com> References: <002001c6efa4$c8372510$1cf52950@osmet> <22523.213.84.177.94.1161000771.squirrel@webmail.xs4all.nl> <5ce89fb50610160731ja2de0d8l23903e914dcfe8da@mail.gmail.com> <984680831.20061016195414@gmail.com> <454BF5D3.60705@imageworks.com> <706781845.20061104095938@gmail.com> <1809061187.20061106200717@gmail.com> Message-ID: On Mon, 6 Nov 2006, Bulat Ziganshin wrote: > Hello Henning, > > Monday, November 6, 2006, 1:27:54 PM, you wrote: > > >> print msg `on` mode==debug > >> > >> but failed because my code frequently contains '$' and there is no way > >> to define operation with a lower precedence > > > This could be solved by the solutions proposed in this thread: > > > > http://www.haskell.org/pipermail/haskell-cafe/2006-October/018923.html > > it's too complex for my purposes. -1 priority is enough This reminds me on good old BASIC programming days, where we numbered lines in steps of 10, in order to be able insert lines later. Unfortunately, BASIC never supported negative nor fractional line numbers. :-) From lennart at augustsson.net Tue Nov 7 07:59:49 2006 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Nov 7 07:59:39 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: References: <002001c6efa4$c8372510$1cf52950@osmet> <22523.213.84.177.94.1161000771.squirrel@webmail.xs4all.nl> <5ce89fb50610160731ja2de0d8l23903e914dcfe8da@mail.gmail.com> <984680831.20061016195414@gmail.com> <454BF5D3.60705@imageworks.com> <706781845.20061104095938@gmail.com> <1809061187.20061106200717@gmail.com> Message-ID: <17DF76C3-68BF-41D5-BD77-8C695D3F8E65@augustsson.net> But DEC's language FOCAL had fractional line numbers. :) On Nov 7, 2006, at 06:00 , Henning Thielemann wrote: > > On Mon, 6 Nov 2006, Bulat Ziganshin wrote: > >> Hello Henning, >> >> Monday, November 6, 2006, 1:27:54 PM, you wrote: >> >>>> print msg `on` mode==debug >>>> >>>> but failed because my code frequently contains '$' and there is >>>> no way >>>> to define operation with a lower precedence >> >>> This could be solved by the solutions proposed in this thread: >>> >>> http://www.haskell.org/pipermail/haskell-cafe/2006-October/ >>> 018923.html >> >> it's too complex for my purposes. -1 priority is enough > > This reminds me on good old BASIC programming days, where we numbered > lines in steps of 10, in order to be able insert lines later. > Unfortunately, BASIC never supported negative nor fractional line > numbers. > :-) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From simonmar at microsoft.com Tue Nov 7 10:24:40 2006 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Nov 7 10:24:36 2006 Subject: proposal: introduce lambda-match (explicit match failure andfall-through) In-Reply-To: <01e401c6fc82$82684f60$b93d7ad5@cr3lt> Message-ID: Claus Reinke writes: > may I be so optimistic as to interpret the absolute lack of counter > arguments over the last week as indication that this proposal is > acceptable in general? Since we don't have any experience of using this extension, and it comes late in the day, it's highly unlikely to become a part of Haskell', simply because the stated mission of Haskell' is to solidify the tried-and-trusted extensions. Cheers, Simon > Thanks to those few who have expressed > support so far, usually in the form "I've wanted something like > this for years"! (*) > > I have braved the evil trac-wiki formatter again, to convert the email > proposal into a slightly updated ticket, with attached patch for GHC, > support libraries and usage examples: > > introduce lambda-match (explicit match failure and fall-through) > http://hackage.haskell.org/trac/haskell-prime/ticket/114 > > most notable updates are in the support library (now being a bit > more helpful in preserving error messages and defining fall_through > cases; also supports joining of nested matches now), with a few > added examples demonstrating the changes. > > It is a good sign that the syntax patch itself has not changed so far, > and the support library now supports most of what I had in mind > for it (took me a while to figure out how to do "nest" ;-). But it > would be very helpful if more eyes looked over the code, to see > if the functionality is roughly right (not to mention the > implementation). > > And, of course, syntax patches for other Haskell implementations > would be great (at least verify whether your favourite implementation > can handle the support library, please - so far verified for GHC and > Hugs)! > > Thank you, > Claus > > ps. a quick recap for those who don't read webpages: a > lambda-match > > | | -> > > is syntactic sugar for > > \ -> case of > { | -> Match $ > return > ; _ -> Match $ fail "lambda-match failure" } > > which allows us to program explicitly with match failure > (represented as Monad.fail/MonadPlus.mzero) and match > fall-through (using MonadPlus.mplus), lifting MonadPlus > operations over function parameters for ease of use. > > this enables us to write previously practically impossible > things (the example file gives some indication of just how > unreadable and hence unusable these would be without > syntactic sugar), such as a user-defined case-variant > (included in the library): > > caseOf True $ ( |True-> False ) +++ ( |False-> True ) > --> False > > or monadic match-failure without using do-notation: > > return True >>= (ok $ |False-> return "hi") :: Maybe String > --> Nothing > > lambda-matches may be nested, but unlike PMC, that will > usually result in nested match monads, unless we use the new > "nest" to join the nested monads: > > myAnd = splice (nest (|True-> (|True->True) > +++ (|False->False)) > +++ nest (|False-> fall_through False) ) > > we can now also abstract over groups of match alternatives: > > grp :: MonadPlus m => String -> [(String, String)] -> > Match m String > grp = (| x locals | Just y <- lookup x locals -> y) > +++ (| "X" locals -> "42") > +++ matchError "var not found" > > and extend them later, or just use them to build > different functions: > > -- select only the first match > varVal :: String -> [(String, String)] -> String > varVal = spliceE grp > > -- a variation, delivering all successful matches > varVals :: String -> [(String, String)] -> [] String > varVals = allMatches grp > > leading to uses like these: > > *Main> varVal "X" [("X","hi")] > "hi" > *Main> varVal "Z" [("X","hi")] > "*** Exception: var not found > *Main> varVals "X" [("X","hi")] > ["hi","42"] > *Main> varVals "Z" [("X","hi")] > [] > > and so on, and so on.. see the proposal attachments for more > inspirations !-) > > (*) it might be useful for the Haskell' committee to clarify the > process for acceptance of proposals, similar to what the > Haskell library community has done recently: > > http://haskell.org/haskellwiki/Library_submissions > > (where the intent of the discussion period is to focus the > process, and to ensure progress, ie lack of objections to > a clearly implementable/implemented proposal is seen as > implicit agreement) > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From simonmar at microsoft.com Tue Nov 7 10:50:04 2006 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Nov 7 10:49:57 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: <706781845.20061104095938@gmail.com> Message-ID: haskell-prime-bounces@haskell.org wrote: > Hello Dan, > > Saturday, November 4, 2006, 5:07:15 AM, you wrote: > >> Here's an idea that (I think) is useful and backwards compatible: >> fractional and negative fixity. > > yes, i think the same. for example, once i've tried to define postfix > 'when' operator like those in perl/ruby > > print msg `on` mode==debug > > but failed because my code frequently contains '$' and there is no way > to define operation with a lower precedence > > really, there is another alternative to solve my particular problem: > make `op` applications having fixed -1 precedence. such applications > look "heavyweight" and once i have a wonderful debugging story just > because for my eyes it was obvious that (a `div` b+1) means "do add > before div" I'd support fractional and negative fixity. It's a simple change to make, but we also have to adopt http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/FixityResolution I've added the proposal to the end of that page. In fact, the page already mentioned that we could generalise fixity levels, but it didn't mention fractional or negative values being allowed. Cheers, Simon From haskell at henning-thielemann.de Tue Nov 7 11:15:12 2006 From: haskell at henning-thielemann.de (Henning Thielemann) Date: Tue Nov 7 11:16:04 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: References: Message-ID: On Tue, 7 Nov 2006, Simon Marlow wrote: > I'd support fractional and negative fixity. It's a simple change to > make, but we also have to adopt > > http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/FixityResolution > > I've added the proposal to the end of that page. In fact, the page > already mentioned that we could generalise fixity levels, but it didn't > mention fractional or negative values being allowed. Maybe that page could also mention earlier proposals and the solutions without precedence numbers. I prefer the non-numeric approach with rules like "(<) binds more tightly than (&&)", because it says what is intended and it allows to make things unrelated that are unrelated, e.g. infix operators from different libraries. Consequently a precedence relation to general infix operators like ($) and (.) had be defined in each library. From simonmar at microsoft.com Tue Nov 7 11:23:21 2006 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Nov 7 11:22:53 2006 Subject: patch applied (haskell-prime-report): make it work with recent GHCs Message-ID: <20061107162321.GA23403@cvs.haskell.org> Tue Nov 7 08:10:45 PST 2006 Simon Marlow * make it work with recent GHCs M ./tools/Makefile -3 +2 From simonmar at microsoft.com Tue Nov 7 11:23:22 2006 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Nov 7 11:22:56 2006 Subject: patch applied (haskell-prime-report): update to compile with recent Haskell compilers Message-ID: <20061107162322.GA23423@cvs.haskell.org> Tue Nov 7 08:11:17 PST 2006 Simon Marlow * update to compile with recent Haskell compilers M ./tools/tex.hs -5 +3 From simonmar at microsoft.com Tue Nov 7 11:23:24 2006 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Nov 7 11:22:56 2006 Subject: patch applied (haskell-prime-report): subsection needs to be interpreted by sh Message-ID: <20061107162324.GA23437@cvs.haskell.org> Tue Nov 7 08:13:22 PST 2006 Simon Marlow * subsection needs to be interpreted by sh M ./report/Makefile -1 +1 From simonmar at microsoft.com Tue Nov 7 11:23:25 2006 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Nov 7 11:22:58 2006 Subject: patch applied (haskell-prime-report): fix line-comment syntax to not consider ' --:' as a comment Message-ID: <20061107162325.GA23452@cvs.haskell.org> Tue Nov 7 08:22:46 PST 2006 Simon Marlow * fix line-comment syntax to not consider '--:' as a comment See LineCommentSyntax on the wiki, ticket #42 M ./report/syntax-lexical.verb -1 +1 From simonmar at microsoft.com Tue Nov 7 11:43:26 2006 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Nov 7 11:43:23 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: Message-ID: Henning Thielemann wrote: > On Tue, 7 Nov 2006, Simon Marlow wrote: > >> I'd support fractional and negative fixity. It's a simple change to >> make, but we also have to adopt >> >> > http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki > /FixityResolution >> >> I've added the proposal to the end of that page. In fact, the page >> already mentioned that we could generalise fixity levels, but it >> didn't mention fractional or negative values being allowed. > > Maybe that page could also mention earlier proposals and the solutions > without precedence numbers. I prefer the non-numeric approach > with rules > like "(<) binds more tightly than (&&)", because it says what > is intended > and it allows to make things unrelated that are unrelated, e.g. infix > operators from different libraries. This is a much more heavyweight change, and its not a clear win. Yes I agree that in some ways it's strange to enforce a total order between unrelated things, but on the other hand it's very convenient, and easy to understand. Currently the default fixity is infixl 9. That is, if you don't declare a fixity, you automatically get a fixity that can be used relative to every other operator. This is quite useful - I bet if we made it mandatory to declare all the relative fixities then we'd need to add fixity declarations to lots of code. I forsee this being quite tiresome. If you'd like to make a concrete proposal, then feel free to do so and I'll make sure it gets onto the wiki. Cheers, Simon From apfelmus at quantentunnel.de Tue Nov 7 11:47:52 2006 From: apfelmus at quantentunnel.de (apfelmus@quantentunnel.de) Date: Tue Nov 7 11:51:09 2006 Subject: Fractional/negative fixity? In-Reply-To: References: Message-ID: Henning Thielemann wrote: > On Tue, 7 Nov 2006, Simon Marlow wrote: > >> I'd support fractional and negative fixity. It's a simple change to >> make, but we also have to adopt >> >> http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/FixityResolution >> >> I've added the proposal to the end of that page. In fact, the page >> already mentioned that we could generalise fixity levels, but it didn't >> mention fractional or negative values being allowed. > > Maybe that page could also mention earlier proposals and the solutions > without precedence numbers. I prefer the non-numeric approach with rules > like "(<) binds more tightly than (&&)", because it says what is intended > and it allows to make things unrelated that are unrelated, e.g. infix > operators from different libraries. Consequently a precedence relation to > general infix operators like ($) and (.) had be defined in each library. I think that computable real fixity levels are useful, too. A further step to complex numbers is not advised because those cannot be ordered. But to be serious, the non-numeric rule based approach yields lattice-valued fixity levels. If we use a CPO, we gain ultimate expressiveness by being able to express fixity levels as fixed points of continuous functionals! Regards, apfelmus From ijones at galois.com Tue Nov 7 12:29:43 2006 From: ijones at galois.com (isaac jones) Date: Tue Nov 7 12:29:15 2006 Subject: patch applied (haskell-prime-report): fix line-comment syntax to not consider ' --:' as a comment In-Reply-To: <20061107162325.GA23452@cvs.haskell.org> References: <20061107162325.GA23452@cvs.haskell.org> Message-ID: <1162920583.5957.136.camel@localhost.localdomain> On Tue, 2006-11-07 at 08:23 -0800, Simon Marlow wrote: > Tue Nov 7 08:22:46 PST 2006 Simon Marlow > * fix line-comment syntax to not consider '--:' as a comment > See LineCommentSyntax on the wiki, ticket #42 > > > M ./report/syntax-lexical.verb -1 +1 Woohoo Simon! Small though it is, this is the first "official" update to the Haskell report from the Haskell' committee :) peace, isaac From haskell at henning-thielemann.de Tue Nov 7 12:30:09 2006 From: haskell at henning-thielemann.de (Henning Thielemann) Date: Tue Nov 7 12:30:37 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: References: Message-ID: On Tue, 7 Nov 2006, Simon Marlow wrote: > This is a much more heavyweight change, and its not a clear win. Haskell 2 ? :-) > If you'd like to make a concrete proposal, then feel free to do so and > I'll make sure it gets onto the wiki. What about the one of J?n Fairbairn ? http://www.haskell.org/pipermail/haskell-cafe/2006-October/018925.html From jon.fairbairn at cl.cam.ac.uk Tue Nov 7 13:10:30 2006 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Tue Nov 7 13:10:14 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: Your message of "Tue, 07 Nov 2006 18:30:09 +0100." Message-ID: <23077.1162923030@calligramme.charmers> On 2006-11-07 at 18:30+0100 Henning Thielemann wrote: > On Tue, 7 Nov 2006, Simon Marlow wrote: > > > This is a much more heavyweight change, and its not a clear win. > > Haskell 2 ? :-) > > > If you'd like to make a concrete proposal, then feel free to do so and > > I'll make sure it gets onto the wiki. > > What about the one of J?n Fairbairn ? > http://www.haskell.org/pipermail/haskell-cafe/2006-October/018925.html The proposal to which that message refers was made before Haskell really existed: we didn't know the concrete syntax of the language, so I used arbitrary keywords. Even if we look at Phil Wadler's subsequent tidying up of it, I'm not at all sure how it fits with the language as it stands now. So while it might make a reasonable starting point, I don't think it yet counts as a concrete proposal! I must say though, that I don't like the reasoning that we can put in fractional fixities because it's a small change. The way to hell is through a series of small steps. If using integers to express fixities is a bit of a hack, switching to rational numbers is a hack on top of a hack. J?n -- J?n Fairbairn Jon.Fairbairn at cl.cam.ac.uk From dmhouse at gmail.com Tue Nov 7 15:10:57 2006 From: dmhouse at gmail.com (David House) Date: Tue Nov 7 15:10:29 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: <23077.1162923030@calligramme.charmers> References: <23077.1162923030@calligramme.charmers> Message-ID: On 07/11/06, Jon Fairbairn wrote: > I must say though, that I don't like the reasoning that we > can put in fractional fixities because it's a small > change. The way to hell is through a series of small > steps. If using integers to express fixities is a bit of a > hack, switching to rational numbers is a hack on top of a > hack. Well, It's a _conceptually_ simple idea, one that doesn't make understanding the language much harder. Also, it provides an infinite space for fixities. I think the problem 'binds tighter than X but not as tight as Y', where X and Y are only fixity integer apart is somewhat common, and this would fix it. It would allow for extensibility into the future, where the operator space will only become more dense, and maintaining a complete order with only 10 integers to play will become more and more difficult. Allowing an infinite amount of operators to come between any two operators sounds like a solid design decision to me. -- -David House, dmhouse@gmail.com From lennart at augustsson.net Tue Nov 7 17:32:39 2006 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Nov 7 17:32:23 2006 Subject: Fractional/negative fixity? In-Reply-To: References: Message-ID: <7C54402C-E9EF-4B68-BA09-71AF9134D992@augustsson.net> On Nov 7, 2006, at 11:47 , apfelmus@quantentunnel.de wrote: > Henning Thielemann wrote: >> On Tue, 7 Nov 2006, Simon Marlow wrote: >> >>> I'd support fractional and negative fixity. It's a simple change to >>> make, but we also have to adopt >>> >>> http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/ >>> FixityResolution >>> >>> I've added the proposal to the end of that page. In fact, the page >>> already mentioned that we could generalise fixity levels, but it >>> didn't >>> mention fractional or negative values being allowed. >> >> Maybe that page could also mention earlier proposals and the >> solutions >> without precedence numbers. I prefer the non-numeric approach with >> rules >> like "(<) binds more tightly than (&&)", because it says what is >> intended >> and it allows to make things unrelated that are unrelated, e.g. infix >> operators from different libraries. Consequently a precedence >> relation to >> general infix operators like ($) and (.) had be defined in each >> library. > > I think that computable real fixity levels are useful, too. A further > step to complex numbers is not advised because those cannot be > ordered. But ordering of the computable reals is not computable. So it could cause the compiler to loop during parsing. :) -- Lennart From robdockins at fastmail.fm Tue Nov 7 17:49:22 2006 From: robdockins at fastmail.fm (Robert Dockins) Date: Tue Nov 7 17:50:00 2006 Subject: Fractional/negative fixity? In-Reply-To: <7C54402C-E9EF-4B68-BA09-71AF9134D992@augustsson.net> References: <7C54402C-E9EF-4B68-BA09-71AF9134D992@augustsson.net> Message-ID: <200611071749.22218.robdockins@fastmail.fm> On Tuesday 07 November 2006 17:32, Lennart Augustsson wrote: > On Nov 7, 2006, at 11:47 , apfelmus@quantentunnel.de wrote: > > Henning Thielemann wrote: > >> On Tue, 7 Nov 2006, Simon Marlow wrote: > >>> I'd support fractional and negative fixity. It's a simple change to > >>> make, but we also have to adopt > >>> > >>> http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/ > >>> FixityResolution > >>> > >>> I've added the proposal to the end of that page. In fact, the page > >>> already mentioned that we could generalise fixity levels, but it > >>> didn't > >>> mention fractional or negative values being allowed. > >> > >> Maybe that page could also mention earlier proposals and the > >> solutions > >> without precedence numbers. I prefer the non-numeric approach with > >> rules > >> like "(<) binds more tightly than (&&)", because it says what is > >> intended > >> and it allows to make things unrelated that are unrelated, e.g. infix > >> operators from different libraries. Consequently a precedence > >> relation to > >> general infix operators like ($) and (.) had be defined in each > >> library. > > > > I think that computable real fixity levels are useful, too. A further > > step to complex numbers is not advised because those cannot be > > ordered. > > But ordering of the computable reals is not computable. So it could > cause the compiler to loop during parsing. :) > > -- Lennart Ha! Well, as long as we're being pedantic, surely we wouldn't need any set larger than the rationals (which does have a decidable ordering)? Also, since I'm commenting anyway, I rather like the idea of specifying operator precedences via a partial order. However, I also feel that there needs to be some work done to make sure there aren't gremlins hiding in the details. Has anyone worked out the theory on this? How does associating to the right vs left play into the picture? How does it fit into the parsing technology? -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG From westondan at imageworks.com Tue Nov 7 19:20:52 2006 From: westondan at imageworks.com (Dan Weston) Date: Tue Nov 7 19:20:34 2006 Subject: Fractional/negative fixity? In-Reply-To: <454BF5D3.60705@imageworks.com> References: <002001c6efa4$c8372510$1cf52950@osmet> <22523.213.84.177.94.1161000771.squirrel@webmail.xs4all.nl> <5ce89fb50610160731ja2de0d8l23903e914dcfe8da@mail.gmail.com> <984680831.20061016195414@gmail.com> <454BF5D3.60705@imageworks.com> Message-ID: <455122E4.5010503@imageworks.com> I started this e-mail thread on HaskellCafe instead of HaskellPrime because it was minimal, backwards-compatible, valid Haskell 98 (or very nearly so) and could go (now) into GHC if someone saw fit to put it in. > If you think C++ is not overly complicated, just what is a protected > abstract virtual base pure virtual private destructor, and when was > the last time you needed one? > -- Tom Cargil, C++ Journal The above was not a proposal for Haskell'. > Proposers of new [C++] features should be required to donate a kidney. > That would - Jim [Waldo] pointed out - make people think hard before > proposing, and even people without any sense would propose at most two > extensions. > -- Bjarne Stroustrup, creator of C++ But at the risk of losing a kidney... Here's where I think Haskell 98 got it wrong: "A fixity declaration may appear anywhere that a type signature appears and, like a type signature, declares a property of a particular operator." Like a type signature? A type signature has semantic value, fixity does not. In principle, neither does the name that a lambda abstraction is bound to in top-level definitions, but we are stuck with linkers that know about names. They don't know about fixity. Operator precedence is a purely syntactic device for people (like me) who hate parentheses. Its "scope" is essentially local to the attention span of a human being (i.e. a single module). A preprocessor can parethesize code to eliminate the need for fixity. I hate chasing other modules looking up operator fixity and would rather just specify it myself: What if we could remap fixity on import: -- (MyModule.???) fixity is 4, exported as its default... import MyModule((???)) -- But in this module I prefer 5... -- This fixity is *not* exported! infix 5 ??? Modules that import this module get the default fixity from the source. Summary: fixity at definition is exported, fixity on import is locally remapped but not reexported. > Better is the enemy of the good > -- Voltaire Simple, powerful, minimal. Any takers? Dan Dan Weston wrote: > Here's an idea that (I think) is useful and backwards compatible: > fractional and negative fixity. > > There have been 3 separate times where I've wanted an operator just > above 0 ($) but less than 1 (>>= or >>>), or else just below 0 (like a > superlow $$) > > infix 0.5 ??? > infix -1 $$ > > The only change would be internal to compiler, wouldn't it? Since fixity > is just syntactic sugar, there should be no semantic difficulties. > > Dan > From claus.reinke at talk21.com Tue Nov 7 20:28:49 2006 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Nov 7 20:28:27 2006 Subject: lambda-match vs PMC References: <00ec01c6fb7d$b23e7800$70637ad5@cr3lt> <20061031153917.18376.qmail@schroeder.cas.mcmaster.ca> Message-ID: <015e01c702d5$3f2a39d0$2d5e8351@cr3lt> Hi Wolfram, > > - matchings are not first-class expressions in PMC > > The most important aim of the original PMC was to be a confluent rewriting > system that emulates Haskell pattern matching > .. > So I needed only those operations on matchings that are ``somehow implicit'' > in Haskell pattern matching, and I did not need matching variables etc. understood. sorry if my message suggested that our aims were the same!-) and as your earlier message indicated, one could nevertheless use PMC-inspired constructs to replace Haskell pattern matching with something more modular. btw, while my proposal ticket does link to your email, it doesn't make your alternative proposal explicit - would you mind elaborating your proposal into a separate Haskell' ticket, so that Haskellers and committee could compare the two alternative proposals and their pros & cons (I have been told that my current ticket is already rather long, so it will be better to have two separate, but cross-linked proposal tickets)? > > in spite of the monadic semantics, there are no monads in the type system, > > Just like in ML. > > In fact, just like in pure expression Haskell, which, > from the point of view taken in the MPC2006 paper, > still relies on a lifting monad to add undefined to constructed types. unlike ML, pure expression Haskell only provides an implicit identity monad, where fail raises an exception, so you might want to be explicit about both the expression and the matching monad. which would mean to have these monads reflected in the types. > > A "running commentary" in computational lambda-calculus, > > The main problem I see with that > is that the computational lambda-calculus only sugars away ONE monad, > while, in the MPC paper, we are dealing with TWO monads. interesting, I hadn't thought about that at all - so we Haskellers routinely use several instances of computational lambda-calculus in our code, and while each of those instances could be explained through one such calculus, one calculus (at least in original form) wouldn't be sufficient to cover current practice. > In the lambda-match proposal there is the remark: > > > > -- we use Maybe as the default matching monad, but [] can be fun, too.. the code carefully leaves open which matching monad to choose, but provides some help for common default choices, such as Maybe, Either String, and []. I'm tempted to make (Either String) the default, as it makes it easy to preserve error messages (although I should use a newtype, to avoid instance conflicts). > In PMC (see the MPC paper) > you can change not only the matching monad, > but also the expression monad, for example: > * the lifting monad in standard Haskell > * a Maybe monad in the ``matching failure as exceptions'' view > of the pattern guards paper [Erwig-PeytonJones-2001], > * a list monad in functional-logic programming. we can still do most of that, we just have to be explicit about both monads. as one example, the function "ok", used to define match-failure in do-notation, merges the match monad and the monad of the do-block. another example is "nest", which merges two nested match-monads. using lists of successes should also work, although we don't have logic variables (not unless we use non-standard data structures that allow for them). propagating match failure through exceptions probably suffers from similar problems (need to use monadic rather than pure code). > To me, it looks like the main difference between the lambda-match library > and Tullsen's pattern matching combinators [PADL 2000] is that the > lambda-match library also includes the same ``pointwise lifting'' of the > monadic operations into function types that we use in the MPC paper. that is strange - if you re-read that paper (I did after your email), I think you'll find very little actual overlap with the lambda-match proposal. of course, both start from the same idea, namely to replace pattern matching with "monadic data parsing", but most of the details are rather different. one might also say that Tullsen's work is more ambitious, in making not only match failure and fall-through explicit in a MonadPlus, but also matching itself (through various pattern combinators and syntactic sugar). this is the main reason I did not mention his paper as related work in the proposal - it would only confuse the issues. of course, I have been working on my own versions of first class patterns, based on the lambda-match proposal, and -so far- no further syntax extensions, but that isn't part of the lambda-match proposal. so, lambda-match is a smaller step, both syntactically and semantically, and has been specifically targetted to be suited for Haskell'. it also aims to lay the groundwork for refactoring Haskell pattern matching into something simpler, more compositional, and more expressive (first-class patterns tend to include pattern abstractions and views), after Haskell'. Henrik has pointed out to me that I should make these aims and expected advantages more explicit in my proposal ticket, which I'll try when I next update it (I'm recompiling ghc and libraries to check whether I've missed any syntax conflicts, updates after that..). > Since PMC handles this as a language extension, > it only concerns the semantics, not the type system. (this referred to the lifting of lambda-matches to multiple parameters) I could be wrong, but when you elaborate your own proposal, I think you'll find that both n-ary patterns and the choice of monads will need to be reflected in the type system, as most other properties of interest in Haskell. once we start to distinguish nested match monads, "curried" matches are no longer as easy to use as n-ary matches, so while you may say that this is merely a convenience, I think it is of practical importance. and I've tried to be careful not to use disputed features such as overlapping instances, etc., which led to the pedestrian approach of wrapping matches in Match constructors. this is nothing but a tag to serve as a base-case for any type-level recursions over the parameters of n-ary matches, which therefore are straightforward. > Since the lambda-match proposal does it as a library, it has to > be done inside the language, leading to the type-class artistry > involving declarations like the following: hmm. speaking for myself, I wouldn't be interested in Haskell's design if I didn't want to use it. and if I want to use Haskell, it would seem odd to handle parts of my proposal as language extensions unless Haskell is not expressive enough to handle those parts as libraries. I don't claim that it was straightforward to come up with the type classes (separating Lift and MonadPlus, separating Ex from Lift, and the details of Nest, all took some work), but apart from Nest, the results are not difficult to read or use, and even nest does seem to pose few problems in use. in fact, I put a lot of work into trying to achieve the latter, by reducing the potential for ambiguities (hence the functional dependencies that make Ex look more complicated), and by keeping to the common subset of Hugs/GHC. there are a few cases where things could be easier, eg, kind annotations (scheduled for Haskell', I think) in MatchMonad, or type patterns in class declarations (which would permit me to make the purpose of Ex more obvious -as it is from the type of ex- while still being able to express the functional dependencies). As for all embedded DSLs, I would like to be able to add syntax transformations without changing the Haskell implementation, and I would like to add error message postprocessing the same way (so that I could define DSL- specific syntax and error messages as part of a library), but I have to make do with what Haskell provides.. > > -- extract (with function) from inner match monad > > -- (extraction is lifted over lambda-match parameters; > > -- we cannot express all functional dependencies, > > -- because the inner c could be a function type) > > class Ex a c da dc | da -> a, dc da -> c, da c -> dc {- , dc a c -> da -} where > > ex :: (a -> c) -> da -> dc > > So probably this is a seemingly innocuous extension to do notation > with the potential for some quite spectacular type error messages... we are not talking about an extension to do notation. we are trying to expose a language feature that was previously only available implicitly, via do notation or case. yes, the type errors messages can be formidable, but mostly due to our old enemy, the monomorphism restriction (how an implementation issue that should at best result in a performance warning was ever permitted to enter the language definition, let alone be such an annoying obstacle to *programming with functions*, is beyond me - I do hope this mistake will finally be corrected in Haskell'!!). having said that, I would again point out that I've tried to make the library useable, and while I haven't been entirely successful wrt to ease of use, the type errors do seem to be helpful most of the time (translating missing constraints into the class members helps), and explicit type declarations do not seem to be needed as often as one might fear for this kind of type-class programming (ymmv, of course, so you'll have to try for yourself, and let me know!-). > And, from my point of view, all it achieves over my tentative > PMC proposal is to avoid the two language extensions of > alternatives inside lambda abstractions, and argument supply > (match ... with ...), at the cost of a different language extension. as I mentioned, the monads will need to be explicit in Haskell, which throws into doubt the idea of not having n-ary matches, as well as raising all the problems of how to handle nested monads, and how to reduce ambiguities while still allowing the monads to be chosen as needed. keeping alternatives inside lambda abstractions as anything other than syntactic sugar does not seem to make the main impact of the suggested change as clear as providing for single alternatives plus composition: pattern match failure and fall-through have become programmable, no longer tied to a language construct. my proposal tries to be a compromise, by providing most (all?) features of PMC, as well as foundations for monadic data parsing in general, using syntactic sugar only where absolutely necessary, and library support everywhere else. please do pursue your own proposal through to a prototypical implementation and Haskell' ticket, though - if you can come up with something that does provide the same features as lambda-match, without its difficulties, I'd like to know about it! > (I am also afraid that the ``|'' notation might be dangerous. > To emphasise its character as a ``monadic lambda'', > I would rather consider something like ``\>'', to be typeset $\lambda_{>}$. > ) I chose the '|' because it is already reserved, but cannot be used in that position (*), and because it is already associated with alternatives in data types. the notation needs to be very lightweight, because several lambda-matches will be normally be used together with (+++) and parenthesis, to cover alternative cases, and the '|' does provide a nice visual aid in connecting these separate cases by layout. I'm not completely tied to this syntax, but anything else I've tried so far seems unable to provide similar benefits in practice (including your \>, which neither aligns well, nor suggests the case alternatives - even if you meant \>>; and we are concerned more with MonadPlus than with Monad here) and might steal another operator/keyword (like "proc" for arrows). note also that this is *not* the "monadic lambda" one might expect, because it embeds the body of the lambda-match in a return. one might want to add a lambda-do as well: [| '\>' 'do' |] ==> \ -> do { <- return () ; } or, using lambda-match to define lambda-do: \> do = ok $ (| -> do ) but I decided not to make that part of the present proposal. Thank you for your comments, Claus (*) actually, when recompiling ghc and libraries from scratch, I found one conflict that I hadn't anticipated: if, within the head of a list comprehension, one uses a do-block with more than one statement, and layout instead of explicit {}, then it is not clear whether one sees the last expression in the do-block or the first qualifier of the list comprehension.. (don't laugh, that actually occurs, in Data/Array/Base;-). to avoid complications, and because lambda-matches are meant to be passed as parameters to higher-order functions such as splice and (+++) anyway, I've now changed the patch to require parens around all lambda-matches, and from this safe position I'm looking for places where the parens are not needed (the way the grammar is organised does not always make it easy to differentiate these places). From claus.reinke at talk21.com Tue Nov 7 21:09:59 2006 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Nov 7 21:09:35 2006 Subject: Fractional/negative fixity? References: <7C54402C-E9EF-4B68-BA09-71AF9134D992@augustsson.net> Message-ID: <018601c702da$ff533e00$2d5e8351@cr3lt> by all means, lets have warm fuzzy precedence declarations infix(nearly right) (exp (2*i*pi) + 1) :-) infix(mostly left) (((\x->cos x + i*(sin x)) (2*pi)) + 1) (-: who says that all the fun has to start in the type system?-) we would probably need to refer to hyperreals, in order to introduce infinitesimal differences between real precedence levels? oh, and let us not forget the early Basic's contribution to language design: renum (who could ever to without it!-) ah well, to justify the use of bandwith (and because you should never let your design decisions be influenced by someone making fun of any of the suggestions): - absolute numbers for operator precedence are a hack that reminds me strongly of my Basic times: I used steps of 100 starting with 1000 for line numbers, I used renum to make space for additions or to clean up (was that refactoring?-), but I was still happy to leave all that nonsense behind! - googling for "operator precedence relative" suggests that some parser generators already use something other that absolute preferences - prolog has more precedence levels, as well as simple declarations for pre- and postfix operators (fx, xf) sorry, I just couldn't resist any more;-) claus -- unsagePerformIO: some things are just not wise to do From bulat.ziganshin at gmail.com Wed Nov 8 03:02:37 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 8 03:04:32 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: <5ce89fb50611071425x29a913e2pd400e42a8a86454a@mail.gmail.com> References: <002001c6efa4$c8372510$1cf52950@osmet> <22523.213.84.177.94.1161000771.squirrel@webmail.xs4all.nl> <5ce89fb50610160731ja2de0d8l23903e914dcfe8da@mail.gmail.com> <984680831.20061016195414@gmail.com> <454BF5D3.60705@imageworks.com> <706781845.20061104095938@gmail.com> <1809061187.20061106200717@gmail.com> <5ce89fb50611071425x29a913e2pd400e42a8a86454a@mail.gmail.com> Message-ID: <306908383.20061108110237@gmail.com> Hello Nicolas, Wednesday, November 8, 2006, 1:25:23 AM, you wrote: > prec ?? < $ > over-specification). You want ?? to bind more tightly than does $; > that's exactly what this approach would let you specify. and how then compiler will guess that is relational priority of this operator comparing to '$!' ? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jo at durchholz.org Tue Nov 7 18:08:00 2006 From: jo at durchholz.org (Joachim Durchholz) Date: Wed Nov 8 03:29:37 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: References: <23077.1162923030@calligramme.charmers> Message-ID: David House schrieb: > Also, it provides an infinite space for fixities. I think the problem > 'binds tighter than X but not as tight as Y', where X and Y are only > fixity integer apart is somewhat common, and this would fix it. It > would allow for extensibility into the future, where the operator > space will only become more dense, and maintaining a complete order > with only 10 integers to play will become more and more difficult. > Allowing an infinite amount of operators to come between any two > operators sounds like a solid design decision to me. Yes, but allowing simply to specify some ordering relationship to existing operators is an even more solid one. Fractional fixities are overspecification, and this can hurt in scenarios like this one: Developer A creates an operator with this fixity declaration: infixl 6.25 +* Developer B has this: infixl 6.75 *+ (They don't use 6.5 because each has another operator at 6.5 already.) Now when some developer mixes +* and *+ in the same expression, the compiler will automatically assign a relative priority for the two operators, even though it's not at all clear whether the two operators have any relative precedence - it would be far preferable if the compiler simply declared nonpriority and emitted an error, forcing the programmer to clearly state what priorities he had in mind when writing down the expression. I know the above example is a bit far-fetched. And it's not a really important issue anyway. Regards, Jo From apfelmus at quantentunnel.de Wed Nov 8 03:58:44 2006 From: apfelmus at quantentunnel.de (apfelmus@quantentunnel.de) Date: Wed Nov 8 04:02:04 2006 Subject: Fractional/negative fixity? In-Reply-To: <7C54402C-E9EF-4B68-BA09-71AF9134D992@augustsson.net> References: <7C54402C-E9EF-4B68-BA09-71AF9134D992@augustsson.net> Message-ID: Lennart Augustsson wrote: > > On Nov 7, 2006, at 11:47 , > apfelmus@quantentunnel.de wrote: > >> Henning Thielemann wrote: >>> On Tue, 7 Nov 2006, Simon Marlow wrote: >>> >>>> I'd support fractional and negative fixity. It's a simple change to >>>> make, but we also have to adopt > [...] >> >> I think that computable real fixity levels are useful, too. A further >> step to complex numbers is not advised because those cannot be ordered. > > But ordering of the computable reals is not computable. So it could > cause the compiler to loop during parsing. :) Actually, that's one of the use cases ;) Regards, apfelmus From simonmar at microsoft.com Wed Nov 8 04:55:39 2006 From: simonmar at microsoft.com (Simon Marlow) Date: Wed Nov 8 04:55:25 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: <5ce89fb50611071425i4568d3d7y7167fe1ec7ca9f23@mail.gmail.com> Message-ID: Nicolas Frisby wrote: > Let's remember that if something is broke, it's only _right_ to _fix_ > it. I patiently waited for someone else to make that pun. > > Understanding the language won't be much harder, but understanding > fixity declarations will become a task. Consider: > > infixl -1.7521 -- what and why? > > As the operator space becomes more dense, negative and fractional > fixities are going to become more obfuscated. The negative and > fractional fixities will satisfy a number purposes well, but they will > also be abused and lead to confusion. > > This smells like a wart growing on a wart to me. All these are valid points. However, given that we can't completely redesign, implement and test a new fixity system in time for Haskell', it makes sense to make a simple change that unambiguously improves the current system, and is no more difficult to implement (in fact, I bet it adds zero lines of code to the compiler). Cheers, Simon > Nick > > On 11/7/06, David House wrote: >> On 07/11/06, Jon Fairbairn wrote: >>> I must say though, that I don't like the reasoning that we >>> can put in fractional fixities because it's a small >>> change. The way to hell is through a series of small >>> steps. If using integers to express fixities is a bit of a >>> hack, switching to rational numbers is a hack on top of a >>> hack. >> >> Well, It's a _conceptually_ simple idea, one that doesn't make >> understanding the language much harder. >> >> Also, it provides an infinite space for fixities. I think the problem >> 'binds tighter than X but not as tight as Y', where X and Y are only >> fixity integer apart is somewhat common, and this would fix it. It >> would allow for extensibility into the future, where the operator >> space will only become more dense, and maintaining a complete order >> with only 10 integers to play will become more and more difficult. >> Allowing an infinite amount of operators to come between any two >> operators sounds like a solid design decision to me. >> >> -- >> -David House, dmhouse@gmail.com >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe From haskell at henning-thielemann.de Wed Nov 8 08:36:22 2006 From: haskell at henning-thielemann.de (Henning Thielemann) Date: Wed Nov 8 08:36:27 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: <306908383.20061108110237@gmail.com> References: <002001c6efa4$c8372510$1cf52950@osmet> <22523.213.84.177.94.1161000771.squirrel@webmail.xs4all.nl> <5ce89fb50610160731ja2de0d8l23903e914dcfe8da@mail.gmail.com> <984680831.20061016195414@gmail.com> <454BF5D3.60705@imageworks.com> <706781845.20061104095938@gmail.com> <1809061187.20061106200717@gmail.com> <5ce89fb50611071425x29a913e2pd400e42a8a86454a@mail.gmail.com> <306908383.20061108110237@gmail.com> Message-ID: On Wed, 8 Nov 2006, Bulat Ziganshin wrote: > Hello Nicolas, > > Wednesday, November 8, 2006, 1:25:23 AM, you wrote: > > > prec ?? < $ > > over-specification). You want ?? to bind more tightly than does $; > > that's exactly what this approach would let you specify. > > and how then compiler will guess that is relational priority of this > operator comparing to '$!' ? :) (What might the smiley mean?) It could not guess it, and this is good! However, if in the Prelude it is defined, that ($) and ($!) have the same precedence, then the compiler could derive automatically that prec ?? < $!. From haskell at henning-thielemann.de Wed Nov 8 08:37:10 2006 From: haskell at henning-thielemann.de (Henning Thielemann) Date: Wed Nov 8 08:38:10 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: References: <23077.1162923030@calligramme.charmers> Message-ID: On Tue, 7 Nov 2006, David House wrote: > On 07/11/06, Jon Fairbairn wrote: > > I must say though, that I don't like the reasoning that we > > can put in fractional fixities because it's a small > > change. The way to hell is through a series of small > > steps. If using integers to express fixities is a bit of a > > hack, switching to rational numbers is a hack on top of a > > hack. > > Well, It's a _conceptually_ simple idea, one that doesn't make > understanding the language much harder. > > Also, it provides an infinite space for fixities. I think the problem > 'binds tighter than X but not as tight as Y', where X and Y are only > fixity integer apart is somewhat common, and this would fix it. In school we learnt "dot operations (multiplication, division) bind more tightly than dash operations (addition, subtraction)". I imagine we would have learnt "dot operations have precedence 7, dash operations have precedence 6". :-) From jo at durchholz.org Wed Nov 8 08:39:13 2006 From: jo at durchholz.org (Joachim Durchholz) Date: Wed Nov 8 08:38:56 2006 Subject: [Haskell-cafe] Fractional/negative fixity? In-Reply-To: <306908383.20061108110237@gmail.com> References: <002001c6efa4$c8372510$1cf52950@osmet> <22523.213.84.177.94.1161000771.squirrel@webmail.xs4all.nl> <5ce89fb50610160731ja2de0d8l23903e914dcfe8da@mail.gmail.com> <984680831.20061016195414@gmail.com> <454BF5D3.60705@imageworks.com> <706781845.20061104095938@gmail.com> <1809061187.20061106200717@gmail.com> <5ce89fb50611071425x29a913e2pd400e42a8a86454a@mail.gmail.com> <306908383.20061108110237@gmail.com> Message-ID: Bulat Ziganshin schrieb: > Hello Nicolas, > > Wednesday, November 8, 2006, 1:25:23 AM, you wrote: > >> prec ?? < $ >> over-specification). You want ?? to bind more tightly than does $; >> that's exactly what this approach would let you specify. > > and how then compiler will guess that is relational priority of this > operator comparing to '$!' ? :) For an expression like a ?? b $! c it would have to emit an error message, since it isn't clear whether the programmer meant (a ?? b) $! c or a ?? (b $! c) In fact that wouldn't be clear to a human reader, either, so it's actually a Good Thing that the programmer must explicitly disambiguate the expression! Dan Weston's proposal (let local fixity declarations augment and/or override those imported from the module that defines an operator) would eliminate the pain in code that makes heavy use of both operators. Fractional priorities, on the other hand, would silently resolve this kind of ambiguity. What makes this troublesome is that programmers and maintainers won't always assume the same resolution as the one that the compiler chose; such things are one of the more powerful ingredients for the occasional debugging nightmare. This lesson has already been learned several times now (I know of PL/I and C++, which both have had their share of problems due to overly ambitious defaulting mechanisms). No need to repeat that. Regards, Jo From jon.fairbairn at cl.cam.ac.uk Wed Nov 8 11:11:02 2006 From: jon.fairbairn at cl.cam.ac.uk (=?utf-8?b?SsOzbiBGYWlyYmFpcm4=?=) Date: Wed Nov 8 11:14:57 2006 Subject: Fractional/negative fixity? References: <5ce89fb50611071425i4568d3d7y7167fe1ec7ca9f23@mail.gmail.com> Message-ID: Simon Marlow writes: > Nicolas Frisby wrote: > > Let's remember that if something is broke, it's only _right_ to _fix_ > > it. I patiently waited for someone else to make that pun. > > > > Understanding the language won't be much harder, but understanding > > fixity declarations will become a task. Consider: > > > > infixl -1.7521 -- what and why? > > > > As the operator space becomes more dense, negative and fractional > > fixities are going to become more obfuscated. The negative and > > fractional fixities will satisfy a number purposes well, but they will > > also be abused and lead to confusion. > > > > This smells like a wart growing on a wart to me. > > All these are valid points. However, given that we can't > completely redesign, implement and test a new fixity > system in time for Haskell', ...the correct thing to do is to leave it alone, rather than make a change that addresses only one of the problems. > it makes sense to make a simple change that unambiguously > improves the current system, I dispute that. It does make it possible to introduce a new operator between two others, but on its own, that strikes me as as likely to be a new problem as an improvement because of the difficulty of remembering numeric precedences. It's bad enough with the present number, let alone a countable infinity of them. The biggest flaw in the present system (and something I wanted to address in my original proposal way back when) is that there is no way to state that there is /no/ precedence relationship between two operators. It would be far better to have the compiler give an error message saying that an expression needs some parentheses than have it choose the wrong parse. The next smaller flaw is that numeric precedences are a poor match for the way we think. I can easily remember that (*) binds more tightly than (+), or that (+) beats (:) (though the latter is slightly less obviously correct), but I don't remember the numbers so when I want to define something new that has a similar precedence to (*) (some new kind of multiplication), I have to look it up, which is tedious. Wanting to insert an operator between two others comes lower in importance even than that, because in many cases giving it the same precedence as something and appropriate associativity gets you most of the way there. It bites because you can't say you want an error if you use it next to something else without parentheses. Let me throw out a couple of possibilities differing only in syntax (one of my fears is that if we get fractional fixities the other problems will be forgotten, so a real improvement will never be discussed). I don't expect either of them to go into Haskell', but putting them forward might encourage further discussion and discourage introduction of something "temporary" that will stay with us forever. Syntax 1, based on Phil Wadler's improvement of my old proposal. The precedence relation is a preorder. infix {ops_1; ops_2; ...; ops_n} (where each ops is a collection of operators optionally annotated with L or R) would mean that each operator in ops_i binds more tightly than all the operators in ops_j for j>i. (and we require ops_i `intersect` ops_j = empty_set for i/=j) Layout rule applies for {;...}. An op can be a varsym or a backquoted varid. It says nothing about the relationship between the those operators and operators not mentioned, except by virtue of transitivity. So infix R ^ L * / L + - would replicate the current relationships between those arithmetic operators. An additional declaration infix + R : says that (+) binds more tightly than (:) and by transitivity, so do (^ * and /). The associativity label obviously has to be the same for all occurrences of an operator in scope, so omitting it just says that it's specified elsewhere. infix * R @+ @- + says that (@+) and (@-) fall between (*) and (-), and that (a @+ b @- c) parses as (a @+ (b@-c)) but infix * R @@ says that (a * b @@ c @@ d) parses as ((a*b) @@ (c@@d)) but leaves (a + b @@ c) undefined (a compile time error) unless another declaration specifies it elsewhere. And infix R @@ @@@ says nothing about the relationship between @@ or @@@ and other operators, but indicates that they associate to the right individually and together. The alternative syntax is exemplified thus: infix L + - (L * / (R ^)) The precedence increases the more deeply you go into the parentheses. Arguably this is more suggestive and avoids the possibility of reading precedences as increasing down the page (danger of endianism argument cropping up there!), but may be harder to read. With both syntaxes there's no reason to reserve L and R, since the context disambiguates. For exports (imports) you pass the graph of the relation with the unexported (unimported) operators omitted. > and is no more difficult to implement (in fact, I bet it > adds zero lines of code to the compiler). If ease of implementation had been a criterion, we'd never have had Haskell at all! I don't think the above suggestion would be hard to implement -- for someone who knows the internals of a compiler, anyway. J?n From jmaessen at alum.mit.edu Wed Nov 8 21:02:13 2006 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Wed Nov 8 21:01:52 2006 Subject: Fractional/negative fixity? In-Reply-To: <200611071749.22218.robdockins@fastmail.fm> References: <7C54402C-E9EF-4B68-BA09-71AF9134D992@augustsson.net> <200611071749.22218.robdockins@fastmail.fm> Message-ID: On Nov 7, 2006, at 5:49 PM, Robert Dockins wrote: [On operator precedence] > > > Ha! Well, as long as we're being pedantic, surely we wouldn't need > any set > larger than the rationals (which does have a decidable ordering)? > > Also, since I'm commenting anyway, I rather like the idea of > specifying > operator precedences via a partial order. However, I also feel > that there > needs to be some work done to make sure there aren't gremlins > hiding in the > details. Has anyone worked out the theory on this? How does > associating to > the right vs left play into the picture? How does it fit into the > parsing > technology? Actually, we *do* use a DAG on operator precedence in the Fortress programming language (my day job). Our goal is to require parentheses when it is not blatantly obvious what is going on (eg because we're using operators from two libraries written in isolation). We can only use operators together in an expression without parentheses if there is an edge between them in the graph. Graph nodes are sets of operators with the "same" precedence (eg addition and subtraction). Among other things this means that if ++ has higher precedence than ==, and == has higher precedence than &&, we can't necessarily mix ++ and && in the same expression without parentheses. That said, this would be a pretty big change for Haskell, and would break existing code unless you somehow wired in the transitive closure of all the existing operators. As another message in this discussion (from Simon M?) mentioned, you might want to be able to specify the relationship between operators imported from different modules, because you *do* know that a well-known relationship exists. -Jan-Willem Maessen > > > > -- > Rob Dockins > > Talk softly and drive a Sherman tank. > Laugh hard, it's a long way to the bank. > -- TMBG > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2425 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20061108/de99e828/smime-0001.bin From robdockins at fastmail.fm Wed Nov 8 21:12:01 2006 From: robdockins at fastmail.fm (Robert Dockins) Date: Wed Nov 8 21:11:34 2006 Subject: Fractional/negative fixity? In-Reply-To: References: <200611071749.22218.robdockins@fastmail.fm> Message-ID: <200611082112.01908.robdockins@fastmail.fm> On Wednesday 08 November 2006 21:02, Jan-Willem Maessen wrote: > On Nov 7, 2006, at 5:49 PM, Robert Dockins wrote: > [On operator precedence] > > > Ha! Well, as long as we're being pedantic, surely we wouldn't need > > any set > > larger than the rationals (which does have a decidable ordering)? > > > > Also, since I'm commenting anyway, I rather like the idea of > > specifying > > operator precedences via a partial order. However, I also feel > > that there > > needs to be some work done to make sure there aren't gremlins > > hiding in the > > details. Has anyone worked out the theory on this? How does > > associating to > > the right vs left play into the picture? How does it fit into the > > parsing > > technology? > > Actually, we *do* use a DAG on operator precedence in the Fortress > programming language (my day job). Huh... I didn't know that. Are there any good papers/documentation on the system you use? > Our goal is to require > parentheses when it is not blatantly obvious what is going on (eg > because we're using operators from two libraries written in > isolation). We can only use operators together in an expression > without parentheses if there is an edge between them in the graph. > Graph nodes are sets of operators with the "same" precedence (eg > addition and subtraction). Among other things this means that if ++ > has higher precedence than ==, and == has higher precedence than &&, > we can't necessarily mix ++ and && in the same expression without > parentheses. > That said, this would be a pretty big change for Haskell, and would > break existing code unless you somehow wired in the transitive > closure of all the existing operators. As another message in this > discussion (from Simon M?) mentioned, you might want to be able to > specify the relationship between operators imported from different > modules, because you *do* know that a well-known relationship exists. So the Fortress system doesn't use transitivity automaticly? And what about operator parsing associativity? Do you require that all operators assigned to the same node in the DAG have the same associativity? > -Jan-Willem Maessen -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG From benjamin.franksen at bessy.de Thu Nov 9 13:25:36 2006 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Thu Nov 9 13:29:47 2006 Subject: Fractional/negative fixity? References: <5ce89fb50611071425i4568d3d7y7167fe1ec7ca9f23@mail.gmail.com> Message-ID: J?n Fairbairn wrote: > Syntax 1, based on Phil Wadler's improvement of my old > proposal. The precedence relation is a preorder.[...] > > infix {ops_1; ops_2; ...; ops_n} > > The alternative syntax is exemplified thus: > > infix L + - (L * / (R ^)) > > [...] I think both ways (I like the second one more) are a lot better than precedence numbers, whether they be fractional or integral. Let us add compiler/interpreter support for querying known precedence/fixity relations and it's (almost) perfect. Cheers Ben From Benjamin.Rudiak-Gould at cl.cam.ac.uk Fri Nov 10 12:11:58 2006 From: Benjamin.Rudiak-Gould at cl.cam.ac.uk (Ben Rudiak-Gould) Date: Fri Nov 10 12:12:39 2006 Subject: Fractional/negative fixity? In-Reply-To: References: Message-ID: apfelmus@quantentunnel.de wrote: >I think that computable real fixity levels are useful, too. Only finitely many operators can be declared in a given Haskell program. Thus the strongest property you need in your set of precedence levels is that given arbitrary finite sets of precedences A and B, with no precedence in A being higher than any precedence in B, there should exist a precedence higher than any in A and lower than any in B. The rationals already satisfy this property, so there's no need for anything bigger (in the sense of being a superset). The rationals/reals with terminating decimal expansions also satisfy this property. The integers don't, of course. Thus there's a benefit to extending Haskell with fractional fixities, but no additional benefit to using any larger totally ordered set. -- Ben From Benjamin.Rudiak-Gould at cl.cam.ac.uk Fri Nov 10 12:13:11 2006 From: Benjamin.Rudiak-Gould at cl.cam.ac.uk (Ben Rudiak-Gould) Date: Fri Nov 10 12:21:45 2006 Subject: Fractional/negative fixity? In-Reply-To: <706781845.20061104095938@gmail.com> References: <002001c6efa4$c8372510$1cf52950@osmet> <22523.213.84.177.94.1161000771.squirrel@webmail.xs4all.nl> <5ce89fb50610160731ja2de0d8l23903e914dcfe8da@mail.gmail.com> <984680831.20061016195414@gmail.com> <454BF5D3.60705@imageworks.com> <706781845.20061104095938@gmail.com> Message-ID: I'm surprised that no one has mentioned showsPrec and readsPrec. Anything more complicated than negative fixities would require their interfaces to be changed. -- Ben From haskell at henning-thielemann.de Fri Nov 10 12:59:37 2006 From: haskell at henning-thielemann.de (Henning Thielemann) Date: Fri Nov 10 12:59:33 2006 Subject: [Haskell-cafe] Re: Fractional/negative fixity? In-Reply-To: References: <002001c6efa4$c8372510$1cf52950@osmet> <22523.213.84.177.94.1161000771.squirrel@webmail.xs4all.nl> <5ce89fb50610160731ja2de0d8l23903e914dcfe8da@mail.gmail.com> <984680831.20061016195414@gmail.com> <454BF5D3.60705@imageworks.com> <706781845.20061104095938@gmail.com> Message-ID: On Fri, 10 Nov 2006, Ben Rudiak-Gould wrote: > I'm surprised that no one has mentioned showsPrec and readsPrec. Anything more > complicated than negative fixities would require their interfaces to be > changed. Very true. Does it mean, that the Functional Graph Library has to become part of the Prelude? From lennart at augustsson.net Fri Nov 10 22:49:15 2006 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Nov 10 22:48:53 2006 Subject: String literals Message-ID: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> I think it's time that string literals got overloaded just like numeric literals. There are several reasons for this. One reason is the new fast string libraries. They are great, but string literals don't work; you need to pack them first. Another reason is the increasing use of Haskell for DSELs. In a DSEL you might want string literals to have a different type than the ordinary String. I have not implemented anything yet, but I would like to see something along the lines of the following: class IsString s where fromString :: String -> s instance IsString String where fromString = id The instance declaration is not allowed in Haskell-98, but it can be rewritten as class IsChar c where -- Make this class local to it's defining module fromChar :: Char -> c instance IsChar Char where fromChar = id instance (IsChar c) => IsString [c] where fromString = map fromChar And, like with numeric literals, any string literal will then have an implicit fromString insert to make the right conversion. My guess is that the defaulting mechanism needs to be extended to default to the String type as well, or we'll get some ambiguous expressions. Any thoughts? -- Lennart From john at repetae.net Fri Nov 10 23:27:36 2006 From: john at repetae.net (John Meacham) Date: Fri Nov 10 23:26:35 2006 Subject: String literals In-Reply-To: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> References: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> Message-ID: <20061111042736.GA32545@momenergy.repetae.net> On Fri, Nov 10, 2006 at 10:49:15PM -0500, Lennart Augustsson wrote: > Any thoughts? what about pattern matching? > class IsString s where > fromString :: String -> s > class IsString s => EqString s where > eqString :: String -> s -> Bool another posibillity would be for pattern matching to add an Eq constraint along with a IsString one on any pattern match of a string constant. I would very strongly prefer not to make Eq a superclass of IsString in any case. Just have a separate EqString class or pass around the Eq and IsString contexts separately. John -- John Meacham - ?repetae.net?john? From dons at cse.unsw.edu.au Fri Nov 10 23:33:48 2006 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Sat Nov 11 00:08:28 2006 Subject: String literals In-Reply-To: <20061111042736.GA32545@momenergy.repetae.net> References: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> <20061111042736.GA32545@momenergy.repetae.net> Message-ID: <20061111043348.GA32251@cse.unsw.EDU.AU> john: > On Fri, Nov 10, 2006 at 10:49:15PM -0500, Lennart Augustsson wrote: > > Any thoughts? > > what about pattern matching? Yes, pattern matching is the issue that occurs to me too. While string literals :: ByteString would be nice (and other magic encoded in string literals, I guess), what is the story for pattern matching on strings based on non-inductive types like arrays? -- Don From lennart at augustsson.net Sat Nov 11 00:16:08 2006 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat Nov 11 00:15:56 2006 Subject: String literals In-Reply-To: <20061111043348.GA32251@cse.unsw.EDU.AU> References: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> <20061111042736.GA32545@momenergy.repetae.net> <20061111043348.GA32251@cse.unsw.EDU.AU> Message-ID: <43F1091B-324D-4837-8E4F-BA223FDB01A1@augustsson.net> Pattern matching would work like pattern matching with numeric literals does. You'll have to use equality comparison. To pattern match the string type would have to be in Eq as well. -- Lennart On Nov 10, 2006, at 23:33 , Donald Bruce Stewart wrote: > john: >> On Fri, Nov 10, 2006 at 10:49:15PM -0500, Lennart Augustsson wrote: >>> Any thoughts? >> >> what about pattern matching? > > Yes, pattern matching is the issue that occurs to me too. > While string literals :: ByteString would be nice (and other magic > encoded in string literals, I guess), what is the story for pattern > matching on strings based on non-inductive types like arrays? > > -- Don > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From bulat.ziganshin at gmail.com Sat Nov 11 04:08:00 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 11 04:23:43 2006 Subject: String literals In-Reply-To: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> References: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> Message-ID: <207210037.20061111120800@gmail.com> Hello Lennart, Saturday, November 11, 2006, 6:49:15 AM, you wrote: > class IsString s where > fromString :: String -> s > My guess is that the defaulting mechanism needs to be extended to > default to the String type as well, imho, it is MUST BE. this will allow to became ByteString and any other alternative string implementation a first-class Haskell citizen btw, String class is regularly debated and even implemented in fps-soc project where it includes a lot of common string functionality. just a head of this class: class (Eq s) => Stringable s where -- Introducing and eliminating -- | The empty string. empty :: s -- | Create a string containing a single 'Char'. singleton :: Char -> s -- | Convert a string into a standard Haskell 'String'. toList :: s -> [Char] toList = foldr (:) [] ........................ this may be disputed as part of library reorganization -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Sat Nov 11 04:19:54 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 11 04:23:45 2006 Subject: String literals In-Reply-To: <20061111043348.GA32251@cse.unsw.EDU.AU> References: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> <20061111042736.GA32545@momenergy.repetae.net> <20061111043348.GA32251@cse.unsw.EDU.AU> Message-ID: <731200081.20061111121954@gmail.com> Hello Donald, Saturday, November 11, 2006, 7:33:48 AM, you wrote: > Yes, pattern matching is the issue that occurs to me too. > While string literals :: ByteString would be nice (and other magic > encoded in string literals, I guess), what is the story for pattern > matching on strings based on non-inductive types like arrays? it's my day :) i'm regularly propose to pass list syntax to the special class which should define methods for building and analyzing data in head/tail way: class ListLike ce e | ce->e where -- Construction empty :: ce cons :: c -> ce -> ce -- Analyzing null :: ce -> Bool head :: ce -> e tail :: ce -> ce and then the following definition: trim (' ':xs) = trim xs trim xs = xs would imply the following type constraints: trim :: (ListLike ce Char, Eq Char) => ce -> ce -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From claus.reinke at talk21.com Sat Nov 11 11:22:37 2006 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat Nov 11 11:22:01 2006 Subject: lambda-match example - from parser combinators to grammar combinators References: <009101c6f751$a6b577c0$ad858351@cr3lt> <01e401c6fc82$82684f60$b93d7ad5@cr3lt> Message-ID: <00f001c705ad$9b65a740$3f6f8351@cr3lt> Some of you have asked me whether I could provide more convincing examples for lambda-match, or whether the shortcomings of Haskell addressed in this proposal will be of practical relevance to the typical seasoned Haskeller without specific interests in language design. There are of course the various themes of views, pattern abstractions, and first-class patterns, which could be built on top of lambda-match, but I'd like to follow a slightly different angle first, inspired by an interesting off-list remark in response to the lambda-match proposal: I do consider myself a fairly seasoned Haskell programmer, and to be honest, I have to admit that I rarely if ever have missed composable pattern matching at the source level. Of course, that could be because I subconsciously just work around the problem, being used to Haskell as it is. I do indeed believe that the problem of non-compositional pattern match has been around in Haskell for so long that many of today's Haskellers are no longer even aware of the issue, and of how much it affects them. So, here is one slightly less trivial example of using lambda-match, which happens to stand for a large group of possible applications, and for one particular area where the lack of compositional patterns has influenced the Haskeller's world-view: Ever since I took up Haskell, I have wondered why Haskellers tend to specify their grammars not just twice (abstract + concrete), but thrice (abstract + parsing + unparsing). The majority of seasoned Haskellers seems to accept that there must be parsers+pretty-printers, read+show, serialize+de-serialize, etc., and that changing concrete syntax must involve making fixes in two separate bits of code, often even following two separate coding patterns. But if one looks at so-called parser combinators, there is very little in them that is parser-specific - usually only the literal parsers determine that we are talking about parsing, whereas the majority of combinators can be used just as well for other syntax-directed tasks. Still, people tend not to reuse their combinator-based grammars for anything but parsing. I submit that one of the main reasons for this is that Haskellers have come to accept that they can construct, but not deconstruct algebraic types in a compositional way (hence the use of parser combinators for converting Strings into algebraic data types, and the use of more pedestrian means for showing the latter as Strings; pretty-printing libraries do at least use combinators, but do not reuse the grammars specified through parser combinators). Please have a look at the example (which needs both syntax patch and library from the proposal ticket, if you actually want to run it *, but the ideas should be reasonably obvious even without): it specifies a concrete and abstract syntax for lambda calculus, and the relationships between the two levels of syntax, using an algebraic data type for the abstract syntax, and a grammar built with monadic combinators for the rest. fairly standard, but for the following: language and library support for monadic data parsing via lambda-match allow us to mix data parsing and string parsing in the same monadic framework, using the same "grammar combinators" to specify the concrete syntax and its relation to the abstract syntax just once, in one piece of code. we can use that single grammar for parsing, unparsing, or indeed, for mixtures of both (see the examples). A long time ago, I used something like this (then sadly without language support) to implement a syntax-oriented editor, with parsing and formatted printing from a single grammar. Although I haven't worked this out, I suspect that the technique would also apply to protocol-based applications: instead of writing client and server separately (and then trying to prove that they fit together and follow two sides of the same protocol), one might try to write a single grammar for the protocol between them, toggling mode at the appropriate points, and then client and server would simply be two instances/uses of the same grammar in its two start modes (so the server would generate prompts, parse requests, and generate responses, and the client would expect prompts, generate requests, and parse responses). have fun;-) claus * I have submitted the syntax patch for the GHC head repository, * but GHC HQ are reluctant to apply the patch as long as there * is no obvious general interest (someone else but myself, and * not just in private email to myself;-) in using these features. If * you want to investigate lambda-match in GHC, to make up your * mind about whether or not you like the proposal (at the moment, * we're only talking about the daily snapshots of GHC head, not * about long-term support in GHC, let alone inclusion in Haskell'!), * please let yourself be heard! (more adventurous souls can of course apply the patch from the ticket themselves and recompile GHC;-) I have also updated the proposal ticket with a list of motivation bullet-points for lambda-match: http://hackage.haskell.org/trac/haskell-prime/ticket/114 -------------- next part -------------- A non-text attachment was scrubbed... Name: PunP.hs Type: application/octet-stream Size: 3513 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20061111/02998e0e/PunP.obj From bulat.ziganshin at gmail.com Sun Nov 12 18:28:09 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 12 18:50:48 2006 Subject: Annotation system for Haskell Message-ID: <1692020927.20061113022809@gmail.com> Both Java and C# provides annotations that can be used to pass some additional information about code to around-language tools and queried at program runtime via Reflection API: [AuthorAttribute ("Ben Albahari")] class A { [Localizable(true)] public String Text { get {return text; } ... } } in the last poll for Haskell', it was widely noted that some form of attribute (annotation) system for Haskell will be great, although there is no any design yet. i think that i've found rather good one: 1. Attributes must be available at run-time via some library that uses RTS-provided information, at compile-time for TemplateHaskell-like language extensions using appropriate APIs, and for 3rd-party tools like DrIFT using database generated by compiler during compilation process 2. Attributes are linked to _entities_, which includes packages, modules, values, types, classes and instances. Entity can be found by specifying its _path_, say "package Foo -> module M -> class Eq -> value (==)". Of course this path on practice may be written just as "Foo:M:Eq:(==)". Because almost any module imports class Eq from Prelude, we can find the very same entity by a number of various paths, including "Base:Data.List:Eq:(==)" and "stm:Control.Concurrent.STM:Eq:(==)". If module A imports module B qualified, then path may look as "Foo:A:B.f". Of course, we will also need some way to get "current" package/module name 3. It should be also possible to _enumerate_ all sub-entities of given entity or all attributes of entity. I think that we should provide both ability to enumerate all entities _available_ inside module and to enumerate all entities _defined_ in the module 4. Each entity has a list of named attributes. We should provide a way to define new attribute name together with its "sort". Using Haskell type to define this "sort" looks like a natural solution: [Declare Author :: String] [Declare Deriving :: [String]] [Author "Bulat"] data T = X | Y [^Deriving ["Eq","Ord"]] 5. Then, using a path to entity and attribute's name, one can easily get attribute value: getAttr "Foo:M:T" "Author". Simplest solution is just to return String representation of attribute value, leaving to programmer the job of using "read" to convert this String value into right type I don't consider this in deeper details, but some form of dynamic typing (Typeable/Data class) can also be used. Ideal solution will be to allow programmer to define his own datatypes of attributes which then may be used _both_ instead of [Declare] statements above and as result type for getAttr function, say: data MyAttrs = Author String | Deriving [String] deriving (Attribute) [Author "Bulat"] data T = X | Y [^Deriving ["Eq","Ord"]] use_reflection_api = case getAttr (CurrentPackage ++ ":" ++ CurrentModule ++ ":T") "Author" of Author str -> str In this scenario, standard (predefined) attributes may be just imported as part of Prelude, and user-defined attributes may be defined in current or imported module But while this way greatly simplifies and makes almost type-safe the most common case - using of well-known attributes, it should also be possible to keep 2 features: 1) ability to declare new attribute types inside a module and use these new attributes immediately inside the same module 2) ability to enumerate and get values of attributes of unknown types. imagine, for example, attribute browsing tool 6. Returning to compiler/3rd-party tools interaction, we can now say that attributes database for each module should be build during compilation of this module. It is something very like .hi file, one per each module compiled, but for external consumption. It looks natural to use XML format here, so the entity path will be translated into the path of appropriate xml file and xml path inside the file. Information in this file don't limited to the attributes provided by module writers, it can also contains any information compiler may provide (types of values, code metrics, options used when compiling module) and 3rd-party tools can also add their own information here it seems that also some indexing/xml merging tools should arise at some moment to speed up access to this database, especially to databases of installed packages -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Mon Nov 13 06:29:11 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Nov 13 07:20:25 2006 Subject: Annotation system for Haskell In-Reply-To: <1692020927.20061113022809@gmail.com> References: <1692020927.20061113022809@gmail.com> Message-ID: <64161472.20061113142911@gmail.com> Hello Bulat, Monday, November 13, 2006, 2:28:09 AM, you wrote: > in the last poll for Haskell', it was widely noted that some form of > attribute (annotation) system for Haskell will be great, although > there is no any design yet. i think that i've found rather good one: i was sleepy and forgot to add some more information: this design is obviously grown from HadDoc ideas. HadDoc adds documentation comments to the same entities - values, types and classes, so one of things we can do is to treat haddoc comments as one sort of attributes, say Documentation :: String this implies that haddoc front-end should be changed to generate xml files that will include this Documentation attributes and haddoc backend should parse these xml files to generate html/tex/... documentation files another haddoc detail that we should reuse is using comments to hold all annotations, in order to make annotated program compilable by old compilers and the third detail is to simplify annotations syntax by allowing to omit "" for String annotations, [] for annotation having type [a] and so on. So, annotation value should be read by some smart variation of "read" function. then, the whole example may look like: -- |Great function f = 1 -- *Documentation: Great function g = 1 -- Two above annotations are equivalent, "-- |" is a legacy shortcut for the full syntax of "-- *Documentation: " -- *Author: Bulat data NewAnnotationType = TextAnnotation String | IntAnnotation Int | PrioritiesList [Int] | Deriving [String] deriving Annotation -- *TextAnnotation: It works! -- *IntAnnotation: 31415 -- *PrioritiesList: 1,2,3,4,5 data T = X | Y -- *^Deriving: DeepSeq, Binary, XMLizable -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lennart at augustsson.net Mon Nov 13 08:22:34 2006 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Nov 13 08:22:09 2006 Subject: String literals In-Reply-To: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> References: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> Message-ID: <256FCB1C-64D2-4DAC-A69A-FF87AD681347@augustsson.net> To follow up on my own post. I implemented the overloaded strings last night and it seems to work pretty well. I've not done anything about defaulting yet. I don't know how much of a problem this will be in practice. On Nov 10, 2006, at 22:49 , Lennart Augustsson wrote: > I think it's time that string literals got overloaded just like > numeric literals. There are several reasons for this. One reason > is the new fast string libraries. They are great, but string > literals don't work; you need to pack them first. Another reason > is the increasing use of Haskell for DSELs. In a DSEL you might > want string literals to have a different type than the ordinary > String. > > I have not implemented anything yet, but I would like to see > something along the lines of the following: > > class IsString s where > fromString :: String -> s > instance IsString String where > fromString = id > > The instance declaration is not allowed in Haskell-98, but it can > be rewritten as > class IsChar c where -- Make this class local to it's defining module > fromChar :: Char -> c > instance IsChar Char where > fromChar = id > instance (IsChar c) => IsString [c] where > fromString = map fromChar > > And, like with numeric literals, any string literal will then have > an implicit fromString insert to make the right conversion. > > My guess is that the defaulting mechanism needs to be extended to > default to the String type as well, or we'll get some ambiguous > expressions. > > Any thoughts? > > -- Lennart > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From apfelmus at quantentunnel.de Mon Nov 13 10:40:15 2006 From: apfelmus at quantentunnel.de (apfelmus@quantentunnel.de) Date: Mon Nov 13 10:44:04 2006 Subject: String literals In-Reply-To: <43F1091B-324D-4837-8E4F-BA223FDB01A1@augustsson.net> References: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> <20061111042736.GA32545@momenergy.repetae.net> <20061111043348.GA32251@cse.unsw.EDU.AU> <43F1091B-324D-4837-8E4F-BA223FDB01A1@augustsson.net> Message-ID: >>> >>> what about pattern matching? >> >> Yes, pattern matching is the issue that occurs to me too. >> While string literals :: ByteString would be nice (and other magic >> encoded in string literals, I guess), what is the story for pattern >> matching on strings based on non-inductive types like arrays? > > Pattern matching would work like pattern matching with numeric > literals does. You'll have to use equality comparison. To pattern > match the string type would have to be in Eq as well. Mh, that's a showcase for Views. Something like view IsString a => String of a where ... That is, one has an already existing type that serves as a view for another one. Perhaps, Views should be more like class declarations with asssociated constructors class IsString a where [] :: a (:) :: Char -> a -> a Very similar to the new (G)ADT syntax and some kind of polymorphic variants with "virtual" constructors, isn't it? Anyway, the pattern guard approach would be to *not* allow string literals in pattern matches: patty bs | "pattern string" == bs = flip id id . flip id I think it's very unfair not to have general Views when now both polymorphic integers and string literals are to be allowed in pattern matching. Regards, apfelmus From simonpj at microsoft.com Mon Nov 13 12:27:08 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 13 12:26:24 2006 Subject: String literals In-Reply-To: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> References: <95C1163D-CCA4-4634-AD84-5BB92008ABE5@augustsson.net> Message-ID: In my experience I've seen more requests for overloaded *Boolean* literals than strings. In a Fran context, for example. Simon | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Lennart Augustsson | Sent: 11 November 2006 03:49 | To: Haskell Prime | Subject: String literals | | I think it's time that string literals got overloaded just like | numeric literals. There are several reasons for this. One reason is | the new fast string libraries. They are great, but string literals | don't work; you need to pack them first. Another reason is the | increasing use of Haskell for DSELs. In a DSEL you might want string | literals to have a different type than the ordinary String. | | I have not implemented anything yet, but I would like to see | something along the lines of the following: | | class IsString s where | fromString :: String -> s | instance IsString String where | fromString = id | | The instance declaration is not allowed in Haskell-98, but it can be | rewritten as | class IsChar c where -- Make this class local to it's defining module | fromChar :: Char -> c | instance IsChar Char where | fromChar = id | instance (IsChar c) => IsString [c] where | fromString = map fromChar | | And, like with numeric literals, any string literal will then have an | implicit fromString insert to make the right conversion. | | My guess is that the defaulting mechanism needs to be extended to | default to the String type as well, or we'll get some ambiguous | expressions. | | Any thoughts? | | -- Lennart | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime From bulat.ziganshin at gmail.com Mon Nov 13 14:26:33 2006 From: bulat.zigan