Tomasz Zielonka wrote:

On Sat, Feb 04, 2006 at 02:52:20PM -0000, Brian Hulley wrote:

...

Hi - In the Haskell98 report section 4.4.2 $ is specified as being right associative. This means that f $ a0 a1 $ b0 b1 would parse as f (a0 a1 (b0 b1)) which seems rather strange to me. Surely it would be much more useful if $ were defined as left associative so that it could be used to separate the args to f?

Does anyone know why this strange associativity was chosen?

Probably it was anticipated that right associative version will be more useful. You can use it to create a chain of transformations, similar to a chain of composed functions:

(f . g . h) x = f $ g $ h $ x

Example:

map f $ group $ sort $ filter g $ l

But of course, left associative version can also be useful. Some time ago I used a left associative version of the strict application operator, which I named (!$).

I wonder if anyone has done empirical studies to determine scientifically which associativity would be more useful in practice eg by analysis of source code involving $ and comparing the number of parentheses that would be needed in each case, and perhaps also some studies involving the number of confused readers in each case... Even though both versions are useful, it seems to me that faced with the choice of choosing an associativity for an operator that does function application, and given that prefix application is left associative, there is one clear winner, but unfortunately the Haskell committee didn't see it this way, and perhaps it is too late to ever change this (just like :: and : which were mixed up for reasons unknown). Especially since chains can already be composed using "." .

Anyway, you can't always remove all parentheses. And why would you want to? Everybody is used to them.

$'s advertised purpose is to remove parentheses, but I agree that parenthesized code is often more readable (especially when operators have unexpected fixities... :-)) Regards, Brian.

On Sat, Feb 04, 2006 at 07:15:47PM -0000, Brian Hulley wrote:

I think the mystery surrounding :: and : might have been that originally people thought type annotations would hardly ever be needed whereas list cons is often needed, but now that it is regarded as good practice to put a type annotation before every top level value binding, and as the type system becomes more and more complex (eg with GADTs etc), type annotations are now presumably far more common than list cons so it would be good if Haskell Prime would swap these operators back to their de facto universal inter-language standard of list cons and type annotation respectively.

I am not convinced. Even if you really want to write types for every top-level binding, it's only one :: per binding, which can have a definition spanning for many lines and as complicated type as you want. On the other hand, when you are doing complicated list processing, it is not uncommon to have four (or more) :'s per _line_. Personally, I started my FP adventure with OCaml (which has the thing the other way around), and I felt that the meanings of :: and : should be reversed - before I even knew Haskell! Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland

Stefan Holdermans wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Brian wrote:

...

I think the mystery surrounding :: and : might have been that originally people thought type annotations would hardly ever be needed whereas list cons is often needed, but now that it is regarded as good practice to put a type annotation before every top level value binding, and as the type system becomes more and more complex (eg with GADTs etc), type annotations are now presumably far more common than list cons so it would be good if Haskell Prime would swap these operators back to their de facto universal inter-language standard of list cons and type annotation respectively.

I don't think Haskell Prime should be about changing the look and feel of the language.

Perhaps it is just a matter of aesthetics about :: and :, but I really feel these symbols have a de-facto meaning that should have been respected and that Haskell Prime would be a chance to correct this error. However no doubt I'm alone in this view so fair enough - it's just syntax after all and I can run my own programs through a pre-processor if I want them the other way round... :-) Regards, Brian.

On 2006-02-04 at 21:15GMT "Brian Hulley" wrote:

Stefan Holdermans wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Brian wrote:

...

I think the mystery surrounding :: and : might have been that originally people thought type annotations would hardly ever be needed whereas list cons is often needed, but now that it is regarded as good practice to put a type annotation before every top level value binding, and as the type system becomes more and more complex (eg with GADTs etc), type annotations are now presumably far more common than list cons so it would be good if Haskell Prime would swap these operators back to their de facto universal inter-language standard of list cons and type annotation respectively.

I don't think Haskell Prime should be about changing the look and feel of the language.

Perhaps it is just a matter of aesthetics about :: and :, but I really feel these symbols have a de-facto meaning that should have been respected and that Haskell Prime would be a chance to correct this error. However no doubt I'm alone in this view so fair enough

