Thanks for the clarification. I missed that on the initial skim of the article. (And yes, I appreciate the irony of me introducing the 'ambiguity' arguments into a topic which deals specifically with the removal of such) :)
It's still arguable that there could be some ambiguity. The compiler makes sure the statement is interpreted in an unambiguous way on the computer's end, but the writer might still not know which of a number of ways to express what she wants to state.
I went into this design decision, having looked very closely at the specific success of the SHRDLU system (1971?). Local disambiguation was very effective, and Avail goes even further by having exceptionally strong types to help distinguish meaning. We also have grammatical restrictions to express a unique form of precedence rules, and semantic restrictions to statically identify a large number of inappropriate uses of methods, like “dog”[4], which is a compile-time subscript bounds error.
Very true. The core Avail language uses “_=_” for comparison, “_:_” to declare a variable, “_:=_” got assignment, and “_::=_” for constants (think “final”). It also has “_:_:=_” for the case when you want to declare a variable of a general type, but initialize it with something more specific (say a counter that starts at 1).
But yes. There’s a lot of deeply evil things that can be done in Avail, right down to the lexical scanning. Like forbidding certain variable names, or manufacturing a run of tokens every time a certain emoji is encountered. There are also a lot of safeties, like sealing methods to prevent someone overriding “_+_” for [3’s type, 4’s type]->9’s type.
Oh, and writing “x = x + 1;” as a statement will be flagged as a syntax error, because it would produce a Boolean value which is not allowed to be silently discarded like in Java or C. “Discard:_” makes these rarely needed situations absolutely obvious.