Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Am Montag, 21. November 2005 20:51 schrieb Henning Thielemann: On Mon, 21 Nov 2005, Wolfgang Jeltsch wrote: [...] Hmm, printing code on paper isn't good for the environment. But is quite the same argument for e-paper. :-) I already thought about this. But if your computer is turned on anyway (as usually is mine during my work time), it doesn't make any difference. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Sat, 2005-11-19 at 15:40 +0300, Bulat Ziganshin wrote: my 15 CRT holds entire 100, even 102 chars in line and i don't want to lose even one of them! :) especially when comment to this function occupies another 7 lines :) The best argument I can come up with when advocating lines of 80 chars for most programming code is subtle, but important: Code is easier to read for me when it is printed on good old paper. a2ps(1) is magnificient, but it takes 80 chars only if you want two pages on a single A4. Quite a number of projects violates the 80 column principle with the result it is unreadable on print. The human eye is not good at scanning long lines. You tend to miss the beginning of the next column and has to scan longer for it when reading code. It helps quite a bit that code is indented though, so it is not entirely impossible. I tend to use rather big fonts and not maximize my emacs. I can cram 80 columns in, but no more. On the other hand, having long lines improves the chance that the grep(1) catches what you want when searching for context. You have some empty space in the end of lines to provide a helpful comment more often than in an 80 column setup. All in all, this is bikesheds on greener grass (google for bikeshed and Poul Henning Kamp). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Am Sonntag, 20. November 2005 12:28 schrieb Jesper Louis Andersen: [...] The best argument I can come up with when advocating lines of 80 chars for most programming code is subtle, but important: Code is easier to read for me when it is printed on good old paper. a2ps(1) is magnificient, but it takes 80 chars only if you want two pages on a single A4. Quite a number of projects violates the 80 column principle with the result it is unreadable on print. Hmm, printing code on paper isn't good for the environment. The human eye is not good at scanning long lines. This is a good argument. [...] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/21/05, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Sonntag, 20. November 2005 12:28 schrieb Jesper Louis Andersen: [...] The best argument I can come up with when advocating lines of 80 chars for most programming code is subtle, but important: Code is easier to read for me when it is printed on good old paper. a2ps(1) is magnificient, but it takes 80 chars only if you want two pages on a single A4. Quite a number of projects violates the 80 column principle with the result it is unreadable on print. Hmm, printing code on paper isn't good for the environment. The human eye is not good at scanning long lines. This is a good argument. Also that terminals etc. usually have 80 chars width. It may be time to stop worrying about code width, especially in languages like Haskell where you tend to use horizontal rather than vertical space to write your algorithms. But still, I always try to stick under 80 chars if possible to make it readible in terminals (and some email-clients etc.). /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
You can change the project and update operators in the HList library to behave in exactly this way. At the moment they are constrained to not allow multiple identical labels in records. If this kind of access is considered useful, I can add it to the HList distribution. Keean. David Menendez wrote: Chris Kuklewicz writes: Would the record system describe at http://lambda-the-ultimate.org/node/view/1119 also be convertable into System Fw, GHC's existing, strongly-typeed intermediate language. ? Probably. Daan's current implementation uses MLF, which I believe is system F implemented for ML. (We're talking about the system in Daan Leijen's paper, Extensible Records With Scoped Labels. Good stuff.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Can this not be done with the HList code? I am pretty sure you should be able to map projections over HLists of HLists... (although the HList generic map is a bit ugly, requiring instances of the Apply class). Actually you should look in the OOHaskell paper (if you haven't already) where it discusses using narrow to allow homogeneous lists to be projected from heterogeneous ones... Keean. John Meacham wrote: another thing is that for any record syntax, we would want higher order versions of the selection, setting, and updating routines. A quick perusal of my source code shows over half my uses of record selectors are in a higher order fashion. (which need to be generated with DrIFT with the current syntax) I mean something like map (.foo) xs to pull all the 'foo' fields out of xs. (using made up syntax) or map (foo_s 3) xs to set all the foo fields to 3. (using DrIFT syntax) John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Mon, 21 Nov 2005, Wolfgang Jeltsch wrote: Am Sonntag, 20. November 2005 12:28 schrieb Jesper Louis Andersen: [...] The best argument I can come up with when advocating lines of 80 chars for most programming code is subtle, but important: Code is easier to read for me when it is printed on good old paper. a2ps(1) is magnificient, but it takes 80 chars only if you want two pages on a single A4. Quite a number of projects violates the 80 column principle with the result it is unreadable on print. Hmm, printing code on paper isn't good for the environment. But is quite the same argument for e-paper. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/18/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: I'm not saying it's impossible to make good use of (.), I'm saying that it's not crucial enough to warrant giving it the dot, which in my opinion is one of the best symbols (and I'd hand it over to record selection any day of the week!). I'm also saying that people tend to abuse the (.) operator when they start out because they think that less verbose == better, whereas most people, in my experience, tend to stop using (.) for all but the simplest cases (such as filte (not . null)) after a while to promote readability. I prefer adding a few lines with named sub-expressions to make things clearer. In case someone counts votes pro et contra of replacing (.) operator, I must say that find it one of the most useful and readable way for doing many different things (not only higher-order). And very compact too. And in my code it is very common operator. While if somebody, who at this moment counts my vote, will remove records from the language some day, I very likely wouldn't notice such a loss. And I can't say I'm very experienced haskell programmer. Actually I'm a beginner comparing my experience with other, particularly imperative OOP languages. And records with (.) as field selector (coupled with dumb constructors) will be the last thing i would miss in haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Hello John,
Saturday, November 19, 2005, 2:25:47 AM, you wrote:
JM grep -o ' [-+.*/[EMAIL PROTECTED] ' GenUtil.hs | sort | uniq -c | sort -n
JM 30 .
JM one of the most common operators.
especially in comments ;) add the following filter to strip them:
import System.Environment
main = interact (noStream.(unlines.map noEnd.lines))
noStream ('{':'-':xs) = noInStream xs
noStream (c:xs) = c:noStream xs
noStream=
noInStream ('-':'}':xs) = noStream xs
noInStream (_:xs) = noInStream xs
noInStream=
noEnd ('-':'-':xs) =
noEnd (c:xs) = c:noEnd xs
noEnd=
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[4]: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Hello Sebastian,
Friday, November 18, 2005, 6:35:13 PM, you wrote:
groupLen mapper combinator tester = length . takeWhile tester . scanl1
combinator . map mapper
SS This is a border line example of what I would consider being abuse of
SS the (.) operator.
SS First of all, that line is 96 characters long. A bit much if you ask
SS me.
my 15 CRT holds entire 100, even 102 chars in line and i don't want
to lose even one of them! :) especially when comment to this function
occupies another 7 lines :)
SS groupLen' mapper combinator tester xs
SS= length $ takeWhile tester $ scanl1 combinator $ map mapper xs
SS The difference is minimal, if anything I think that writing out the
SS list argument is actually clearer in this case (although there are
SS cases when you want to work on functions, and writing out the
SS parameters makes things less clear).
... including this one. i'm work with functions, when possible: build
them from values and other functions, hold them in datastructures,
pass and return them to/from functions. if function definition can be
written w/o part of its arguments, i do it in most cases
moreover, in some cases this leads to dramatic changes in speed. see:
-- |Test whether `filepath` meet one of filemasks `filespecs`
match_filespecs filespecs {-filepath-} = any_function (map match_FP filespecs)
function `match_FP` thranslates regexps to functions checking that
given filename match this regular expression:
match_FP :: RegExp - (String-Bool)
when definition of `match_filespecs` contained `filepath`, this
testing works very slow for large filelists. imho, for each filename
list of filespecs was retranslated to testing functions, each
function applied to filename and then results was combined by
`any_function`. it's a pity, especially cosidering that most common
case for regexps list was just [*], which must render to
(const True) testing function. so, in this case it was absolutely
necessary to write all this regexp machinery in point-free style, so that
it returns data-independent functions, which then optimized
(reduced) by Haskell evaluator before applying them to filenames
on the Wiki page RunTimeCompilation there is another examples of
building functions from datastructures before applying to input data
it is very possible that this point-free `groupLen` definition,
together with other point-free definitions, makes filelist processing
in my program faster - i just dont't checked it
SS I'm not saying it's impossible to make good use of (.), I'm saying
SS that it's not crucial enough to warrant giving it the dot, which in my
SS opinion is one of the best symbols (and I'd hand it over to record
SS selection any day of the week!).
SS I'm also saying that people tend to abuse the (.) operator when they
SS start out because they think that less verbose == better, whereas
SS most people, in my experience, tend to stop using (.) for all but the
SS simplest cases (such as filte (not . null)) after a while to promote
SS readability. I prefer adding a few lines with named sub-expressions to
SS make things clearer.
readability is not some constant factor for all people. it depends
on your experience. for you it is natural to work with data values.
for me, it's the same natural to work with function values, partially
apply and combine them. and in those definitions the variables
containing actual data is just looks as garbage for me
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Sebastian Sylvan wrote: How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That symbol actually does look better, but isn't on any English keyboards to the best of my knowledge. I can get it in my setup with compose-key o x, but not many people have a compose key assigned. Also, this may just be a bug, but currently, ghc gives a lexical error if I try to use that symbol anywhere, probably just since it's not an ASCII character. Hmm. On my keyboard it's Shift+4. Strange that it's not available on other keyboards. As far as I know that symbol means nothing particularly swedish. In fact, I have no idea what it means at all =) It's a generic currency symbol (the X11 keysym is XK_currency). It doesn't exist on a UK keyboard (where Shift-4 is the dollar sign). In any case, using non-ASCII characters gives rise to encoding issues (e.g. you have to be able to edit UTF-8 files). -- Glynn Clements [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/18/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On Thu, Nov 17, 2005 at 06:56:09PM +0100, Sebastian Sylvan wrote: Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. But this case is quite important, isn't it? I'm not so sure it is, and you can almost always write it using ($) without too much trouble. I really only ever use (.) for pretty simple things like filter (not . null). Again. I'm thinking () is a good operator. An intelligent editor would pull them together a bit more to make it look even more like a ring. I could see myself using and for dot and cross products in linear algebra, though, but I'm willing to sacrifice those operators for the greater good :-) /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
I always fancied () as a synonym for 'mappend' John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Fri, Nov 18, 2005 at 12:21:09PM +0100, Sebastian Sylvan wrote: On 11/18/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On Thu, Nov 17, 2005 at 06:56:09PM +0100, Sebastian Sylvan wrote: Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. But this case is quite important, isn't it? I'm not so sure it is, and you can almost always write it using ($) without too much trouble. I really only ever use (.) for pretty simple things like filter (not . null). Try not to look as if you wanted to _remove_ the composition operator, because that will make people angry (w...) :-) We are talking about _renaming_ the composition, not removing it, right? If you removed it from the Prelude, most people would write their own versions, with different names, and we rather don't want that. Anyway, is it realistic to expect that people will rewrite their programs to use the new operator? I thought that the new version of Haskell will be mostly downwards compatible with Hashell 98? Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/18/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On Fri, Nov 18, 2005 at 12:21:09PM +0100, Sebastian Sylvan wrote: On 11/18/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On Thu, Nov 17, 2005 at 06:56:09PM +0100, Sebastian Sylvan wrote: Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. But this case is quite important, isn't it? I'm not so sure it is, and you can almost always write it using ($) without too much trouble. I really only ever use (.) for pretty simple things like filter (not . null). Try not to look as if you wanted to _remove_ the composition operator, because that will make people angry (w...) :-) We are talking about _renaming_ the composition, not removing it, right? Yes. I just don't think it's used enough to warrant giving it one of the best symbols. Anyway, is it realistic to expect that people will rewrite their programs to use the new operator? I thought that the new version of Haskell will be mostly downwards compatible with Hashell 98? Well the records proposal is unlikely to go in Haskell 1.5 anyway, so I'm mainly exercising wishful thinking here. In Haskell 2.0, which I understand to be more of a complete make-over, backwards-compability be damned!, this could be considered. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Fri, Nov 18, 2005 at 04:22:59PM +0100, Sebastian Sylvan wrote: Yes. I just don't think it's used enough to warrant giving it one of the best symbols. grep -o ' [-+.*/[EMAIL PROTECTED] ' GenUtil.hs | sort | uniq -c | sort -n 1 $! 1 * 8 + 10 == 12 - 17 -- 30 . 31 $ 39 ++ one of the most common operators. I think experienced haskell programers tend to use it a whole lot more often than beginning ones, and I am not even a point-free advocate. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
I second this motion! I rather like Simon's proposal. On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. On 11/17/05, Joel Reymont [EMAIL PROTECTED] wrote: Don't get me started, please :-). I tried making each field a separate class but then needed to compose records of difference field instances which led to HList which led to GHC eating up all my memory and crashing, etc. I can see where you are going but if I have 250 records with shared fields then that's a whole lot of extra boiler plate code to marshall between the functions with prefixes to the class method implementations. The road to hell is paved with good intentions ;-). Thanks for the tip, though. On Nov 17, 2005, at 2:12 PM, Fraser Wilson wrote: To solve this problem I just made them all instances of a class with a gameId function. Still, not ideal. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit).Joel Reymont [EMAIL PROTECTED] wrote: I second this motion! I rather like Simon's proposal.On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. ===Gregory Woodhouse [EMAIL PROTECTED] "Interaction is the mind-body problem of computing." --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Joel Reymont [EMAIL PROTECTED] wrote: I second this motion! I rather like Simon's proposal. On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. === Gregory Woodhouse [EMAIL PROTECTED] Interaction is the mind-body problem of computing. --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
So it sounds to me that momentum is building behind Simon PJ's proposal and that we are finally getting somewhere! Now, when can we actually get this in GHC? On Nov 17, 2005, at 5:56 PM, Sebastian Sylvan wrote: I've been wanting this for ages. It's SO much better than the current horribly broken records we have. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Would the record system describe at http://lambda-the-ultimate.org/node/view/1119 also be convertable into System Fw, GHC's existing, strongly-typeed intermediate language. ? On Thu, November 17, 2005 17:56, Sebastian Sylvan said: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Joel Reymont [EMAIL PROTECTED] wrote: I second this motion! I rather like Simon's proposal. On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. == Gregory Woodhouse [EMAIL PROTECTED] Interaction is the mind-body problem of computing. --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote:
Isn't there a potential for confusion with function composition (f . g)?
Perhaps, but I always have spaces on either side when it's function composition. Isn't there already an ambiguity?
-- I bet there's a quicker way to do this ...
module M where data M a = M a deriving (Show)
data T a = T a deriving (Show)
module M.T where f = (+1)
import M
import qualified M.T
f = (*2)
v1 = M . T . f $ 5
v2 = M.T.f $ 5
main = do { print v1; print v2; return () }
Fraser.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. Another option is to make application of a label to a record mean projection, somewhat like things currently are, though since labels aren't really functions anymore that is potentially confusing. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. This is going to be highly fuzzy and completely subjective. Here it goes. I find that for selections (records, or qualified modules etc.) I want the operator to be small and so that the important word groups become the module or the record. When I read the following two variants myPoint#x myPoint.x I definatly prefer the latter. In the first one the operator is so large that it makes myPoint and x blend together as you read it (step away from the monitor and squint and you'll see what I mean), whereas in the second example the operator is small and makes the two operands naturally separate slightly when reading it, which makes it easier to tell which identifier is accessed. Also, it's certainly not a BAD thing if Haskell uses the same operators as other languages. With function composition, though, the operator is just as important to identify when reading as the operands are. So I don't think a big operator is a problem there - likewise I have no problems with ($) being large. How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That's my subjective view on why the dot-operator is so darn nice, anyway. Oh and to answer to your other post. I realise that function composition is a fundamental operation, but it's so fundamental that it's quite useless for most real-world cases unless your willing to seriously ubfuscate your code. IMO it really only works well for simple chains like foo . bar . oof . rab but as soon as you start working with functions that take more parameters it starts looking very unreadable and you'd be better off to just use $ or write out paranthesis and apply arguments explicitly, or better yet, introduce some temporary descriptive variables in a let or where clause. It's a matter of personal preference, but I certainly haven't found it used enough to warrant giving it perhaps the best symbol on the keyboard. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
--- Cale Gibbard [EMAIL PROTECTED] wrote: Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Actually, the fact that (!) is the array selector makes it all the more attractive as a record selector. (It does make you wonder if a record isn't a kind of a typed associative array, though...) Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. Well, yeah, but the arrows have such a fundamentally different meaning in Haskell. (I thought of that one, too). There's a triangle which is not taken, and isn't so hard to type (|). If we're not careful, though, Haskell will end up looking like APL. I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. Another option is to make application of a label to a record mean projection, somewhat like things currently are, though since labels aren't really functions anymore that is potentially confusing. Actually, I thought of that, too, or rather something like get label record or get record label (I haven't made up my mind which way the currying makes more sense. Do you have a generic function for getting records with a certain label, or do you apply get label, tget the field with this label, to record?) - Cale === Gregory Woodhouse [EMAIL PROTECTED] Interaction is the mind-body problem of computing. --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. This is going to be highly fuzzy and completely subjective. Here it goes. I find that for selections (records, or qualified modules etc.) I want the operator to be small and so that the important word groups become the module or the record. When I read the following two variants myPoint#x myPoint.x I think both of those look crowded -- smashing operator punctuation up against symbols basically never looks good to me. The right amount of spacing isn't generally available without proper typesetting, but a full space is a lot closer than no space at all. Why not myPoint # x and myPoint . x? I definatly prefer the latter. In the first one the operator is so large that it makes myPoint and x blend together as you read it (step away from the monitor and squint and you'll see what I mean), whereas in the second example the operator is small and makes the two operands naturally separate slightly when reading it, which makes it easier to tell which identifier is accessed. Also, it's certainly not a BAD thing if Haskell uses the same operators as other languages. With function composition, though, the operator is just as important to identify when reading as the operands are. So I don't think a big operator is a problem there - likewise I have no problems with ($) being large. How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That symbol actually does look better, but isn't on any English keyboards to the best of my knowledge. I can get it in my setup with compose-key o x, but not many people have a compose key assigned. Also, this may just be a bug, but currently, ghc gives a lexical error if I try to use that symbol anywhere, probably just since it's not an ASCII character. That's my subjective view on why the dot-operator is so darn nice, anyway. Oh and to answer to your other post. I realise that function composition is a fundamental operation, but it's so fundamental that it's quite useless for most real-world cases unless your willing to seriously ubfuscate your code. I disagree, there are plenty of cases where it's just what you want, and saves you from introducing a lambda term for nothing. This occurs very often in parameters to higher order functions. A simple example would be something like filter (not . null), or any ((`elem` consumers) . schVertex). More sophisticated examples come up all the time, and often the functions being composed have some parameters applied to them. I disagree that it's just for obfuscation. Using function composition puts emphasis on the manipulation of functions rather than on the manipulation of the elements those functions act on, and quite often in a functional language that's just what you want. IMO it really only works well for simple chains like foo . bar . oof . rab but as soon as you start working with functions that take more parameters it starts looking very unreadable and you'd be better off to just use $ or write out paranthesis
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 17/11/05, Benjamin Franksen [EMAIL PROTECTED] wrote: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. This is going to be highly fuzzy and completely subjective. Here it goes. I find that for selections (records, or qualified modules etc.) I want the operator to be small and so that the important word groups become the module or the record. When I read the following two variants myPoint#x myPoint.x I think both of those look crowded -- smashing operator punctuation up against symbols basically never looks good to me. The right amount of spacing isn't generally available without proper typesetting, but a full space is a lot closer than no space at all. Why not myPoint # x and myPoint . x? Well, again this is just preference, but to me I'd like selectors to not have space between the record and the label, they still need to be connected, but with a symbol which is small enought to help you easily see what's what. I definatly prefer the latter. In the first one the operator is so large that it makes myPoint and x blend together as you read it (step away from the monitor and squint and you'll see what I mean), whereas in the second example the operator is small and makes the two operands naturally separate slightly when reading it, which makes it easier to tell which identifier is accessed. Also, it's certainly not a BAD thing if Haskell uses the same operators as other languages. With function composition, though, the operator is just as important to identify when reading as the operands are. So I don't think a big operator is a problem there - likewise I have no problems with ($) being large. How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That symbol actually does look better, but isn't on any English keyboards to the best of my knowledge. I can get it in my setup with compose-key o x, but not many people have a compose key assigned. Also, this may just be a bug, but currently, ghc gives a lexical error if I try to use that symbol anywhere, probably just since it's not an ASCII character. Hmm. On my keyboard it's Shift+4. Strange that it's not available on other keyboards. As far as I know that symbol means nothing particularly swedish. In fact, I have no idea what it means at all =) That's my subjective view on why the dot-operator is so darn nice, anyway. Oh and to answer to your other post. I realise that function composition is a fundamental operation, but it's so fundamental that it's quite useless for most real-world cases unless your willing to seriously ubfuscate your code. I disagree, there are plenty of cases where it's just what you want, and saves you from introducing a lambda term for nothing. This occurs very often in parameters to higher order functions. A simple example would be something like filter (not . null), or any ((`elem` consumers) . schVertex). More sophisticated examples come up all the time, and often
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
another thing is that for any record syntax, we would want higher order versions of the selection, setting, and updating routines. A quick perusal of my source code shows over half my uses of record selectors are in a higher order fashion. (which need to be generated with DrIFT with the current syntax) I mean something like map (.foo) xs to pull all the 'foo' fields out of xs. (using made up syntax) or map (foo_s 3) xs to set all the foo fields to 3. (using DrIFT syntax) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Chris Kuklewicz writes: Would the record system describe at http://lambda-the-ultimate.org/node/view/1119 also be convertable into System Fw, GHC's existing, strongly-typeed intermediate language. ? Probably. Daan's current implementation uses MLF, which I believe is system F implemented for ML. (We're talking about the system in Daan Leijen's paper, Extensible Records With Scoped Labels. Good stuff.) -- David Menendez [EMAIL PROTECTED] | In this house, we obey the laws http://www.eyrie.org/~zednenem |of thermodynamics! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/18/05, John Meacham [EMAIL PROTECTED] wrote:
another thing is that for any record syntax, we would want higher order
versions of the selection, setting, and updating routines. A quick
perusal of my source code shows over half my uses of record selectors
are in a higher order fashion. (which need to be generated with DrIFT
with the current syntax)
I mean something like
map (.foo) xs
to pull all the 'foo' fields out of xs. (using made up syntax)
Well I suppose this is just a section on the selection operator?
map (foo_s 3) xs
This is trickier I think. I think I can live with map (\r - {r | s =
3}), though.
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Fri, Nov 18, 2005 at 07:32:53AM +0100, Sebastian Sylvan wrote:
On 11/18/05, John Meacham [EMAIL PROTECTED] wrote:
map (.foo) xs
to pull all the 'foo' fields out of xs. (using made up syntax)
Well I suppose this is just a section on the selection operator?
So field labels are first-class citizens? Great!
map (foo_s 3) xs
This is trickier I think. I think I can live with map (\r - {r | s =
3}), though.
I think this special case could be treated specially, for example
(\r - {r | s = 3})
could be equivalent to
{|s = 3}
Best regards
Tomasz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Thu, Nov 17, 2005 at 06:56:09PM +0100, 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 just checked in two recent projects, and it's about one (.) in 100 lines of code. I wanted to disagree with you, but in the end I could accept pressing more keys when I wanted function composition, especially if I got something in return. BTW, I think there was some tool to calculate various metrics on Haskell code. It would be interesting to make some graphs showing how often you use various features of Haskell, how it changed with time. I use ($) way more often than (.). Me too, measurement shows it's about four times more often. However, I like my uses of (.) much more than uses of ($). I often turn $'s into parentheses, because I feel it looks better this way. Of course, there are cases where $ is indispensable. Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. But this case is quite important, isn't it? Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
