在设计数字编程语言时，并置乘法的陷阱有哪些？

Question

In lieu of a standard definition (happy to replace if exists), I'll define syntax for multiplication by juxtaposition using a space between symbols or expressions so that:

c = a b  --> c = a * b

(Note: I'm specifically not allowing c=ab --> c = a * b as ab would be the 2-character name of a variable ab ).

This ought to work nicely with parenthesis and order of operations so that

c = a (b + q)       --> c = a * (b + q)
c = (a + p) (b + q) --> c = (a + p) * (b + q)
c = a/p b           --> c = a/p*b

It seems that very few languages (eg, Wolfram Alpha), allow such implied multiplication. I'm wondering why ?

Is this just a pain to parse?

Are there ambiguities?

A keyword-search skim of "A practical approach to type-sensitive parsing" [Sailor & McCorsky 1994] seems to imply that this is possible.

Regarding vote to close due to "primarily opinion-based" : I am not looking for opinions. I'm looking for theoretical reasons why parsing this would be more complex or impossible due to ambiguities.

Answer 1

It's not impossible to parse but there are a number of issues which need to be resolved.

First, x(a+b) could be a product or a function call, depending on whether x is a scalar or a function. To resolve the ambiguity, you need to know what x is, which pretty well requires mandatory declare before use . Even if your language is strongly typed and you don't mind the requirement to declare first, you still ned a somewhat clunky back-channel from the parser to the lexical scanner, or some other parsing hack. (For example, Awk -- which uses juxtaposition for string concatenation -- treats it as a function call if there is no space between the function name and the ( .). You can defer the parse but you might find that you need to reparse the entire expression in order to get precedences right.

A similar ambiguity with unary operators. It's easy enough to insist that a -b is a subtraction, so that the product would be written with parentheses -- a(-b) -- but it complicates the grammar.

Precedence can be confusing for people reading the code, too. Consider n!/k!(nk)! ; if that is the correct way to write the expression, juxtaposition must have a higher precedence than division, but there are those who think that juxtaposition and product should have the same precedence. (This group and includes some of the authors of the SI measurements standard, which recommends not using juxtaposition to write measurements where the expression type has a multiplied denominator.)

In short, a syntax supposedly designed for improved readability can produce confusion and even subtle bugs. That, plus the increase in parsing complexity, raises the question of how much ch real benefit there is in leaving out a few * s.