[clean-list] Wish list, part 3

[Marco Kesseler]

>BTW, I had meant 'AnyChar' to include both 'FunnyChar' and alphanumerical
>characters.

Yes, I mistook AnyChar for alphanum. It also occurred to me too late 
that you were actually talking about infix operator syntax, and not 
identifiers in general. I must have been writing too many mails lately.

What I had in mind, were identifiers that may consist of
a) completely ordinary: alphanum starting with alpha as usual
b) completely funny
c) ordinary on the inside but with funny stuff at one or both ends.

Funny on the inside, but ordinary on the outside probably leads to 
psychological damage anyway (also see below).

>To clarify, the below would allow both x<*>y and x <exclusive&&operator> y,
>but not x<exclusive&&operator>y.

This hurts my brain.

>>From: Rinus Plasmeijer <rinus@cs.kun.nl>
>>To: Matt Lye <mlye@idirect.ca>
>>
>> Hi Matt,
>>
>> > This would allow expressions such as +symbol+, *symbol*, ?symbol?,
>> > @node>, <elem>, without creating confusion such as in the n+1 instance.
>>
>> Don't think so. How about  n+m+k? Is it n +m+ k (where +m+ is a symbol) or
>> n + m + k?

I think that humans are very likely to automatically interpret n+m as 
two parts, no matter what syntactical rules exist. So I propose that 
n+m+k should never be an identifier. One could also argue that no 
identifier should start with a character that can be mistaken for a 
monadic operation, if not ended by another funny one (for example, 
don't allow -n, but do allow -n-).

If furthermore, symbols are separated by whitespace (and brackets) we 
get:
n + m + k is an expression with 5 symbols (supposedly 2 additions)
n +m+ k is an expression with 3 symbols (of which the middle one 
seems to be some sort of dyadic operator).

Depending on the context this could be slightly confusing, but well, 
that holds for any badly chosen name. As long as one does not define 
a dyadic arithmetic operator named +m+ there won't be much trouble. 
The compiler will start to complain about unknown identifier '+m+' if 
you forgot the spaces (or give a type error if you had defined +m+ 
somewhere).

>I had a half-formed reason in the back of my head involving pattern matching
>for why I thought that was ok*, but I guess even if it was, it would mean
>trouble for anyone who later created or inadvertently imported +m+ as an
>operator and then tried to figure out why let m = 2 in 1+m+(m^2) was a type
>error instead of seven.

..which of course will not happen if let m = 2 in 1 + m + (m ^ 2) 
were the correct syntax...

Anyway, I doubt we can come up with a complete solution here and now 
(Bummer).

>*(this is why I never joined the military.  "Sir!  I had a half-formed
>reason, sir!".)
Hmmm, I wonder what the military would call a dyadic operator. 
Probably no-one is every allowed an argument, let alone be in the 
middle of two.

regards,
Marco