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