- Haskell-prime - Haskell.org

RE: Infix expressions
by Simon Peyton-Jones 16 Mar '06

16 Mar '06

If it is sufficiently non-obvious to require this thread, perhaps it'd be worth adding the relevant guidance can be added to the idioms page itself? Incidentally, I looked on the Haskell home page for links to programming idioms and advice, but came up empty. The obvious place to look was under "Using Haskell", but I didn't find anything. Was I being stupid? Haskell.org is the obvious place to look for advice about programming in Haskell. S | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Donald Bruce Stewart | Sent: 15 March 2006 23:49 | To: Malcolm Wallace | Cc: haskell-prime(a)haskell.org | Subject: Re: Infix expressions | | Malcolm.Wallace: | > dons(a)cse.unsw.edu.au (Donald Bruce Stewart) writes: | > | > > Yes, this is _exactly_ the kind of thing to add to the Idioms | > > page of the wiki, here: | > > http://www.haskell.org/haskellwiki/Category:Idioms | > > So if anyone knows of an interesting Haskell trick, and wants to write | > > about it, add a page! | > | > It is not entirely clear _how_ to add a page hanging off Idioms. When | > you click on "Edit this page", the text edit box contains only a single | > word: [[Category:Haskell]], and no visible record of the existing text. | > Rather confusing, and there is no link to "add a new page" or similar. | | To add your page to a particular category, have [[Category:Idioms]] (for | example) appear at the bottom of the page -- it then appears automagically. | | You add a new page just by typing that page's url into your browser. | You'll get a blank page suggesting that you create it (once you log on). | | -- Don | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

2 1

only explicit universal quantification
by Wolfgang Jeltsch 16 Mar '06

16 Mar '06

Hello, what about dropping implicit universal quantification of type variables from the language, meaning that every universal quantification has to be made explicit? One advantage of this would be that spelling mistakes in type variables would be detected by the compiler more often since every type variable would need to be “declared” by a forall (or exists). In addition one could think of different semantics for unbound type variables. Such a variable could refer to a quantification at a higher level which would solve the problem of sometimes not being able to give type declarations for let/where declarations. For example, in the following example, the type variable e in the where clause would refer to the same type as the type variable e in the type declaration of the function example: example :: forall e. Enum e => e -> e example = helper where helper :: e -> e helper = succ I know, these would be rather drastic changes but they seem sensible to me. What do others think? Best wishes, Wolfgang

3 2

RE: Infix expressions
by Simon Marlow 15 Mar '06

15 Mar '06

On 15 March 2006 13:41, Malcolm Wallace wrote: > dons(a)cse.unsw.edu.au (Donald Bruce Stewart) writes: > >> Yes, this is _exactly_ the kind of thing to add to the Idioms >> page of the wiki, here: >> http://www.haskell.org/haskellwiki/Category:Idioms >> So if anyone knows of an interesting Haskell trick, and wants to >> write about it, add a page! > > It is not entirely clear _how_ to add a page hanging off Idioms. When > you click on "Edit this page", the text edit box contains only a > single word: [[Category:Haskell]], and no visible record of the > existing text. Rather confusing, and there is no link to "add a new > page" or similar. Good point. I don't know either, but I just thought I'd point out that "Hitchiker's Guide to Haskell" is in a section called "P", for some unknown reason. Cheers, Simon

1 0

Infix expressions
by oleg＠pobox.com 15 Mar '06

15 Mar '06

Doaitse Swierstra wrote: > In Haskell we write `f` in order to infixify the identifier f. In ABC > the stuff between backquotes is not limited to an identifier, but any > expression may occur there. This would allow one to write e.g. > > xs `zipWith (+)` ys Chung-chieh Shan and Dylan Thurston showed the Haskell98 solution for exactly the same example, in their article `Infix expressions', back in 2002: http://www.haskell.org/pipermail/haskell-cafe/2002-July/003215.html For ease of reference, here's their elegant solution: > infixr 0 -:, :- > data Infix f y = f :- y > x -:f:- y = x `f` y > > main = print $ [1,2,3] -: zipWith (+) :- [4,5,6] For completeness, here's the `dual': > infixr 5 -! > (-!) = flip ($) > infixr 5 !- > (!-) = ($) > > add2 x y = x + y > add3 x y z = x + y + z > add4 x y z u = x + y + z + u > > testa1 = 1 -! add2 !- 3 + 4 > testa2 = 1 -! add3 1 !- 3 + 4 > testa3 = 1 - 2 -! add4 1 5 !- 3 * 4 All code is Haskell98.

