On Mon, 2008-11-10 at 16:06 -0600, Derek Elkins wrote:
> On Mon, 2008-11-10 at 18:50 +, Duncan Coutts wrote:
> [...]
> > If you meant, why is it allowed rather than banned then I guess the
> > answer is because it is orthogonal. The rules naturally handle that case
> > and there was no particul
On Mon, 2008-11-10 at 18:50 +, Duncan Coutts wrote:
[...]
> If you meant, why is it allowed rather than banned then I guess the
> answer is because it is orthogonal. The rules naturally handle that case
> and there was no particular reason to ban it, even if it is somewhat
> unusual.
"Unusual?
On Mon, 2008-11-10 at 18:48 +, Andrew Coppin wrote:
> Jonathan Cast wrote:
> > On Mon, 2008-11-10 at 18:20 +, Andrew Coppin wrote:
> >
> >> Mitchell, Neil wrote:
> >>
> >>> In general:
> >>>
> >>> if boolean then [value] else []
> >>>
> >>> Can be written as:
> >>>
> >>> [value | bo
On Mon, 2008-11-10 at 18:19 +, Andrew Coppin wrote:
> I don't actually use *lists* all that much - or at least not list
> transformations. And if I'm going to do something complicated, I'll
> usually write it as a do-expression rather than a comprehension.
>
> > Just a random example out of
On Mon, 2008-11-10 at 18:20 +, Andrew Coppin wrote:
> Mitchell, Neil wrote:
> > In general:
> >
> > if boolean then [value] else []
> >
> > Can be written as:
> >
> > [value | boolean]
> >
>
> Is there any specific reason why this is valid?
It is due to the rules for the translation of lis
Jonathan Cast wrote:
On Mon, 2008-11-10 at 18:20 +, Andrew Coppin wrote:
Mitchell, Neil wrote:
In general:
if boolean then [value] else []
Can be written as:
[value | boolean]
Is there any specific reason why this is valid?
Is there any specific reason to dis-al
On Mon, 2008-11-10 at 18:19 +, Andrew Coppin wrote:
> Duncan Coutts wrote:
> > On Sun, 2008-11-09 at 19:18 +, Andrew Coppin wrote:
> >
> >>
> >> Generalised? Heck, I don't use list comprehension at all! :-P
> >>
> >
> > Perhaps you should! :-)
> >
> > When I first started with Haske
On Mon, 2008-11-10 at 18:20 +, Andrew Coppin wrote:
> Mitchell, Neil wrote:
> > In general:
> >
> > if boolean then [value] else []
> >
> > Can be written as:
> >
> > [value | boolean]
> >
>
> Is there any specific reason why this is valid?
Is there any specific reason to dis-allow it? Th
Because expressions are treated as guards in list comprehensions. I.e.:
[ foo | x <- a, b, y <- c, d ]
Is interpreted as:
do x <- a
guard b
y <- c
guard d
return foo
Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Mitchell, Neil wrote:
In general:
if boolean then [value] else []
Can be written as:
[value | boolean]
Is there any specific reason why this is valid?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinf
Duncan Coutts wrote:
On Sun, 2008-11-09 at 19:18 +, Andrew Coppin wrote:
Generalised? Heck, I don't use list comprehension at all! :-P
Perhaps you should! :-)
When I first started with Haskell I kind of had the idea that list
comprehensions were just for beginners and that 'real'
On Sun, 2008-11-09 at 19:18 +, Andrew Coppin wrote:
> Derek Elkins wrote:
> > As far as I can tell, no one actually uses parallel list comprehensions.
> > With any luck, the same will be true for generalized list
> > comprehensions.
> >
>
> Generalised? Heck, I don't use list comprehension
> > Generalised? Heck, I don't use list comprehension at all! :-P
>
> Perhaps you should! :-)
You definitely should! Take a look at the Uniplate paper for some
wonderful concise uses of list comprehensions for abstract syntax tree
traversals. If you use a language like F# they become even more co
Derek Elkins wrote:
> As far as I can tell, no one actually uses parallel list comprehensions.
> With any luck, the same will be true for generalized list
> comprehensions.
I second this.
-Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http
Derek Elkins wrote:
As far as I can tell, no one actually uses parallel list comprehensions.
With any luck, the same will be true for generalized list
comprehensions.
Generalised? Heck, I don't use list comprehension at all! :-P
___
Haskell-Cafe m
On Sun, 2008-11-09 at 10:15 +, Max Bolingbroke wrote:
> 2008/11/9 Johannes Waldmann <[EMAIL PROTECTED]>:
> > NB: Wasn't there a time (before "do") when "list" notation (brackets)
> > would work in any monad? And "map" was a method in "Functor",
> > and we had "class Functor m => Monad m", etc.
like [(x, y) | x <- xs | y <- ys], and it's not clear how to define
"zip" for a monad - but perhaps there is some extension of a monad
where it makes sense?
Well, I question that the above notation makes sense (for lists).
It is trying to be too clever.
"standard" list comprehensions at leas
2008/11/9 Johannes Waldmann <[EMAIL PROTECTED]>:
> NB: Wasn't there a time (before "do") when "list" notation (brackets)
> would work in any monad? And "map" was a method in "Functor",
> and we had "class Functor m => Monad m", etc. Well well well times have
> changed.
Sure, I believe the feature
I don't think we
considered the possibility you might use do notation for the list
monad, as it's not an idiom that seems to occur often.
depends where you look, I guess. (Such questions could in principle
be answered automatically by browsing the code on hackage?)
As I said, I am avoiding lis
2008/11/8 Johannes Waldmann <[EMAIL PROTECTED]>:
> Looking at this funny new feature
> http://haskell.org/ghc/docs/6.10.1/html/users_guide/syntax-extns.html#generalised-list-comprehensions
> I have just one question - why doesn't this work with the do-notation?
>
> I avoid list comprehensions becau
Looking at this funny new feature
http://haskell.org/ghc/docs/6.10.1/html/users_guide/syntax-extns.html#generalised-list-comprehensions
I have just one question - why doesn't this work with the do-notation?
I avoid list comprehensions because I feel that
"return" belongs at the end, not in front.
21 matches
Mail list logo
