On 30 Mar 2012, at 12:52, David Matthews wrote:
On 29/03/2012 16:00, Rob Arthan wrote:
On 27 Mar 2012, at 22:41, Phil Clayton wrote:
For example, given
infix& datatype t =&
Poly/ML (5.4) reports:
Warning-(&) has infix status but was not preceded by op.
So Poly/ML seems to prefer the use of 'op' in a datatype declaration. However, if 'op' is present, i.e.
I've had another look at this and committed a change to the parser. I can't see any reason for producing the warning in this case so I've removed it. I have a vague feeling that in an early draft of Standard ML the syntax of datatype bindings more closely resembled pattern matching so there was a real reason for using "op". Something like datatype 'a list = nil | 'a :: 'a list compared with datatype 'a list = nil | op :: 'a * 'a list
Looking carefully at the syntax, though, "op" is not allowed in a datatype specification although in all other respects the syntax of a binding and a specification are the same. I've added an error message if "op" is used in a specification.
I didn't look at the syntax of modules. You are quite right. In fact, as far as I can see, op is not allowed anywhere in a signature.
Can anything be done to align the warnings from Poly/ML and SML/NJ in this respect?
It is, of course, possible to write local nonfix & in datatype t = & end This should work in both Poly/ML and SML/NJ although I haven't tested SML/NJ here.
(f&);
Error-<identifier> expected but ) was found
I would have expected Poly/ML to give a warning on the exception binding. I also can't explain why it doesn't allow (f&). Maybe David can give a more accurate explanation of when Poly/ML requires op.
I hadn't actually realised that "op" was allowed on exception bindings and I've now fixed that. I think a sensible approach is to produce a warning in the cases where a symbol could be used as an infix; in an expression, a fun binding or in a pattern (val binding) and to ignore it in other cases.
I think it is wise to give the warning in those cases, because other compilers are not as liberal as Poly/ML, so I read the warning as a warning about a potential portability problem (and always act on it).
The reason that "f &" gives an error is that here we have something that could actually be an infixed use of "&" but isn't because the right-hand side is missing. I think it's actually more helpful than producing a warning. For example, val a = 1; val b = a + ; is probably a missing expression. Producing a warning about a missing "op" and then an error saying "a" is not a function could well be more confusing than helpful.
Out of interest, are you still planning to allow things like "(+)"?
Regards,
Rob.