Not exactly alone; I've felt it was wrong ever since we argued about it for the first version of Haskell. ":" for typing is closer to common mathematical notation. But it's far too late to change it now.

- it's just syntax after all

It is indeed. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

On 2006-02-05, Brian Hulley wrote:

Jon Fairbairn wrote:

...

Brian Hulley wrote:

...

<snip>

Not exactly alone; I've felt it was wrong ever since we argued about it for the first version of Haskell. ":" for typing is closer to common mathematical notation.

But it's far too late to change it now.

...

- it's just syntax after all

Well I'm reconsidering my position that it's "just" syntax. Syntax does after all carry a lot of semiotics for us humans, and if there are centuries of use of ":" in mathematics that are just to be discarded because someone in some other language decided to use it for list cons then I think it makes sense to correct this.

It would be impossible to get everything right first time, and I think the Haskell committee did a very good job with Haskell, but just as there can be bugs in a program, so there can also be bugs in a language design, and an interesting question is how these can be addressed.

For example, in the Prolog news group several years ago, there was also a discussion about changing the list cons operator, because Prolog currently uses "." which is much more useful for forming composite names - something which I also think has become a de-facto inter-language standard. Although there was much resistance from certain quarters, several implementations of Prolog had in fact changed their list cons operator (list cons is hardly ever needed in Prolog due to the [Head|Tail] sugar) to reclaim the dot for its "proper" use.

My final suggestion if anyone is interested is as follows:

1) Use ":" for types 2) Use "," instead of ";" in the block syntax so that all brace blocks can be replaced by layout if desired (including record blocks) 3) Use ";" for list cons. ";" is already used for forming lists in natural language, and has the added advantage that (on my keyboard at least) you don't even need to press the shift key! ;-)

Regards, Brian.

If anything, using ',' for block syntax and ';' for lists is backwards. ',' is used for generic lists in English, whereas ';' is used for seperating statements or lists. But I like the current syntax just fine. -- Aaron Denney -><-

Tomasz Zielonka wrote:

On Sun, Feb 05, 2006 at 01:10:24PM -0000, Brian Hulley wrote:

...

2) Use "," instead of ";" in the block syntax so that all brace blocks can be replaced by layout if desired (including record blocks)

Wouldn't it be better to use ; instead of , also for record syntax?

I thought of this also, but the nice thing about using commas everywhere is that it is consistent with tuples and lists: [a,b,c] (a,b,c) {a,b,c} I admit it takes some getting used to to write: map f (h;t) = f h;map f t but you couldn't use commas in tuple syntax if they were also used as list cons. Also, I'm using test :{Eq a, Show a} a -> () instead of test :: (Eq a, Show a) => a->() and the comma here is particularly nice because it suggests a set, which is exactly what the context is. Regards, Brian.

Actually, one of the main reasons that we chose (:) is that that's what Miranda used. So, at the time at least, it was not entirely clear what the "de facto universal inter-language standard" was. In any case, I agree with Stefan regarding Haskell Prime! -Paul Stefan Holdermans wrote:

Brian wrote:

...

I think the mystery surrounding :: and : might have been that originally people thought type annotations would hardly ever be needed whereas list cons is often needed, but now that it is regarded as good practice to put a type annotation before every top level value binding, and as the type system becomes more and more complex (eg with GADTs etc), type annotations are now presumably far more common than list cons so it would be good if Haskell Prime would swap these operators back to their de facto universal inter-language standard of list cons and type annotation respectively.

I don't think Haskell Prime should be about changing the look and feel of the language.

Regards,

Stefan

These lineages are more or less right, except that there is a bit of incest: LML is certainly one of the progenitors of Haskell. (more semantically than syntactically, though) Cheers, --Joe ajb@spamcop.net said:

G'day all.

Quoting Paul Hudak :

...

Actually, one of the main reasons that we chose (:) is that that's what Miranda used. So, at the time at least, it was not entirely clear what the "de facto universal inter-language standard" was.

Exactly. One point that's often not appreciated is that Haskell is not a descendent of ML. The ML lineage is, roughly:

