[clean-list] Wish list, part 3

[Marco Kesseler]

Hi Richard,

>Someone wrote:
[snip]
that's me
	
>And someone else wrote:
[snap]
that's Erik
	
>YOW!  Are we in never-never land here, or in a world where programming
>is done by fallible human beings?  Clean is supposed to be useful for
>writing real programs; a notation where you can't tell where the words
>begin and end without a map would be disastrous.

I don't think that we disagree.

>There's only one language family I use regularly where "all symbols are
>separated by whitespace (and brackets)", and that's Lisp.  Lisp can get
>away with it because it has *no* infix operators.  x+y might as well be
>a symbol because there isn't anything else it could be.

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

Therefore, I think that it is useful to have at least some form of 
annotating identifiers. That does not mean that I am prepared to 
throw overboard all other goodies. This is not my biggest wish.

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.

>At the last count I had used over 120 different programming languages,
>including some without operators, some with a fixed set of operators,
>and some with user-defined operators.
>
>There is precisely one language that I've come across that lets you have
>+ operators, including user-defined operators,
>AND
>+ tokens containing both letters and operator symbols.
>That's Pop-11.  If I recall correctly, the syntax is like this:
>
>    <word> ::= <syllable 1> {'_' <syllable n>}*
>    <syllable 1> ::= <letter> {<letter> | <digit>}*
>		  |  <operator character>+
>    <syllable n> ::= {<letter> | <digit>}+
>		  |  <operator character>+
>
>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.

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

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

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

But maybe it is just me.

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

regards,
Marco