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.
_______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