Lisp -> ISWIM -> ML -> SML, LML, O'Caml etc

And the Haskell lineage is:

Lisp -> ISWIM -> SASL -> KRC -> Miranda -> Haskell

ML is much more like an older cousin than an ancestor.

This point is important because Turner languages already had a list syntax at the time that they adopted an ML-like type system.

Cheers, Andrew Bromage _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Joseph H. Fasel, Ph.D. email: jhf@lanl.gov Stockpile-Complex Modeling and Analysis phone: +1 505 667 7158 University of California fax: +1 505 667 2960 Los Alamos National Laboratory post: D-2 MS F609; Los Alamos, NM 87545

[a,b,c ; tail] === a :: b :: c :: tail -- where ::

How is [a,b,c ; tail] simpler, clearer or less typing than a:b:c:tail ? I think that the commas and semicolons are easy to confuse. While we're talking about the aesthetics of "::" and ":", I like how a line with a type annotation stands out strongly with "::", e.g. map :: (a -> b) -> [a] -> [b] Compare this to map : (a -> b) -> [a] -> [b] where the identifier looks more connected to the type. You will notice this is different than ML anyway because in Haskell you can separate the type annotation and the declaration. If you are designing your own langauge, you will of course have your own aesthetics and reasons for doing it your way. As for me, I started to design (in my head) the "perfect" language (for me), but the more I learned and used Haskell, the more I realized how carefully designed it was and how it was better for me to use my efforts to learn from Haskell (especially conceptually, since the syntax is so transparent and the ideas are so amazing) than to try to insert clever ideas to satisfy my own whims. Sure, there are always little things to nitpick, but on the whole, can you think of more succinct language with more power? (and less parentheses!) Plus, what other languages let you more easily add (infix) operators, etc. and change things to fit your whim, anyway (and still be strongly type!). Cheers, Jared. -- http://www.updike.org/~jared/ reverse ")-:"

Brian Hulley wrote:

Jared Updike wrote:

...

...

[a,b,c ; tail] === a :: b :: c :: tail -- where ::

How is [a,b,c ; tail] simpler, clearer or less typing than a:b:c:tail ? I think that the commas and semicolons are easy to confuse.

It seems strange that you can write [a,b,c] with a nice list sugar but if you want to include a tail you have to switch to the infix notation using list cons. Prolog for example allows you to write [a,b,c|Tail] but neither Haskell nor ML allows this. In Haskell, | is used to introduce a list comprehension so I was just trying to find a replacement symbol for when you want the equivalent of the Prolog list sugar so that you wouldn't be forced to use infix notation.

All this was not to replace a:b:c:tail but was to replace a::b::c::tail so that : could be used for type annotations instead.

There is the .. operator which is unused in pattern matching contexts. So maybe case [1,3..] of [a,b,c,tail..] -> tail -- I like this one, the ..] catches the eye better [a,b,c,..tail] -> tail -- I think this is less clear at a glance [a,b,c,..tail..] -> tail -- I expect no one to like this [a,b,c,_..] -> [a,b,c] -- Not the best looking thing I've ever seen [a,b,c,.._] -> [a,b,c] -- ditto [a,b,c,.._..] -> [a,b,c] -- ick But this implies [a,b,c,[]..] is the same as [a,b,c] and [a,b,c,[d,e,f]..] is the same as [a,b,c,d,e,f] and [a,b,c,[d,e,f..]..] is [a,b,c,d,e,f..] Wacky.

G'day all. Quoting Tomasz Zielonka :

Probably it was anticipated that right associative version will be more useful. You can use it to create a chain of transformations, similar to a chain of composed functions:

(f . g . h) x = f $ g $ h $ x

Of course, if $ were left-associative, it would be no less useful here, because you could express this chain thusly: f . g . h $ x This is the way that I normally express it. Partly because I find function application FAR more natural than right-associative application, and partly because I'm hedging my bets for Haskell 2 just in case the standards committee wakes up and notices that the associativity of $ is just plain wrong and decides to fix it. :-) In fact, I'll go out on a limb and claim that ALL such uses of $ are better expressed with composition. Anyone care to come up with a counter-example?

