On 11/17/05, Greg Woodhouse 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 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

"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

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 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 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

"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

On 11/17/05, Cale Gibbard wrote:

On 17/11/05, Sebastian Sylvan wrote:

...

On 11/17/05, Greg Woodhouse 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

On 11/17/05, Cale Gibbard wrote:

On 17/11/05, Sebastian Sylvan wrote:

...

On 11/17/05, Cale Gibbard wrote:

...

On 17/11/05, Sebastian Sylvan wrote:

...

On 11/17/05, Greg Woodhouse 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

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⑈

On Fri, Nov 18, 2005 at 07:32:53AM +0100, Sebastian Sylvan wrote:

On 11/18/05, John Meacham 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

Hello Sebastian, Thursday, November 17, 2005, 11:02:09 PM, you wrote: SS> IMO it really only works well for simple "chains" like "foo . bar . SS> oof . rab" but as soon as you start working with functions that take SS> more parameters it starts looking very unreadable and you'd be better SS> off to just use $ or write out paranthesis and apply arguments SS> explicitly, or better yet, introduce some temporary descriptive SS> variables in a let or where clause. "are you don't like cats? you just don't know how to cook them right!" :) -- |Returns length of initial segment of list, conforming to combined condition -- F.e. "groupLen (fiSize) (+) (<16*mb) files" returns length of -- initial segment of list, containing files with TOTAL size not exceeding 16 mb groupLen mapper combinator tester = length . takeWhile tester . scanl1 combinator . map mapper -- |Sort list by function result (use Schwarznegian transform) sortOn f = map snd . sortOn' fst . map (keyval f) -- |Sort list by function result (don't use Schwarznegian transform!) sortOn' f = sortBy (map2cmp f) -- This defines filters for files, included in various operations on archives let arc_filter = andf [not.excluded_f cmd, not.overwrite_f cmd] let arc_filter = andf [included_f cmd, not.excluded_f cmd] let arc_filter = not.andf [included_f cmd, not.excluded_f cmd] let arc_filter = andf [included_f cmd, not.excluded_f cmd, not.overwrite_f cmd] let arc_filter = andf [included_f cmd, not.excluded_f cmd] -- Best regards, Bulat mailto:bulatz@HotPOP.com

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, Bulat mailto:bulatz@HotPOP.com

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

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. :-)

On 11/18/05, Sebastian Sylvan 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.

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

I always fancied (<>) as a synonym for 'mappend' John -- John Meacham - ⑆repetae.net⑆john⑈

On 11/18/05, Tomasz Zielonka wrote:

On Fri, Nov 18, 2005 at 12:21:09PM +0100, Sebastian Sylvan wrote:

...

On 11/18/05, Tomasz Zielonka 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 (wrrrr...) :-) 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

Hello John, Saturday, November 19, 2005, 2:25:47 AM, you wrote: JM> grep -o ' [-+.*/=^$#@!%]+ ' 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, Bulat mailto:bulatz@HotPOP.com

Fraser Wilson writes:

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.

Good for you. Syntax that changes depending on spacing is my number one gripe with the Haskell syntax. And too many infix operators and symbolic elements are on the list as well. How about a pair of (magical, if necessary) functions called set and get? Letting you do something like x `set` first 4 `set` second "foo" ? -k -- If I haven't seen further, it is by standing in the footprints of giants

Antti-Juhani Kaijanaho wrote:

Ketil Malde wrote: [about A.b and A . b potentially meaning different things:]

...

Syntax that changes depending on spacing is my number one gripe with the Haskell syntax

I've generally considered that one of the good ideas in most current languages (it's not specific to Haskell). ISTR there was a Basic dialect where IFX=0THENX=X+1 and IF X = 0 THEN X = X + 1 meant the same thing.

My point is that e.g. currently "foo? bar", "foo ?bar" and "foo ? bar" have (at least two) different meanings. Hierarchical naming collides with function composition (admittedly only rarely in practice). Template haskell collides with list comprehensions. Do you really think that is such a great idea? -k

On 21/11/05, Henning Thielemann wrote:

On Sat, 19 Nov 2005, Antti-Juhani Kaijanaho wrote:

...

Ketil Malde wrote: [about A.b and A . b potentially meaning different things:]

...

Syntax that changes depending on spacing is my number one gripe with the Haskell syntax

I also think that it is problematic that a character which can be part of an alpha-numeric identifier can also be part of an infix operator identifier. This is the cause of the relevance of the spacing. 'A+b' and 'A + b' always mean the same, but 'A.b' and 'A . b' do not. Very confusing.

This really isn't so bad in practice though. I've certainly never been confused by it. You'd have to go out of your way to construct a situation in which it's potentially confusing, which is something that might be relevant in the IOHCC, but not in ordinary programming. There are much more important issues to deal with than this, really. In a sane language, small amounts of whitespace sensitivity are going to be around no matter what you do. We use whitespace to denote function application. I can't write fx to mean f x. This is a good thing. The same perhaps ought to apply to operators. It would be nice sometimes to be able to use '-' as a hyphen in the middle of names. - Cale

Just my 2p worth... If I were designing a language I would not have used the '.' like Haskell does. One problem is that ascii does not support enough symbols (Hmm, PL1 here we come). I guess my vote would go to keeping the '.' as is to not break existing programs, and using a different symbol for record access and qualified names... however '.' works well for DNS names: a@f -- function composition (people are used to reading the @ backwards due to emails) M.f -- qualified naming... f?f -- record access... really needs more symbols... of course the problem then becomes entering them on a "normal" keyboard. Keean. Ketil Malde wrote:

Cale Gibbard writes:

...

This really isn't so bad in practice though. I've certainly never been confused by it.

Well, what can I say? Good for you?

...

You'd have to go out of your way to construct a situation in which it's potentially confusing

No.

...

There are much more important issues to deal with than this, really.

Like inventing as many new and wonderful symbolic operators as possible! Hey, why not allow quoted function names? So that I can defined a function "f " different from "f "? Or differentiate (+4) from completely different (+ 4), ( +4) and ( + 4) which *obviously* are entirely differen things?

...

might be relevant in the IOHCC, but not in ordinary programming.

So why not go for the Obfuscated Language Design Contest instead?

...

In a sane language, small amounts of whitespace sensitivity are going to be around no matter what you do.

And if you already are using whitespace to separate words, surely the logical (not to mention aesthetical) way forward would be to introduce evene more whitespace sensitivity - here is the Holy Grail http://compsoc.dur.ac.uk/whitespace/index.php

I don't understand why this isn't obvious to people who generally appear fairly bright, but: introducing extension that turns working programs into non-working ones is generally a bad idea. Having it be due to spacing habits around symbolic operators is worse. That spacing changes suddenly starts bringing very complex language extensions into the picture, with an associated heap of incomprehensible error messages is *not* a nice thing for anybody - except, perhaps, the two academics who wrote the paper, and the three academics who read it.

--------------------

</rant>

Okay, I'm being unfair here. Haskell is an academic language, its primary purpose is to produce papers, not software. And as a mere programmer, I'm in a minority. I think Haskell is really cool, but I don't really belong here, and I realize of course that my voice isn't going to carry a lot of weight.

But IF there is a desire for Haskell to be used for Real Work, I think there should be a certain degree of stability. Taking the function composition operator and turning it into record selection -- depending on spacing, of course -- is, IMO, madness.

But good luck on those papers, and see you later, probably on the Clean mailing lists.

-k

--- Sven Panne wrote:

I think this discussion has reached a point where it is of utmost importance to re-read "Wadler's Law of Language Design", a law so fundamental to

computer science that it can only be compared to quantum dynamics in physics:

http://www.informatik.uni-kiel.de/~mh/curry/listarchive/0017.html

:-)

Cheers, S.