1 0

RE: overlapping instances and constraints
by Simon Peyton-Jones 11 Mar '06

11 Mar '06

Overlapping instances are undoubtedly useful, but they raise lots of interesting questions. Such as - A program that type checks can have its meaning changed by adding an instance declaration - Similarly adding "import M()" can change the meaning of a program (by changing which instances are visible - Haskell would need to be a lot more specific about exactly where context reduction takes place. Consider f xs x = xs == [x] Do we infer the type (Eq a) => [a] -> a -> Bool? Thereby committing to a particular choice of instance? Or do we (as GHC does) infer the type (Eq [a]) => [a] -> a -> Bool, so that if f is applied at (say) type Char, then an instance Eq [Char] instance would apply. GHC is careful to do the latter. - When exactly is overlap permitted? Is this ok? instance C a Int instance C Bool b Previously GHC rejected this, on the grounds that it could be ambiguous when you came across (C Bool Int). But not GHC accepts it, on the grounds that (C Bool Char) is quite unambiguous. [Actually this last point is relevant for MPTCs even if overlap isn't allowed.] Concerning using the instance context, yes, it's attractive, but it involves *search* which the current mechanism does not. Presumably you have in mind that the type system should "commit" only when there is only one remaining instance declaration that can fit. You need to be very careful not to prune off search branches prematurely, because in a traditional HM type checker you don't know what all the type are completely. And you need to take functional dependencies into account during the search (but not irrevocably). I have not implemented this in GHC. I don't know anyone who has. I don't even know anyone who has specified it. All good stuff to debate. I'd be happy to see the traffic on MPTCs reach half the level that syntax debates do! In general, I think that type-system proposals are much easier to evaluate when accompanied with formal type rules. It's not just a macho thing -- it really helps in debugging the dark corners. Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Claus Reinke | Sent: 26 February 2006 16:28 | To: haskell-prime(a)haskell.org | Subject: overlapping instances and constraints | | | the point about overlapping instances is that they shouldn't, | so we are looking for ways to resolve what looks like overlaps | unambiguously, so that there are no overlapping instances left. | | we don't want overlapping instances in the language definition, | but we do want more expressive means of defining non- | overlapping instances. | | 1. resolving overlaps in favour of the most specific declaration | does so, so why is that approach slated as "adopt: probably no"? | | http://hackage.haskell.org/trac/haskell-prime/ticket/54 | | 2. FDs can help to make types in instance declarations more | specific, thus avoiding some overlaps or at least helping the | "best-match" to resolve overlaps. defaults resolve some of | the simplest overlaps (which instance of Num did you mean?), | but not others, because their overloading is not expressed in | terms of classes (which empty list did you mean?). | | 3. in this context, could someone please remind me what exactly | is the reason that class constraints in instance declarations are | ignored when deciding whether two instances overlap? | | we have two worlds to consider, the unconstrained world of | semi-decidable type class programming, and the restricted | world which guarantees termination of type class inference. | | in the first world, it seems there is no reason not to look at | the constraints, because there are no termination guarantees | anyway. and in the second world, it seems there is no reason | not to look at the constraints, because we know that doing | so will terminate nicely, thank you. | | so why are some instance declarations still rejected as | overlapping even if their constraints clearly say they don't? | | cheers, | claus | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

9 20

darcs patch: add Data.Set.notMember and Data.Map.notMember / generalized infix notation use case
by Jean-Philippe Bernardy 11 Mar '06

11 Mar '06

Patch applied. Still, In time, I suppose the somewhat ugly not (element `member` set) sould be addressed by a mixture of generalized infix notation and the definition of such an operator: f /. g = \x y -> f (g x y) allowing element `not/.member` set Cheers, JP. On 3/11/06, Cale Gibbard <cgibbard(a)gmail.com> wrote: > > I don't like notElem either > > > > > * quite useful for cleaning up guards: > > > > > > f x | not (x `Set.member` map) && foo = ... > > > is hard to read. > > > > You may swap quards (or the "then" and "else" branches of "if"), or > > avoid the infix notation (which is horrible in this case anyway). > > > Although I'd normally agree with negated versions of things being > somewhat redundant, the infix version here is rather important, since > one often wants the code to look the same way as the mathematics. The > symbols \in and \not\in are both usually written infix, and that's not > going to change soon. Putting the membership operation in between is > nice, because we read the guard here as "If x is a member of xs > then..." rather than "If member x xs then..." anyway. Perhaps if the > proposal to allow somewhat more general expressions as infix operators > goes through (which I'm actually ambivalent about), I'd feel different > about this case. > > If you want to reduce redundancy, let's unify the 3 separate ways to > say 'map'. :) > > - Cale > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

