[clean-list] Wish list, part 3

[Marco Kesseler]

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

My 'where are' questions make little sense if you asume that no user 
defined infix operators exist. But even so (the 'what means' part):
- there are variations in which some of the letters are upper-case, 
meaning they can be either functions or constructors. 
- there may be reason to visually distinguish various kinds of 
functions (the a).
- the arguments (b, c,...) can be functions, or passed arguments, or 
locally defined graphs. There may be reason to visually distinguish 
these. There may even be reason to visually distinguish arguments 
that are all functions, or all passed 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.

I agree that in many cases this is better than having to know what 
the user defined infix operators are. Still, in cases it is clear I 
do like things like:

a and b or c
x before y

and for example:

a <b> c <d> e

where it is not.

Please note that the original wish was not about infix operators 
alone. There are various reasons that one may want to annotate a symbol.

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

I would not want that either.

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

That is very much true.
Personally, I prefer x + (y * z) if priorities are not clear.

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

I am open to many solutions, also to not changing anything. But I do 
want to know what the arguments are.

I find it very useful to know what other languages have done. That in 
itself however does not mean that it is also useful for Clean.

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

I am not proposing to adopt the Haskell solution. And I admit that I 
have no solution for this yet. I just find it a bit of a waste that 
the square bracket notation has been used for a datastructure that is 
actually an ordinary algebraic type, for which already a notation 
exists.

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

The point here is, that lists have a special status, while I find 
this is not always justified.

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

Sounds fair. I wrongly interpreted your remarks as "one can always 
use his/her syntax of choice by writing a preprocessor", effectively 
creating a 'new' language.

Trying things out in this way may not be simple though. In some cases 
the preprocessor will become rather complex. Ordinary discussions 
with examples may just as well convince people.

regards,
Marco