I have a small issue with the Poly/ML pretty-printer. If you run:
datatype FOO = D of (int * int); infix D; 1 D 2;
Poly/ML prints: val it = D (1, 2) : FOO
Poly/ML will parse D(1, 2) but only because of a non-standard extension that lets you omit the keyword "op" that the Standard ML definition requires before infix operator names used with ordinary function application syntax.
Regards,
Rob.
Rob Arthan wrote:
I have a small issue with the Poly/ML pretty-printer. If you run:
datatype FOO = D of (int * int); infix D; 1 D 2;
Poly/ML prints: val it = D (1, 2) : FOO
Poly/ML will parse D(1, 2) but only because of a non-standard extension that lets you omit the keyword "op" that the Standard ML definition requires before infix operator names used with ordinary function application syntax.
Poly/ML does a reasonable job of printing expressions in a way that enables them to be parsed but there's no guarantee that the output can be parsed without first being manually edited. It's easy enough to construct examples where a value can be printed but the constructors are not actually in scope.
Prior to version 5.3 Poly/ML did take account of the infix environment when printing constructors but that changed in the 5.3 release. From 5.3 the compiler produces a default print function when a datatype is declared and that always uses the prefix form. I did consider having this use an infix form if a constructor had infix status when the datatype was declared but decided that that was only going to be confusing. It wouldn't deal with your example anyway.
Before version 5.3 printing was done by interpreting the type information when the value was actually printed so it was possible to choose either prefix or infix form according to the fixity status at the point of printing. For this to work, though, various hacks were required particularly in the representation of types inside the compiler so that it was possible to find the constructor environment, the set of value constructors and their types for a datatype, from the type of a value. That isn't something that is needed anywhere else and the hacks had various undesirable side-effects such as on printing type information in error messages. I decided to change this to have a printing function associated with the datatype, and also an equality function - removing the need for "structure equality". That then removed the need to be able to get from the type of a value to the constructor environment.
Basically, if you need a value printed out in infix form you've always got the option of installing your own pretty-printer for the type.
Regards, David
On Mon, 6 Sep 2010, David Matthews wrote:
Basically, if you need a value printed out in infix form you've always got the option of installing your own pretty-printer for the type.
Generally, I have also found the new pp setup something to get used to, but now it works so much better than before, since I can embedd my own markup into the pretty trees processed by Poly/ML, for example.
Makarius
Makarius, David,
Thanks for the input on this. I should explain that my example is for a presentation including a demo involving an 11-line LCF-style kernel and a decision procedure that packs as many bugs and infelicities as I could manage into 4 lines. So sadly, writing my own pretty-printer would spoil the point. However, as it is a really trivial program, it will run on New Jersey ML! For a serious LCF-style system, one will always want to write a custom pretty-printer for the abstract data types in the kernel, so this is not an issue of any importance in practice.
Regards,
Rob.
On 8 Sep 2010, at 13:45, Makarius wrote:
On Mon, 6 Sep 2010, David Matthews wrote:
Basically, if you need a value printed out in infix form you've always got the option of installing your own pretty-printer for the type.
Generally, I have also found the new pp setup something to get used to, but now it works so much better than before, since I can embedd my own markup into the pretty trees processed by Poly/ML, for example.
Makarius _______________________________________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml