Poly/ML doesn't seem to parse strexps with a signature ascription. IOW, the following productions do not seem to be accepted by Poly/ML:
strexp ::= strexp : sigexp strexp :> sigexp
See Figure 6 on page 13 in the Definition.
I can see that at least a part of the bug is located in the PARSE_DEC.ML file around line 2133.
I encountered this bug while attempting to compile my generics library [1] with Poly/ML. Some of the generics make essential use of the following form of sealing [e.g. at bottom of #2]:
functor WithXXX (...) = let structure Result = struct ... end in Result :> XXX where type (...) t = (...) Result.t end
If I comment out the ascription, Poly/ML seems to compile the code correctly.
-Vesa Karvonen
[1] http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/generic/unstable... [2] http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/generic/unstable...
On Nov 9, 2007 1:05 AM, Vesa Karvonen vesa.a.j.k@gmail.com wrote:
Poly/ML doesn't seem to parse strexps with a signature ascription. IOW, the following productions do not seem to be accepted by Poly/ML:
strexp ::= strexp : sigexp strexp :> sigexp
See Figure 6 on page 13 in the Definition.
Oops, I forgot to include an example with this bug report:
Poly/ML 5.1 Testing
structure Trivial = struct end : sig end ;
Error: ; expected but : was found
Static errors (pass 1)
-Vesa Karvonen
Vesa Karvonen wrote:
Poly/ML doesn't seem to parse strexps with a signature ascription. IOW, the following productions do not seem to be accepted by Poly/ML:
strexp ::= strexp : sigexp strexp :> sigexp
I've fixed this. For some reason it got missed when Poly/ML was updated to ML97 quite a few years ago now. Then, in the space of a week, two different people report it! I had an email from Timothy Bourke a few days ago pointing this out.
By the way, this is fixed in the compiler so it requires make; make bootstrap; make after updating from CVS to rebuild the compiler and then build Poly using the new compiler. "make bootstrap" updates one of the files in the imports directory depending on the architecture you run it on. That may cause conflicts when that file is updated in CVS but the solution is just to remove the updated one and then update again from CVS.
The other, type checking, bug looks to be more complicated so I'll take a look when I get a bit of time.
David.