"2m.6" is interpreted as multiplication

[sandeepsengupta]

Hello! I just wanted to ask if this is intended behavior:

evaluate("2m.6")
    1.2 m
evaluate("2m6")
    Error: Undefined symbol m6

I would have expected both of these to be considered invalid input, so I was surprised to find out that "2m.6" (with no parentheses) is interpreted as the product (2 m)(.6).

[MLuc24]

It is not a special case anyone designed — it falls out of two rules that are each deliberate on their own, and the difference between your two examples is purely about which characters may continue an identifier.

A symbol starts on an alpha character and then keeps going while the next one is alpha or a digit:

if (parse.isAlpha(currentCharacter(state), prevCharacter(state), nextCharacter(state))) {
  while (parse.isAlpha(...) || parse.isDigit(currentCharacter(state))) {

A dot is neither, and isDigitDot puts it firmly on the number side instead:

parse.isDigitDot = function isDigitDot (c) {
  return ((c >= '0' && c <= '9') || c === '.')
}

So 2m6 tokenises as 2 followed by the single symbol m6, which is undefined — exactly the error you got. 2m.6 tokenises as 2, then the symbol m (the loop stops dead at the dot), then the number .6. Three tokens, and implicit multiplication then joins them.

The joining is intentional and the source says so in as many words:

// symbol:      implicit multiplication like '2a', '(2+3)a', 'a b'
// number:      implicit multiplication like '(2+3)2'

Worth noticing the guard on the number case, because it is what makes the behaviour look inconsistent from outside:

(state.tokenType === TOKENTYPE.NUMBER &&
    !isConstantNode(last) &&
    (!isOperatorNode(last) || last.op === '!')) ||

A number only multiplies implicitly when the thing before it is not a constant. That is why a bare 2 3 does not quietly become 6. In 2m.6 the preceding node by that point is the symbol m, not a constant, so the guard passes and you get (2 m) * 0.6.

So both of your expectations are half right: 2m6 is rejected, but not for the reason it looks like, and 2m.6 is accepted because the parser never sees anything malformed — just a unit and a number sitting next to each other, which is the same shape as 2 m itself. Whether that ought to be rejected anyway is a design call for @josdejong, though tightening it would mean treating a symbol-then-number sequence differently depending on whether whitespace separates them.

[sandeepsengupta]

Thanks for the thorough and prompt analysis! Greatly appreciated.