[clean-list] Wish list, part 3

[Richard A. O'Keefe]

Marco Kesseler <m.wittebrood@mailbox.kun.nl> wrote:
	I don't think that we disagree.
	
	Okay, but consider this. Clean has user-definable infix operators 
	with priorities, and it has ordinary prefix functions, and it has 
	currying, and it does not require you to write down types (and it has 
	algebraic types with the possibilty for infix constructors).
	
	So, if you encounter a sequence 'a b c d e f' in Clean that somebody 
	else wrote, then what does that mean? Where are the functions, where 
	are the arguments (and where are the constructors)?
	
Well, we know there _aren't_ any constructors in 'a b c d e f',
because constructors must start with a capital latter.  In the absence
of user-provided operator fixity declarations, it has a unique parse;
'a' is the function and 'b c d e f' are its arguments.

In the presence of user-provided operator fixity declarations,
it is unambiguous once we know what those declarations are, and they
must be either in the module we are looking at or the module declarations
it imports.

This isn't particularly wonderful, and that's precisely why I think
that Haskell's approach here is brilliantly right:  you can use an
identifier as an operator, but only if you enclose it in backquotes.
a `b` c `d` e f
is reasonably clear.

Having said that I don't think Clean made the best choice here,
this nastiness is at least two decimal orders of magnitude less
nasty than not even be able to tell where the token boundaries are!

	On the other hand, if expressions like 'n+1' are the main reason
	that prohibits this form of annotation, I AM prepared to doubt
	whether writing arithmetic expressions without spaces is such a
	great good for software development.

In expressions that involve more than one operator, I find it important
to discriminate precedence levels visually.  If I write
	x + y*z
it is visually obvious that the * governs y, not x + y.  Thoughtfully
used, omitting spaces in places where they do not have to be CAN be a
useful good for software development.  (Mild digression:  where _did_
the fashion amongst certain lawyers and business people of using a
hyphen instead of a decimal point arise?  Why did anyone ever think
that writing one hundred dollars and fifty cents as $100-50 was a good
idea?  I have seen this too often to be amused any longer.)
	
	>That made tokens like symbol_+, symbol_*, and symbol_? available,
	>while in symbol+..., symbol*..., and symbol?.... the letters and the
	>would have to be in separate tokens, making x+1 unamiguously three
	>tokens and x_+ 1 unambiguously two tokens.
	
	I don't reject such solutions. But I do want a clear trade-off 
	between various syntactical features.
	
I don't understand this.  Can you explain more fully?

	>The only thing I personally would change in Clean's syntax is to
	>change 'if e1 e2 e3' to 'if e1 then e2 else e3'.  This would actually
	>reduce the number of tokens I have to write, because I usually have
	>to wrap parentheses around the expressions so they are parsed correctly.
	
	Can I put that on the wish list?

Certainly.
	
	>Clean's list syntax is _perfect_, and I wish Haskell would adopt it.
	
	It's not bad. It has its advantages, but there are issues too.
	
The only issue I can think of is that it isn't the same as every other
functional language.  But : is different from ML's :: anyway, so there's
no way to be the same as _everyone_ else (and Prolog used ., not :).
A great advantage is that "here is a list pattern or expression
IF AND ONLY IF here is a square bracket".  I find it unpleasant,
confusing, and error-proner I can write [a,b,c] in Haskell but have to
write (a:b:c:xs) if I want the tail.

	Talking about real programs.  The problem with lists that I
	sometimes encounter is that there is no room for error
	information.  So, I end up writing my own lists, that allow
	error elements.  As a result, I have code in wich the only use
	for square brackets is for array selection (not for array types).
	
So?  No matter _what_ the list notation is, if you want to use a different
data structure you had better use different notation.

	>I suggest that the remedy for anyone who doesn't like Clean's syntax,
	>especially someone who is happy writing combinator-based parsers, is
	>to write a preprocessor to convert the syntax they do like to Clean.
	>(And of course share it to build up the number of 'converts'.)
	
	Aha: YACCC (yes with an extra C).
	
	In general, I do NOT like the idea that anyone writes his/her own 
	syntax, because that would really hurt software development. I would 
	rather have Clean powerful enough to avoid this. Parsers may be an 
	exception.
	
We are not talking about using an extensible language, where each
program uses a different syntax.  Hang on, that's what _you're_
suggesting.  I _don't_ want Clean to be 'powerful' in this area; I
want it to be clean and simple.

I quite agree that extensible languages have not always been used in
a way that helps software sharing.  My proposal is much more
responsible than that, simply that people should TRY OUT syntax
proposals before suggesting their adoption.