But of course, left associative version can also be useful. Some time ago I used a left associative version of the strict application operator, which I named (!$).

In fact, I think it's much MORE useful, and for precisely the reason that you state: it makes strict application much more natural. Strict application also has the wrong associativity. As it is, $! is only useful if the _last_ argument of a function needs to be strict. I find that ordering my arguments in a de Bruijn-like order (which many experienced functional programmers do unconsciously) results in this being the least common case. The last argument of a function is usually the induction argument: it's almost invariably the subject of a top-level test. The strictness analyser invariably picks up that the argument is strict. It's the OTHER arguments you may need to evaluate early. Suppose you have a function with three arguments, the second of which needs to be strict. I want to write something like this: f (g x) $! (h y) $ (j z) What I have to write is this: (f (g x) $! (h y)) (j z) or this: let y' = h y in y' `seq` f (g x) y' (j z)

Anyway, you can't always remove all parentheses. And why would you want to? Everybody is used to them.

I agree. However, sometimes parentheses make things more confusing. Almost always the best solution is to give the offending subexpression a name, using "let" or "where". However, the specific case above is the only one that I've found where this, too, makes things worse. In summary: There is no good reason to make $ right-associative and at least one good reason to make it left-associative. Cheers, Andrew Bromage

ajb@spamcop.net wrote:

G'day all.

Quoting ajb@spamcop.net:

...

This is the way that I normally express it. Partly because I find function application FAR more natural than right-associative application,

I meant to say that I find function COMPOSITION more natural than right-associative application. It certainly fits better with my personal biases about good functional programming style.

Yes the case you've made for $ being left associative is very compelling - namely that the existing associativity actively encourages a *bad* programming style in which the right associative $ hides the composition in a chain of function applications instead of allowing the composition to be explicit and neatly separate from its argument. Moreover, the existing associativity of $ implies that whoever thought it up was confusing two concepts: application and composition, instead of allowing "$" to take its proper place as an equal citizen to ".", with the associativity proper to its role as application alone. Thus if $ were made left associative in Haskell Prime, this would add clarity to the thought forms associated with the language, which would (presumably) in turn lead to better programs being written in it. Regards, Brian.

Tomasz Zielonka wrote:

The only problem I see right now is related to change locality. If I have a chain like this:

f x y . g x $ z

and I want to add some transformation between g and z I have to change one line and insert another

f x y . g x . h x y $ z

With right-associative $ it would be only one line-add. Probably not a very strong argument.

How about: f x y . g x $ z then you only need to add the line . h x y This is similar to how people often format lists: a = [ first , second , third ] Regards, Brian.

Tomasz Zielonka wrote:

On Sun, Feb 05, 2006 at 01:14:42PM -0000, Brian Hulley wrote:

...

How about:

f x y . g x $ z

then you only need to add the line

. h x y

But then you have a problem when you when you want to add something at the beginning ;-) With right-assoc $ adding at both ends is OK.

...

This is similar to how people often format lists:

a = [ first , second , third ]

I am one of those people, and I am slightly annoyed with I have to add something at the beginning of the list. I even went so far that when I had a list of lists, which were concatenated, I've put an empty list at front:

concat $ [ [] , [...] , [...] . . . ]

Just in case you are interested, in the "preprocessor" I'm writing, I would write these examples as: (.) #> f x y g x h x y $ z and a = #[ first second third where exp #> {e0,e1,...} is sugar for let a = exp in a e0 (a e1 (a ... ) ...)) and #[ {e0, e1, ... } is sugar for [e0, e1, ...] (exp #> block and exp #< block are the right and left associative versions respectively and the special # sugar allows a layout block to be started if it occurs at the end of a line) This allows me to avoid having to type lots of syntax eg repeating the "." all the time and focus on the semantics... Regards, Brian.

Tomasz Zielonka wrote:

On Sun, Feb 05, 2006 at 04:36:44PM -0000, Brian Hulley wrote:

...

Just in case you are interested, in the "preprocessor" I'm writing, I would write these examples as:

