Thank you for these answers. It helps. Still a question about nested patterns (e.g. case x of (0 | 1) => true | _ => false;). I understand this is an extension of the grammar provided by SML/NJ.
The code I'm trying to port to Poly/ML is big, and we have used nested patterns in a lot of functions for years. We manage to compile with MLton thanks to a tool named "defunct" that makes some changes to come back to a more official grammar (nested patterns, nested functors...). I would like to avoid using the defunct tool as I guess it would break the debugging in PolyML. Moreover, I find the SML code much easier to read with nested patterns, as it avoids duplicating the code! Do you think it would be a good idea to extend Poly/ML to support nested patterns ? If so, do you think it would be reasonable effort to extend Poly/ML to support nested patterns ? Thanks, Gael. > -----Original Message----- > From: Makarius [mailto:[email protected]] > Sent: Thursday, August 16, 2012 3:25 PM > To: Gael Mulat > Cc: [email protected] > Subject: Re: [polyml] From SML/NJ to Poly/ML > > On Wed, 15 Aug 2012, Gael Mulat wrote: > > > I am considering using Poly/ML to benefit of its debugger. > > You will also gain a lot of speed, both of the compiler and the compiled code. > > In Isabelle we are supporting both Poly/ML and SML/NJ for many years, but > the SML/NJ part has always been a pain to maintain, because NJ has odd > ideas about SML. > > End-user performance is now in the range of factor 100 that Poly/ML is > better than SML/NJ (on regular 8 core hardware). E.g. see > http://isabelle.in.tum.de/devel/stats/at-sml-dev/HOL-Library.png > http://isabelle.in.tum.de/devel/stats/mac-poly-M8/HOL-Library.png (The > scale in these charts is in minites, and the application is heavy-duty > symbolic > theorem proving.) > > So almost every effort to include Poly/ML in your portfolio will pay off. > > > Makarius _______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
