Yes... not quite so well with the “by” variants. What would we say?
then group initsBy by x
This problem occurs independent of group, does it not?
then sortBy by x
The solution is to rename
sort -- sortByDefault
sortBy -- sort
but that's hardly appealing. Might be better
a function exported by
Data.List, and I don't think the benefit justifies the cost.
Simon
From: George Giorgidze [mailto:giorgi...@gmail.com]
Sent: 10 October 2011 23:22
To: Simon Peyton-Jones; GHC Users List; Philip Wadler
Subject: Re: Two Proposals
A quick thought that came to me after hoogling
On Sun, Oct 9, 2011 at 10:33 PM, George Giorgidze giorgi...@gmail.com wrote:
Thanks to all of you for providing feedback on my proposal and for providing
alternatives.
In this email, I will try to collect all proposals and give pros and cons for
each of those (although I will try to provide
For instance, at your day job, the Array type.
On Wed, Oct 5, 2011 at 12:23 PM, Roman Leshchinskiy r...@cse.unsw.edu.auwrote:
Simon Peyton-Jones wrote:
I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map
String Int. Probably not. Maybe that's a shortcoming... but such
A quick thought that came to me after hoogling [a] - [[a]].
The first four functions in the search result are named after what they return
(noun in plural) rather than what they do (verb). I am talking about inits,
permutations, subsequence and tails.
So I thought the following syntax might
Thanks to all of you for providing feedback on my proposal and for providing
alternatives.
In this email, I will try to collect all proposals and give pros and cons for
each of those (although I will try to provide a good argumentation, some of
them might be subjective).
Inspired by Simon's
On Oct 6, 2011, at 10:30 AM, Roman Leshchinskiy wrote:
Manuel M T Chakravarty wrote:
Roman Leshchinskiy:
What data structures other than lists do we want to construct using list
literals? I'm not really sure what the use cases are.
Parallel arrays! (I want to get rid of our custom
2011/10/5 Simon Peyton-Jones simo...@microsoft.com:
| In the spirit of don't let the perfect be the enemy of the good
| though, I'm solidly in favor of the original proposal as it is.
This is my thought too. George is proposing to extend Haskell's existing
mechanism for numeric literals
Roman Leshchinskiy:
Simon Peyton-Jones wrote:
I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map
String Int. Probably not. Maybe that's a shortcoming... but such Maps
are a rather surprising use of list literals.
What data structures other than lists do we want to
Manuel M T Chakravarty wrote:
Roman Leshchinskiy:
What data structures other than lists do we want to construct using list
literals? I'm not really sure what the use cases are.
Parallel arrays! (I want to get rid of our custom syntax.)
Why? Don't you think it is useful to have a visual
Roman Leshchinskiy:
Manuel M T Chakravarty wrote:
Roman Leshchinskiy:
What data structures other than lists do we want to construct using list
literals? I'm not really sure what the use cases are.
Parallel arrays! (I want to get rid of our custom syntax.)
Why? Don't you think it is
Am Freitag, den 30.09.2011, 19:28 +0200 schrieb George Giorgidze:
Basically the idea is to treat list literals like:
[1,2,3]
as
fromList [1,2,3]
where
class IsList l where
type Item l
fromList :: [Item l] - l
Could we *please* not have classes whose names start with “Is”? We
| In the spirit of don't let the perfect be the enemy of the good
| though, I'm solidly in favor of the original proposal as it is.
This is my thought too. George is proposing to extend Haskell's existing
mechanism for numeric literals (namely, replace 4 by (fromInteger
(4::Integer))), so
Simon Peyton-Jones wrote:
I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map
String Int. Probably not. Maybe that's a shortcoming... but such Maps
are a rather surprising use of list literals.
What data structures other than lists do we want to construct using list
On Wed, Oct 5, 2011 at 8:23 AM, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
Simon Peyton-Jones wrote:
I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map
String Int. Probably not. Maybe that's a shortcoming... but such Maps
are a rather surprising use of list literals.
2011/10/5 Simon Peyton-Jones simo...@microsoft.com:
| In the spirit of don't let the perfect be the enemy of the good
| though, I'm solidly in favor of the original proposal as it is.
This is my thought too. George is proposing to extend Haskell's existing
mechanism for numeric literals
Hi all,
Simon PJ wrote:
should we not treat
[a,b,c]
as short for
return a `mappend` return b `mappend` return c
[...]
I'm not sure if this plan would support [(fred,45), (bill,22)] ::
Map String Int. Probably not. Maybe that's a shortcoming... but
such Maps are a
I like both George's proposals.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of George Giorgidze
| Sent: 30 September 2011 18:28
| To: glasgow-haskell-users@haskell.org
| Subject: Two
George Giorgidze wrote:
My second proposal is to introduce the
OverloadedLists extension that overloads
list literals...
I am opposed to this proposal as stated.
But I think that with a modification,
it can not only be improved, but also solve
the problems with the current OverloadedStrings
George Giorgidze wrote:
This extension could also be used for giving data-parallel array literals
instead of the special syntax used currently.
Unfortunately, it couldn't. DPH array literals don't (and can't really) go
through lists.
In general, if we are going to overload list literals then
Roman Leshchinskiy wrote:
In general, if we are going to overload list literals then forcing the
desugaring to always go through lists seems wrong to me. There are plenty
of data structures where that might result in a significant performance
hit.
These are literals. So the lists will almost
Just anecdotally I remember we had this problem with Accelerate.
Back when we were using it last Spring for some reason we were forced by the
API to at least nominally go through lists on our way to the GPU -- which we
sorely hoped were deforested! At times (and somewhat unpredictably), we'd
be
On Tue, Oct 4, 2011 at 3:25 PM, Yitzchak Gale g...@sefer.org wrote:
George Giorgidze wrote:
My second proposal is to introduce the
OverloadedLists extension that overloads
list literals...
I am opposed to this proposal as stated.
But I think that with a modification,
it can not only be
2011/10/4 Gábor Lehel illiss...@gmail.com:
On Tue, Oct 4, 2011 at 3:25 PM, Yitzchak Gale g...@sefer.org wrote:
George Giorgidze wrote:
My second proposal is to introduce the
OverloadedLists extension that overloads
list literals...
I am opposed to this proposal as stated.
But I think that
On Fri, Sep 30, 2011 at 7:28 PM, George Giorgidze giorgi...@gmail.com wrote:
GHC Users,
I would like to make to the following two proposals:
* Eliminate the default grouping close from SQL-like comprehensions
* Introduce a GHC extension for list literal overloading
OK, let me start with
Yitzchak Gale wrote:
Roman Leshchinskiy wrote:
In general, if we are going to overload list literals then forcing the
desugaring to always go through lists seems wrong to me. There are
plenty
of data structures where that might result in a significant performance
hit.
These are literals.
What are the defaulting rules for IsList? It needs to be backwards compatible.
-- Lennart (iPhone)
On Sep 30, 2011, at 19:28, George Giorgidze giorgi...@gmail.com wrote:
GHC Users,
I would like to make to the following two proposals:
* Eliminate the default grouping close from
27 matches
Mail list logo
