David, Thanks for the info. I don't have any code that needs PolyML.Compiler.printTypesWithStructureName.
Regards, Rob. > 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