To be honest, I haven't followed the entire records thread (at least not yet), but I don't know that it's fair to say that we've been focusing entirely (or nearly so) on lexical issues. I'll grant you that there's an awful lot of that going on, but unless I'm missin something obvious, support for a record data type isn't even a purely syntactic issue. If records are to be supported, they need to have semantics, and it's not obvious to me how this is to be done in a functional language. That being said, this is a matter of some interest to me, primarily because I've been thinking about how to go about using Haskell with (not necessarily relational) databases, and it seems awkward to use a tuple or heterogenous list in a context where new attributes can be added to existing data. Now, of course, that's a puzzle in it's own right: How on earth can you achieve anything like referential transparency here? === Gregory Woodhouse "Interaction is the mind-body problem of computing." --Philip Wadler

Ketil Malde wrote:

Cale Gibbard writes:

...

This really isn't so bad in practice though. I've certainly never been confused by it.

Well, what can I say? Good for you?

...

You'd have to go out of your way to construct a situation in which it's potentially confusing

No.

...

There are much more important issues to deal with than this, really.

Like inventing as many new and wonderful symbolic operators as possible! Hey, why not allow quoted function names? So that I can defined a function "f " different from "f "? Or differentiate (+4) from completely different (+ 4), ( +4) and ( + 4) which *obviously* are entirely differen things?

...

might be relevant in the IOHCC, but not in ordinary programming.

So why not go for the Obfuscated Language Design Contest instead?

...

In a sane language, small amounts of whitespace sensitivity are going to be around no matter what you do.

And if you already are using whitespace to separate words, surely the logical (not to mention aesthetical) way forward would be to introduce evene more whitespace sensitivity - here is the Holy Grail http://compsoc.dur.ac.uk/whitespace/index.php

I don't understand why this isn't obvious to people who generally appear fairly bright, but: introducing extension that turns working programs into non-working ones is generally a bad idea. Having it be due to spacing habits around symbolic operators is worse. That spacing changes suddenly starts bringing very complex language extensions into the picture, with an associated heap of incomprehensible error messages is *not* a nice thing for anybody - except, perhaps, the two academics who wrote the paper, and the three academics who read it.

--------------------

</rant>

Okay, I'm being unfair here. Haskell is an academic language, its primary purpose is to produce papers, not software. And as a mere programmer, I'm in a minority. I think Haskell is really cool, but I don't really belong here, and I realize of course that my voice isn't going to carry a lot of weight.

But IF there is a desire for Haskell to be used for Real Work, I think there should be a certain degree of stability. Taking the function composition operator and turning it into record selection -- depending on spacing, of course -- is, IMO, madness.

But good luck on those papers, and see you later, probably on the Clean mailing lists.

-k

Speaking about Clean... Clean uses record.field for record selections and it combines record syntax (using field names) with array syntax (using indices) in a nice way IMHO. Function composition is defined as: (o) f g = \x -> f (g x) Using the lower case letter o as an approximation to the mathematical symbol. (Actually, it is a macro, but that is a totally different thread.) http://www.cs.ru.nl/~clean/CleanExtra/report20/chapter5/s52.html may give some inspiration for new record syntax (and maybe array syntax). I'm sorry for promoting Clean on a Haskell list, but both languages are very similar yet they have a very different approach to records, so it might be interesting to compare them. kind regards, Arjen

On Tue, Nov 22, 2005 at 07:09:33AM +0200, Antti-Juhani Kaijanaho wrote:

Henning Thielemann wrote:

...

...

Hence, spacing being significant is not Haskell-specific

So Haskell is somehow BASICish -- how awful.

No, you got it backwards. I was contrasting a BASIC dialect as an example of a space-*in*sensitive language to just about every modern language, including Haskell. In other words, Haskell was specifically *not* like BASIC in my comparison.

I believe early FORTRAN is another example of a spacing-*in*sensitive language comparable to that BASIC dialect, and *not* similar to Haskell.

Aren't C and C++ space insensitive (except the preprocessor)? Best regards Tomasz

On Tue, Nov 22, 2005 at 10:39:22AM +0200, Antti-Juhani Kaijanaho wrote:

Tomasz Zielonka wrote:

...

Aren't C and C++ space insensitive (except the preprocessor)? (In a totally space insensitive language, "andy" and "and y" would be tokenized the same way.)

Ah, I was wrong, here are some examples: int a; inta; + + a; ++a; map map Best regards Tomasz