Records (was Re: [Haskell] Improvements to GHC)
Sebastian Sylvan wrote:
Personally I think that the dot is way to good of a symbol to be "wasted" on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I
I found it useful to use (mainly for debugging purposes) mapM (putStrLn . show) <some list> if I want to print its elements each on a new line. -- Dimitry Golubovsky Anywhere on the Web
Sebastian Sylvan wrote:
Personally I think that the dot is way to good of a symbol to be "wasted" on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I
Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type "<Compose> 0 ^" in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation. - Cale
On 2005-11-17 at 13:21EST Cale Gibbard wrote:
Sebastian Sylvan wrote:
Personally I think that the dot is way to good of a symbol to be "wasted" on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I
Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient.
Hear hear.
Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type "<Compose> 0 ^" in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation.
Ought to be ∘, unicode 0x2218, but without defining some keyboard macros, that's even harder to type. On the other hand, I could define ctrl-. as (ucs-insert "2218"), and then it would be no harder to type than >. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk
On Thursday 17 November 2005 19:21, Cale Gibbard wrote:
Sebastian Sylvan wrote:
Personally I think that the dot is way to good of a symbol to be "wasted" on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I
Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type "<Compose> 0 ^" in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation.
Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists. For a hypothetical Haskell2 I'd propose to get rid of all special 'list' constructs and re-use the good symbols and names for /abstract/ interfaces to sequences and collections resp. (in case of the colon) for record selection. Just my 2 cent. Ben
On 17/11/05, Benjamin Franksen
On Thursday 17 November 2005 19:21, Cale Gibbard wrote:
Sebastian Sylvan wrote:
Personally I think that the dot is way to good of a symbol to be "wasted" on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I
Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type "<Compose> 0 ^" in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation.
Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists.
However, the way things are currently, all symbols starting with ':' are constructors of concrete data types, as that's how infix data constructors are distinguished. Also, I must point out that lists are a pretty important structure in lazy functional programming, taking the place of loops in an imperative language, and their importance shouldn't be taken so lightly. Given how much they are used, giving them a little syntax sugar and good looking data constructors doesn't seem all that far off. On the other hand, I would like to see list comprehensions generalised to monad comprehensions again.
For a hypothetical Haskell2 I'd propose to get rid of all special 'list' constructs and re-use the good symbols and names for /abstract/ interfaces to sequences and collections resp. (in case of the colon) for record selection.
However, you can't abstract data constructors. If cons was abstracted, then you couldn't use it in pattern matching, which is problematic.
Just my 2 cent.
Ben _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Nov 17, 2005, at 1:52 PM, Benjamin Franksen wrote:
... Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists.
Would you be happier if it were the "yield" operator for iterators? Yours lazily, Jan-Willem Maessen
Just my 2 cent.
Ben _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Friday 18 November 2005 02:59, you wrote:
On Nov 17, 2005, at 1:52 PM, Benjamin Franksen wrote:
... Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists.
Would you be happier if it were the "yield" operator for iterators?
Yours lazily,
Ok, ok, I tend to forget that Haskell lists are lazy streams, not just simple stacks... which makes them indeed a /lot/ more useful than the corresponding data type in strict languages. I still think all those nice short and meaningful names in the Prelude (map, filter, ...) should be type class members in some suitable standard collection library. Ben
participants (5)
-
Benjamin Franksen -
Cale Gibbard -
Dimitry Golubovsky -
Jan-Willem Maessen -
Jon Fairbairn