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 the functions being composed have some parameters > applied to them. I disagree that it's just for obfuscation. Well, what I said was that for any more complex cases than that it ends up being hard to read. In a lot of examples when peopl abuse function compostion you really have to think for quite a while before you can figure out what it does, whereas if they had just written out everything in a few more steps it would've been immediatly clear. "filter (not # null)" isn't in any way worse than "filter (not . null)" IMO. Also, like I said earlier, I would even prefer a larger operator for compositon since in that case you want spaces around the operator (at least that's how I always use it in maths) and the dot is perhaps a bit too small in that case (easy to miss it on a glance, misstaking it for application). How about (<>) for the ring operator? That's almost a circle. "filter (not <> null)" looks pretty nice IMO. At any rate, I think that the dot is such a good symbol that I'd prefer to give it to a primitive operator (such as module or record selection) rather than something which is user-defined (but in the prelude). Plus, if the record system was halfway decent, I'm pretty sure record selection would occur a few orders of magnitude more often than function composition. So from a pure "popularity" standpoint record selection would win (assuming it's agreed that three uses for the dot operator is too much and one needs to go, that is). /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