1 0

Re[2]: darcs patch: add Data.Set.notMember and Data.Map.notMember
by Bulat Ziganshin 10 Mar '06

10 Mar '06

Hello Christian, Friday, March 10, 2006, 2:32:02 PM, you wrote: >> f x | not (x `Set.member` map) && foo = ... >> is hard to read. btw, (x `not.Set.member` map), as proposed by Doaitse Swierstra, will look better in this case -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Strictness standardization/description
by Henk-Jan van Tuyl 10 Mar '06

10 Mar '06

L.S., Much has already been said about strictness, but what I haven't seen discussed sofar, and what am missing in the Haskell Report, is a description of the strictness of parameters of functions and operators. It is often important to know the strictness to prevent space leaks and even for the correctness of a program. A description of strictness in the Haskell' report would not only enable more reliable design of Haskell programs, but also prevent difference in strictness between the compilers/interpreters. -- Best regards, Henk-Jan van Tuyl -- http://members.chello.nl/hjgtuyl -- Using Opera's revolutionary e-mail client: https://secure.bmtmicro.com/opera/buy-opera.html?AID=789433

3 2

RE: the dreaded offside rule
by Simon Marlow 10 Mar '06

10 Mar '06

On 10 March 2006 11:02, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> wrote: > >> Here's another couple that just occurred to me: >> >> f x | let y = x = y >> f x = case x of _ | let y = x -> y >> >> granted these are unlikely to occur in practice. > > Are these Haskell'98? I'm afraid I don't understand how a let binding > (without "in") can occur in a guard for a function decl or case > branch. In Ben's examples, the vertical bar was not a guard, but the > separator in a comprehension (although he omitted to show the > surrounding brackets...) > > [ ... | let x, y :: T > x = 3 > y = 4, > ... ] > > [ ... | let x = 3, ... ] Right, they're not Haskell 98, they all require pattern guards. Cheers, Simon

1 0

RE: the dreaded offside rule
by Simon Marlow 10 Mar '06

10 Mar '06

On 09 March 2006 22:56, Ian Lynagh wrote: > On Thu, Mar 09, 2006 at 04:53:52PM -0000, Simon Marlow wrote: >> On 09 March 2006 14:40, Simon Marlow wrote: >> >>> But ISTR I later discovered a reason that counting brackets wouldn't >>> work so well, but for now it escapes me. I'll try to dig it up. >> >> I remember now: the problem is that 'let' does not always have a >> matching 'in', e.g. when it is used in 'do', pattern guards or list >> comprehensions. So you can't consistently treat let/in as brackets. >> I don't know a way around this. > > Right, I mentioned that in my earlier mail. So you did, sorry, I skimmed it too quickly. Ben's mail pretty much covers the problems with this idea, I think. It's unfortunate, because it almost works. Here's another couple that just occurred to me: f x | let y = x = y f x = case x of _ | let y = x -> y granted these are unlikely to occur in practice. Cheers, Simon

2 1