Rob, Yes, I removed PolyML.Compiler.printTypesWithStructureName. 5.3 does a much better at trying to detect exactly what path is needed to identify a type and always tries to produce the minimal path. This isn't always easy or possible in the presence of sharing, type abbreviations and type and structure renaming since what it's trying to do is get back from the abstract "type name" that represents a unique type to a concrete type constructor that "carries" that type.
For example: Poly/ML 5.3 Enhanced Reporting Testing
structure S = struct datatype t = A val x = A end;
structure S : sig val x : t datatype t = A end (* x just has type t *)
val y = S.x;
val y = A : S.t (* Reports S.t as the path *)
open S;
datatype t = A val x = A : t (* Reports t because it's now in scope *)
x;
val it = A : t (* As above *)
type t = int; (* Redefine t *)
eqtype t
x;
val it = A : S.t (* Now reports S.t because t doesn't mean S.t *)
This makes it difficult to know what printTypesWithStructureName ought to do. Should it suppress all structure prefixes even if they're needed or add them on even if they're not? The simplest answer was to remove it. I could reinstate it for backwards compatibility if it would make things easier and simply ignore the value it has.
Regards, David
Rob Arthan wrote:
I wrote:
I am completely baffled. I thought I hada solved all my problems on MacOS X 10.6 and was just tidying up, when I had to recompile a 32 bit version of Poly/ML to test a tidied up make file. This failed because PolyML.Compiler.printTypesWithStructureName no longer exists. The same problem happened when i rebuild a 64 bit version. What has happened?
but it was a false alarm: my make file was wrong for other reasons and the absence of PolyML.Compiler.printTypesWithStructureName was not relevant. No doubt there are good reasons why this variable has been withdrawn.