Issue with persistence of infixity status

[brandonspark]

Consider the following code fragment:

val << = fn (x, y) => x + y
fun foo x =
  let
    infix <<
  in
    x << 5
  end


val res = 2 << 3

It is rejected by the Standard ML of New Jersey compiler with the following error:

λ ~/P/parse-sml on add-local-dec  rlwrap smlnj test.sml   19:10:08
Standard ML of New Jersey (64-bit) v110.99.1 [built: Mon Apr 19 12:32:21 2021]
[opening test.sml]
test.sml:11.5-11.17 Error: operator is not a function [overload - bad instantiation]
  operator: 'Z[INT]
  in expression:
    2 <<

However, the parser currently accepts the program with:

 ~/P/parse-sml on main ◦ ./main test.sml                 19:10:50

val << = fn (x, y) => x + y
fun foo x =
  let
    infix <<
  in
    x << 5
  end


val res = 2 << 3

Lexing succeeded.
Parsing...

val << = fn (x, y) => (x + y)
fun foo x = let infix << in (x << 5) end
val res = 2 << 3

Parsing succeeded.

This seems to suggest to be that the infdicts are storing information past when they should, if I'm understanding what you were trying to do with the infdicts correctly.

[shwestrick]

I actually think this is correct. Our parser isn't parsing << as an infixed operator, but as a normal identifier. I believe SML/NJ is failing early because it knows that the literal 2 does not have function type (which is what it means by "operator does not have function type")

[shwestrick]

I.e., I think SML/NJ is rejecting this program because it doesn't type check, not because it doesn't parse.

[brandonspark]

Oh - for some reason I thought that it was storing information about infixity to determine whether or not something like 2 << 3 should be parsed as "2 applied to <<, applied to 3" versus "<< applied to (2, 3)".

Nevermind, I think I confused myself - that makes sense. Sorry for the mix-up!