> 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 bet
n't think we can steal "group" as a keyword -- it's 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; Phili
George, Thanks very much for this. I like your suggestion, which
fits the logical structure perfectly; and you've suggested a neat way
around the ugliness of 'group groupBy'. I also note that if we aren't
so worried about not introducing new keywords, that 'then group' could
become 'group'. You
On Sun, Oct 9, 2011 at 10:33 PM, George Giorgidze 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 a good argumen
For some reasons Philip's email was rejected by the mailing list.
I am reposting his message. See below.
Cheers, George
Begin forwarded message:
> From: Philip Wadler
> Date: 2011-October-11 11:48:31 GMT+02:00
> To: Simon Peyton-Jones , George Giorgidze
>
> Subject
the current story is not great, but it's the best I could think of.
> Improvements welcome.
>
> Simon
>
> | -Original Message-
> | From: Philip Wadler [mailto:wad...@inf.ed.ac.uk]
> | Sent: 04 October 2011 18:15
> | To: Simon Peyton-Jones; George Giorg
For instance, at your day job, the Array type.
On Wed, Oct 5, 2011 at 12:23 PM, Roman Leshchinskiy 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
> >
2011/10/5 Simon Peyton-Jones :
> | 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
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 o
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 an
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
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 yo
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 vis
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
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
2011/10/5 Simon Peyton-Jones :
> | 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
On Wed, Oct 5, 2011 at 8:23 AM, Roman Leshchinskiy 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.
>
> Wha
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 lis
| 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
y salary
But that is hardly beautiful either.
So the current story is not great, but it's the best I could think of.
Improvements welcome.
Simon
| -Original Message-
| From: Philip Wadler [mailto:wad...@inf.ed.ac.uk]
| Sent: 04 October 2011 18:15
| To: Simon Peyton-Jones
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
On Fri, Sep 30, 2011 at 7:28 PM, George Giorgidze 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
2011/10/4 Gábor Lehel :
> On Tue, Oct 4, 2011 at 3:25 PM, Yitzchak Gale 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 modifi
On Tue, Oct 4, 2011 at 3:25 PM, Yitzchak Gale 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 impro
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 f
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 almo
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 the
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
: Two Proposals
|
| 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 the first proposal.
|
| Currently, the SQL-like comprehe
What are the defaulting rules for IsList? It needs to be backwards compatible.
-- Lennart (iPhone)
On Sep 30, 2011, at 19:28, George Giorgidze wrote:
> GHC Users,
>
> I would like to make to the following two proposals:
> * Eliminate the default grouping close f
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 the first proposal.
Currently, the SQL-like comprehension notation (both in its
31 matches
Mail list logo
