<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>A quick thought that came to me after hoogling [a] -> [[a]].</div><div><br></div><div>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 <font class="Apple-style-span" face="'Courier New'">inits</font>, <font class="Apple-style-span" face="'Courier New'">permutations</font>, <font class="Apple-style-span" face="'Courier New'">subsequence</font> and <font class="Apple-style-span" face="'Courier New'">tails</font>.</div><div><br></div><div>So I thought the following syntax might work as well if (as it is already common) grouping functions are named after what they return.</div><div><br></div><div><div><font class="Apple-style-span" face="'Courier New'">then f<br>then f by e<br>then group f<br>then group f by e</font></div></div><div><br></div><div>For example the following code fragments read well:</div><div><br></div><div><font class="Apple-style-span" face="'Courier New'">then group inits</font></div><div><font class="Apple-style-span" face="'Courier New'">then group permutations</font></div><div><font class="Apple-style-span" face="'Courier New'">then group subsequences</font></div><div><font class="Apple-style-span" face="'Courier New'">then group tails</font></div><div><br></div><div>Here we use the special identifier group as a verb.</div><div><br></div><div>I have not told you about the fifth result of the hoogling, the <font class="Apple-style-span" face="'Courier New'">groupWith</font> function. The following really looks ugly:</div><div><br></div><div><font class="Apple-style-span" face="'Courier New'">then group groupWith by e</font></div><div><br></div><div>But following the aforementioned naming convention the <font class="Apple-style-span" face="'Courier New'">groupWith</font> function could as well be named as <font class="Apple-style-span" face="'Courier New'">equals</font>. Now this reads well:</div><div><br></div><div><font class="Apple-style-span" face="'Courier New'">then group equals by e</font></div><div><br></div><div>Cheers, George</div><div><br></div><br><div><div>On 2011-Oct-5, at 09:14 , Simon Peyton-Jones wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>[adding ghc-users]<br><br>It's not easy, Phil. Do you have any ideas?<br><br>For the 'then' case the name of the function serves as the verb. One might say<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>then take 4<br>or<br><span class="Apple-tab-span" style="white-space:pre"> </span>then takeWhile by salary > 40<br><br>For grouping one might like to say the same thing, such as<br><span class="Apple-tab-span" style="white-space:pre"> </span>then groupBy by salary<br>but the typing rule is quite different, so we really need a different keyword. We chose the compound keyword "then group" to avoid needing a whole new keyword ("group" is treated specially only in tthis context). So you write<br><span class="Apple-tab-span" style="white-space:pre"> </span>then group by salary using groupBy<br><br>Using this order of the pieces for the sorting case is harder. What would one say? "then process"? Like this?<br><span class="Apple-tab-span" style="white-space:pre"> </span>then process by salary > 40 using takeWhile<br>Not very nice.<br><br>One could use a new keyword for grouping "theng" say, thus:<br><span class="Apple-tab-span" style="white-space:pre"> </span>theng groupBy by salary<br>But that is hardly beautiful either.<br><br>So the current story is not great, but it's the best I could think of. Improvements welcome.<br><br>Simon<br><br>| -----Original Message-----<br>| From: Philip Wadler [mailto:wadler@inf.ed.ac.uk]<br>| Sent: 04 October 2011 18:15<br>| To: Simon Peyton-Jones; George Giorgidze<br>| Subject: Re: FW: Two Proposals<br>| <br>| George,<br>| <br>| Nice proposal. I like the idea of symmetry, but don't at all like the<br>| idea that f comes before e for 'then' but f comes after e for 'then<br>| group'. Can you rethink it and come up with something even more<br>| symmetric?<br>| <br>| Yours, -- P<br>| <br>| <br>| On Tue, Oct 4, 2011 at 9:23 AM, Simon Peyton-Jones<br>| <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<br>| > FYI<br>| ><br>| > -----Original Message-----<br>| > From: <a href="mailto:glasgow-haskell-users-bounces@haskell.org">glasgow-haskell-users-bounces@haskell.org</a> [mailto:glasgow-haskell-<br>| users-bounces@haskell.org] On Behalf Of George Giorgidze<br>| > Sent: 30 September 2011 18:28<br>| > To: <a href="mailto:glasgow-haskell-users@haskell.org">glasgow-haskell-users@haskell.org</a><br>| > Subject: Two Proposals<br>| ><br>| > GHC Users,<br>| ><br>| > I would like to make to the following two proposals:<br>| > * Eliminate the default grouping close from SQL-like comprehensions<br>| > * Introduce a GHC extension for list literal overloading<br>| ><br>| > OK, let me start with the first proposal.<br>| ><br>| > Currently, the SQL-like comprehension notation (both in its list comprehension<br>| and monad comprehension variants) features the following five clauses:<br>| ><br>| > then f<br>| > then f by e<br>| > then group by e<br>| > then group using f<br>| > then group by e using f<br>| ><br>| > The first two clauses are used for specifying transformations of type [a] -> [a]<br>| (or Monad m => m a-> m a for monad comprehensions). The following three<br>| clauses are used for specifying transformations of type [a] -> [[a]] (or Monad m,<br>| Functor f => m a -> m (f a) for monad comprehensions). See [1] for further<br>| details.<br>| ><br>| > Note that the third clause does not mention which function is used for grouping.<br>| In this case GHC.Exts.groupWith function is used as a default for list<br>| comprehensions and the mgroupWith function from the MonadGroup class is used<br>| as a default for monad comprehensions.<br>| ><br>| > I would like to suggest to remove the third clause for the following reasons:<br>| > * Currently the syntax is asymmetrical. Note that there is the default case for<br>| the 'then group' clause and not for the 'then' clause.<br>| > * In the current notation it is not clear which grouping function is used in the<br>| default case<br>| > * For many monads including lists it is not clear which function should be<br>| selected as a default (e.g., the groupWith function also does sorting and it is not<br>| clear to me why this should be the default)<br>| > * Gets rid of the MonadGroup class. Currently the sole purpose of this class is to<br>| introduce a default grouping function for monad comprehensions.<br>| > * Explicit mention of the grouping function would make monad/list<br>| comprehensions much easier to read by making it immediately apparent which<br>| function is used for grouping.<br>| ><br>| > My second proposal is to introduce the OverloadedLists extension that overloads<br>| list literals. See Section 5.2 in [1] for details.<br>| ><br>| > Basically the idea is to treat list literals like:<br>| ><br>| > [1,2,3]<br>| ><br>| > as<br>| ><br>| > fromList [1,2,3]<br>| ><br>| > where<br>| ><br>| > class IsList l where<br>| > type Item l<br>| > fromList :: [Item l] -> l<br>| ><br>| > In the following I give useful instances of the IsList class.<br>| ><br>| > instance IsList [a] where<br>| > type Item [a] = a<br>| > fromList = id<br>| ><br>| > instance (Ord a) => IsList (Set a) where<br>| > type Item (Set a) = a<br>| > fromList = Set.fromList<br>| ><br>| > instance (Ord k) => IsList (Map k v) where<br>| > type Item (Map k v) = (k,v)<br>| > fromList = Map.fromList<br>| ><br>| > instance IsList (IntMap v) where<br>| > type Item (IntMap v) = (Int,v)<br>| > fromList = IntMap.fromList<br>| ><br>| > instance IsList Text where<br>| > type Item Text = Char<br>| > fromList = Text.pack<br>| ><br>| > As you can see the extension would allow list literals to be used for sets, maps<br>| and integer maps. In addition the suggested OverloadedLists extension would<br>| subsume OverloadedStrings extension (see the instance for Text, for example).<br>| Having said that, for now, I am not suggesting to remove the OverloadedStrings<br>| extension as it appears to be widely used.<br>| ><br>| > This extension could also be used for giving data-parallel array literals instead of<br>| the special syntax used currently.<br>| ><br>| > Unless there is a vocal opposition to the aforementioned two proposals, I would<br>| like to implement them in GHC. Both changes appear to be straightforward to<br>| implement.<br>| ><br>| > Thanks in advance for your feedback.<br>| ><br>| > Cheers, George<br>| ><br>| > [1] <a href="http://www-db.informatik.uni-tuebingen.de/files/giorgidze/haskell2011.pdf">http://www-db.informatik.uni-tuebingen.de/files/giorgidze/haskell2011.pdf</a><br>| > _______________________________________________<br>| > Glasgow-haskell-users mailing list<br>| > <a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>| > <a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>| ><br>| ><br>| ><br>| <br>| <br>| <br>| --<br>| .\ Philip Wadler, Professor of Theoretical Computer Science<br>| ./\ School of Informatics, University of Edinburgh<br>| / \ <a href="http://homepages.inf.ed.ac.uk/wadler/">http://homepages.inf.ed.ac.uk/wadler/</a><br>| <br>| The University of Edinburgh is a charitable body, registered in<br>| Scotland, with registration number SC005336.<br>| <br><br></div></blockquote></div><br></body></html>