On Feb 4, 2006, at 1:31 PM, Jon Fairbairn wrote:

... There ought to be a list_product somewhere (I mean [1..] `list_product` [4..] == [(1,4),(2,4),(1,5),(3,4),(2,5),(1,6),...]). Is there?

Not that I know of, but here's one which handles finite lists correctly; it'd be a nice addition to Data.List: dzip :: [a] -> [b] -> [(a,b)] dzip = dzipWith (,) dzipWith :: (a -> b -> c) -> [a] -> [b] -> [c] dzipWith f [] ys = [] dzipWith f as [] = [] dzipWith f as (y:ys) = dzipK ys [y] where dzipK (b:bs) rbs = zipWith f as rbs ++ dzipK bs (b : rbs) dzipK [] rbs = dzipT as where dzipT ys@(_:yt) = zipWith f ys rbs ++ dzipT yt dzipT [] = [] -Jan-Willem Maessen

Jón

-- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime

On 2006-02-04 at 16:08EST Cale Gibbard wrote:

cartesian xs ys = map (\[x,y] -> (x,y)) $ sequence [xs,ys]

I'm lost. Isn't that just like cartesian xs ys = [(x,y)|x<-xs, y<-ys] ? Whereas...

On 04/02/06, Jan-Willem Maessen wrote:

...

On Feb 4, 2006, at 1:31 PM, Jon Fairbairn wrote:

...

... There ought to be a list_product somewhere (I mean [1..] `list_product` [4..] == [(1,4),(2,4),(1,5),(3,4),(2,5),(1,6),...]). Is there?

Not that I know of, but here's one which handles finite lists correctly; it'd be a nice addition to Data.List:

dzip :: [a] -> [b] -> [(a,b)] dzip = dzipWith (,)

dzipWith :: (a -> b -> c) -> [a] -> [b] -> [c] dzipWith f [] ys = [] dzipWith f as [] = [] dzipWith f as (y:ys) = dzipK ys [y] where dzipK (b:bs) rbs = zipWith f as rbs ++ dzipK bs (b : rbs) dzipK [] rbs = dzipT as where dzipT ys@(_:yt) = zipWith f ys rbs ++ dzipT yt dzipT [] = []

-Jan-Willem Maessen

...does seem to work for infinite lists! -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

On Sat, Feb 04, 2006 at 06:31:56PM +0000, Jon Fairbairn wrote:

There ought to be a list_product somewhere (I mean [1..] `list_product` [4..] == [(1,4),(2,4),(1,5),(3,4),(2,5),(1,6),...]). Is there?

This is called "fair conjunction" in "Backtracking, Interleaving, and Terminating Monad Transformers" [1]. (>>-) :: [a] -> (a -> [b]) -> [b] [] >>- f = [] (x:xs) >>- f = interleave (f x) (xs >>- f) interleave :: [a] -> [a] -> [a] interleave [] ys = ys interleave (x:xs) ys = x : interleave ys xs t = take 6 ([1..] >>- \x -> [4..] >>- \y -> [(x, y)]) Andrew [1] http://okmij.org/ftp/Computation/monads.html#LogicT

On Sat, Feb 04, 2006 at 11:58:15AM -0800, John Meacham wrote:

On Sat, Feb 04, 2006 at 03:11:10PM +0100, John Hughes wrote:

...

I noticed ticket #55--add parallel list comprehensions--which according to the ticket, will probably be adopted. I would argue against.

I disagree. :) I use them all the time and find them very useful.

however, I do agree with some of your criticisms and would be interested if we can think of some sort of generalization of them.

Hmmm... you can use zip, can't you? If you want to zip arbitrary number of lists, there is a trick that can help: zApp = zipWith ($) then zip3 [1..4] [2..] [3..] is equivalent to: repeat (,,) `zApp` [1..4] `zApp` [2..] `zApp` [3..] where the latter is easily extensible. You could also only use zip, if you don't mind working on nested pairs: zip (zip [1..4] [2..]) [3..] I don't use parallel list comprehensions. I am also zipping trees, and PLCs don't help me here. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland

On Sun, Feb 05, 2006 at 12:50:16AM +0300, Bulat Ziganshin wrote:

Hello Tomasz,

Saturday, February 04, 2006, 11:18:47 PM, you wrote:

TZ> I don't use parallel list comprehensions. I am also zipping trees, TZ> and PLCs don't help me here.

making `zip` a class function should please you :)

Good idea! Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland

On Thu, Feb 16, 2006 at 09:06:24AM +0000, Ross Paterson wrote:

On Sat, Feb 04, 2006 at 03:11:10PM +0100, John Hughes wrote:

...

I noticed ticket #55--add parallel list comprehensions--which according to the ticket, will probably be adopted. I would argue against.

As there are many voices against and only John M speaking for these, it seems reasonable at least to move them from "probably yes" to "maybe".

I really like them, partially because it gives list comprehensions more power than plain old do notation.

...

My opinion may be coloured by the fact that I never use the things. However, I think it's a mistake to add rarely used features with a small payoff to the language. It just makes the language larger, harder to learn, and harder to read for all but the expert, without much corresponding benefit.

I agree, but then I feel the same way about pattern guards. I've used them only recently, and that was modifying code (GHC) that already had lots of Maybe-returning functions designed for use with pattern guards.

Oh golly, I can't live without pattern guards. they are the best thing since sliced bread. :) I don't know how people can write concise code without them. John -- John Meacham - ⑆repetae.net⑆john⑈

John Meacham wrote:

Oh golly, I can't live without pattern guards. they are the best thing since sliced bread. :) I don't know how people can write concise code without them.

I agree. Pattern guards is a must for Haskell'. When you need them (which is often), there's no good substitute. -- Lennart

On Thu, Feb 16, 2006 at 01:27:52AM -0800, John Meacham wrote:

I would be worried about dropping things because people exist who have not used the feature. For all they know, they might love it once they start using it. Very little of haskell is manditory so there really is no need for everyone to explore every corner of the language, but a lot of the syntax makes our lives easier, sometimes substantially so.

Features do impact on people who never use them: when they make errors that stray near the syntactic and type-system space occupied by the feature, and when they read or modify code written by others. As JohnH said, every addition increases the cost of the language, and needs to bring significant benefit to justify inclusion.

Oh golly. I can't live without pattern guards.

Yes, I knew my position was more extreme there.

Oh golly. I can't live without pattern guards. they are the best darn thing since sliced bread. I highly recommend them. I .. would have to seriously refactor a ton of code if pattern guards disapeared.

So much so that it would be less work to implement pattern guards for other compilers and submit the patches.

eh, well, pattern guards are nice. but, many of their uses are also easily replaced, by moving the pg-monad from the lhs to the rhs, and employing MonadPlus for the fall-throughs; something roughly like: f p1 | g1 = e1 .. f pn | gn = en where <stuff> --> f x = fromJust $ do {p1 <- return x; guard g1; return e1} .. `mplus` do {pn <- return x; guard gn; return en} where <stuff> for any pattern matches in the guards, just drop the "guard";-) grouping several guards under one pattern is also straightforward. the only problem is where to place any pattern-dependent wheres. the easy approach matches them lazily out of x, but that matches some things twice.. this is not an argument against pattern guards; but I often find to my surprise that many Haskellers still think that functions with several clauses can't be translated easily (without losing the basic structure [*]) because of the "fall-through" on pattern-match failure, so they might find this translation pattern useful; it could also be elaborated (recovering better error messages) into a naive, but readable, desugaring of pattern-guards and the like, for reports, and for not-yet-supporting implementations.. cheers, claus [*] to be more accurate, since you can move the whole group of clauses into a case, the barrier is seen between moving from the world of patterns and guards to the world of expressions. MonadPlus allows us to move back.