Ramana, On 30 Sep 2011, at 14:49, Ramana Kumar wrote:
> The syntax reference here > http://www.csci.csusb.edu/dick/samples/ml.syntax.html#Specification > suggests that I should be able to write > > signature foo = sig > local open CharVectorSlice in > val baz : vector -> slice > end > end > > (making use of "other_spec" in the syntax reference above) > > But PolyML complains when it hits the "local" > > Poly/ML 5.4.1 Release >> use"foo.sig"; > Error- in 'foo.sig', line 2. > end expected but local was found > > Am I wrong in thinking that that is a valid signature specification? > Is there an official reference for the syntax of the language PolyML > compiles? I believe Poly/ML is intended to conform with Milner, Tofte, Harper & MacQueen's "The Definition of Standard ML (Revised)". I don't know of an online reference for the syntax. This feature was removed from Standard ML in the 1997 revision of the standard: to quote section G.17: "open and local specifications have been criticised on the grounds of programming methodology." The criticism being in the paper "A Critique of Standard ML" by Andrew Appel, which in my opinion did a great deal of harm. In this case, it either forces you to use long identifers (StructureName1.thing) in your signatures (which is sometimes extremely bad for readability), or you have to "include" which includes one signature in another, so that the namespace gets wider and wider (which is my idea of bad programming methodology). I was forced to do the latter in some cases when I ported ProofPower to SML'97 and it is extremely annoying. Typically, David MacQueen's own compiler, Standard ML of New Jersey, has a non-standard extension that mitigates this omission from SML'97 (you can open a structure locally around the signature declaration thus: local open CharVectorSlice in signature foo = sig val baz : vector -> slice end end but this is not allowed by the standard). > > Do I have to keep repeating LongStructureName.type_i_want in my > specifications? Or maybe it is typical to just export types liberally > (because I could do type v = CharVectorSlice.vector at the top of that > signature, etc.) Or as mentioned above, you can use "include". Personally, I prefer to do that (or use long identifiers) to introducing extra type abbreviations into the namespace, but you can certainly do the latter if you are happy with it. Regards, Rob. > _______________________________________________ > polyml mailing list > [email protected] > http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