(.) #> f x y g x h x y $ z

and a = #[ first second third

where exp #> {e0,e1,...} is sugar for let a = exp in a e0 (a e1 (a ... ) ...)) and #[ {e0, e1, ... } is sugar for [e0, e1, ...] (exp #> block and exp #< block are the right and left associative versions respectively and the special # sugar allows a layout block to be started if it occurs at the end of a line)

Well... I care about change locality and the like, but I'm not sure I would use such syntax (as a means of communication between programmers). Perhaps that's because I am not used to it and it looks alien. But it's rather because I still put readability first.

It is true that it looks quite alien at first, but consider that it allows you to use longer identifiers for function names (because they now only need to be written once) which could actually enhance readability eg Prelude.compose #> f x y g x h x y $ z so perhaps people would start using more real words instead of obscure symbols like >=+=< etc. Also, the less use of infix notation the better, because every infix symbol requires the reader to search for the fixity declaration then try to simulate a precedence parser at the same time as grappling with the semantics of the code itself. The #>, #< notation solves this problem by making the sugared associativity immediately visible, and the use of layout further enhances the direct visual picture of what's happening. Anyway it's just an idea I thought I'd share- I'm sure there's no danger of it ever ending up in a future Haskell... ;-) Regards, Brian.

On Sun, Feb 05, 2006 at 06:58:15PM +0000, Ben Rudiak-Gould wrote:

Tomasz Zielonka wrote:

...

But then you have a problem when you when you want to add something at the beginning ;-)

How about:

id . f x y . g x $ z

Yes, I've thought about it. You are using a neutral element of ., just like I used [] as a neutral element of ++ (or concat). Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland

On Sun, 2006-02-05 at 13:49 +0100, Tomasz Zielonka wrote: . . .

and I want to add some transformation between g and z I have to change one line and insert another

f x y . g x . h x y $ z

With right-associative $ it would be only one line-add. Probably not a very strong argument.

Maybe stronger than you think. I know that one of the arguments for making ";" a C-style delimiter rather than a Pascal-style separator is that adding a new statement at the end of a series is error-prone -- one tends to forget to add the ";" in front of the new statement (and one reason Pascal syntax included the "null" statement was so that "s1;" would parse as "s1; null", making ";" a de facto delimiter). Editing ease matters more than a little. -- Bill Wood

On Sat, Feb 04, 2006 at 08:37:51PM +0100, Stefan Holdermans wrote:

Taral wrote:

...

I think it's very natural. Everything after the $, including other $ expressions, is applied to the stuff before the $. This saves me from a lot of nested parentheses.

To me, ($) helping me to avoid writing lots of parentheses, makes it extremely useful. Actually: except for passing function application to higher-order functions, this is the only way I use it. So, I always thought parentheses were *the* reason for the right- associativity of ($). Not sure if it really was originally, but, ever so, I think it is the best reason.

A left-associative low-precedence application operator can also help avoid writing parentheses, only in different cases, eg. f $$ x + 1 $$ x * x + 2 * x + 1 equals f (x + 1) (x * x + 2 * x + 1) But in this case the parentheses don't nest, which may be a reason why a right-associative version was chosen. ($) helps to avoid the case of nesting parentheses. Such nesting is unbounded, for example you can have chains like this with arbitrary length: a (b (c (d (e (f x))))) even if you only have unary functions. Also, adding or removing a function in such a chain can require non-local changes, that is you are forced to add or remove a closing parenthesis on the end of expression. If you use ($): a $ b $ c $ d $ e $ f x you can easily add or remove a function in the chain. On the other hand, adding new parameters to calls like this f (x + 1) (y - 1) ... is very localised. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland

On Sun, Feb 05, 2006 at 02:27:45AM +0000, Ben Rudiak-Gould wrote:

No one has mentioned yet that it's easy to change the associativity of $ within a module in Haskell 98:

import Prelude hiding (($))

infixl 0 $ f$x = f x

or, for the purists,

import Prelude hiding (($)) import qualified Prelude (($))

infixl 0 $ ($) = (Prelude.$)

But that would break Copy & Paste between modules! ;-) Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland