Hi,
I'm developing in SML for years (so with a big number of lines of code, different projects, in-house libraries, ...). The code compiles well in MLton (for production) and in SML/NJ (for dev and debug).
I am considering using Poly/ML to benefit of its debugger.
I wonder what will be the effort in order to port the code to Poly/ML.
I have already found that:
- The organization of the code has to be adapted: sources.cm and mlb files have to be rewritten in some equivalent for polyml
- Some libraries will be missing (from my first attempt, it seems that smlnj basis is bigger than what is provided in polyml)
- Interfaces with C will have to be adapted (among others: does it exist an easy way to have nlffi in polyml?)
- Some grammar constructs may not be accepted by polyml. For example: case x of (0 | 1) => true | _ => false; is not accepted in polyml
Does someone have such an experience? Are there documents somewhere that give hints? Are there other big tasks to anticipate for this port?
Thanks,
Gael Mulat.
Gael> The organization of the code has to be adapted: sources.cm and Gael> mlb files have to be rewritten in some equivalent for polyml
Yes. I use driver files that are actually written in ML. The PolyML structure (and especially PolyML.Compiler) is your friend.
Gael> Some libraries will be missing (from my first attempt, it seems Gael> that smlnj basis is bigger than what is provided in polyml)
Do you really mean basis, or the smlnj-lib? From the latter, I have ported all of Util, and I'm working (now & then, when I have time) on the rest.
Gael> Interfaces with C will have to be adapted (among others: does it Gael> exist an easy way to have nlffi in polyml?)
Not that I know.
Gael> Some grammar constructs may not be accepted by polyml. For Gael> example: case x of (0 | 1) => true | _ => false; is not accepted Gael> in polyml
This is not Standard ML, so it won't work in MLton, either. In fact I'm pretty sure it is discussed in the "Deviations of SML/NJ" article on MLton wiki.
Gael> The organization of the code has to be adapted: sources.cm and mlb Gael> files have to be rewritten in some equivalent for polyml
Ian> Yes. I use driver files that are actually written in ML. The PolyML structure Ian> (and especially PolyML.Compiler) is your friend.
OK. I have not yet completely understood how to do that. I try to put a ml_bind.ML file in my library folders. But I do not manage to refer to it from another code folder. Seems tricky about the files locations (shall they be given a full path?). Would you have a small example of how to do that?
Gael> Some libraries will be missing (from my first attempt, it seems Gael> that smlnj basis is bigger than what is provided in polyml)
Ian> Do you really mean basis, or the smlnj-lib? From the latter, I have ported all Ian> of Util, and I'm working (now & then, when I have time) on the rest.
I mean smlnj-lib.
Actually, since my question yesterday, I found this very interesting page: http://www.tbrk.org/software/poly_smlnj-lib.html by Timothy Bourke
Following the advices there allowed me to quickly get the smlnj-lib working. Except that I do not manage to add it to the basis directory of polyml (did not find a way to correctly add it in the build.sml file).
Gael> Interfaces with C will have to be adapted (among others: does it Gael> exist an easy way to have nlffi in polyml?)
Not that I know.
Gael> Some grammar constructs may not be accepted by polyml. For Gael> example: case x of (0 | 1) => true | _ => false; is not accepted Gael> in polyml
This is not Standard ML, so it won't work in MLton, either. In fact I'm pretty sure it is discussed in the "Deviations of SML/NJ" article on MLton wiki.
On 16/08/12 00:14, Gael Mulat wrote:
The code compiles well in MLton (for production) and in SML/NJ (for dev and debug).
I am considering using Poly/ML to benefit of its debugger.
I wonder what will be the effort in order to port the code to Poly/ML.
It may be useful to consider separately 1. whether code compiles 2. when code compiles, does it have the desired behaviour
2 mainly relates to the Basis Library: structures such as Int, LargeInt differ across platforms. Also architecture plays a part: compilers with an interactive session determine top-level values using the compile-time environment at whereas MLton will use the (initial) run-time environment. For example, consider a top-level value that depends result of OS.Process.getEnv .
Considering 1, reasons for portability issues relate to the language and the Basis Library. The main factor is probably support for optional structures/functors in the Basis Library. Some compiler-specific reasons that I have found in practice can result in non-portable code are as follows:
MLton
1. The unifying of monomorphic and polymorphic arrays and vectors allows e.g. "abc" : char Vector.vector which won't generally port. See http://www.mlton.org/FAQ (this could usefully be mentioned on http://www.mlton.org/StandardMLPortability too)
Poly/ML
1. Resolves flexible records and overloading using a topdec as the 'surrounding text', which is non-standard, accepting programs that other compilers won't accept without extra type annotations. (See recent messages on mlton-user maillist.)
SML/NJ
1. There are a number of non-standard extensions that are useful, except for writing portable code. These just have to be removed.
2. The only compiler I know that doesn't accept '(op *)' due to end of comment ambiguity.
I have already found that:
-The organization of the code has to be adapted: sources.cm and mlb files have to be rewritten in some equivalent for polyml
PolyML.make automatically loads source files based on module dependencies. This requires filenames to have their module name (with a known extension), which may be an issue for a large existing code base. I haven't found a way for this to work when files are spread across multiple directories though, so I don't use it.
Instead I tend to have a file called 'polyml.sml' that has lines of the form use "<filename>"; These largely mimic a corresponding 'mlton.mlb' file, thought the order of loading must be completely explicit. However, this approach is problematic because such files don't work hierarchically like MLB files: with e.g. use "module1/polyml.sml"; the file is processed in the current directory, not in module1/. For this reason I define a new use function:
fun use file = case OS.Path.splitDirFile file of {dir = "", file} => PolyML.use file | {dir, file} => let open OS.FileSys val curDir = getDir () in ( chDir dir; PolyML.use file; chDir curDir ) handle e => (chDir curDir; raise e) end
-Some libraries will be missing (from my first attempt, it seems that smlnj basis is bigger than what is provided in polyml)
I would say that the SML/NJ library as bundled with MLton stands a good chance of loading in Poly/ML.
-Interfaces with C will have to be adapted (among others: does it exist an easy way to have nlffi in polyml?)
See below.
-Some grammar constructs may not be accepted by polyml. For example: case x of *(0 | 1)* => true | _ => false; is not accepted in polyml
Nested patterns aren't standard. I don't believe that will work with MLton either. Avoid non-standard language features - you will benefit in the long run.
Does someone have such an experience?
I have been using quite a bit of code with both Poly/ML and MLton lately. I know that ProofPower has a substantial amount of code that works with both Poly/ML and SML/NJ.
Are there documents somewhere that give hints?
I don't know of a comprehensive document covering several compilers. That would be useful. I'm making notes on this subject at the moment and would be interested to hear of any portability issues you find.
For MLton, as mentioned above: http://www.mlton.org/StandardMLPortability
Are there other big tasks to anticipate for this port?
Lack of optional parts in the Basis Library may be a big issue.
I think the C interface is possibly the biggest issue. Unfortunately, there is considerable variation across compilers and I don't know of any NLFFI support for Poly/ML. With my GTK+ bindings, I have taken an approach to minimize compiler-specific code, but there is still a little, though less of an issue as it is automatically generated.
I think I heard someone say that Fortran 11(?) has defined a standard C FFI. Whether or not that is true, it is certainly a good idea!
Phil
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
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:makarius@sketis.net] Sent: Thursday, August 16, 2012 3:25 PM To: Gael Mulat Cc: polyml@inf.ed.ac.uk 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
Gael> The code I'm trying to port to Poly/ML is big, and we have used Gael> nested patterns in a lot of functions for years.
A total nitpick: I think most of the SML community knows this extension as "or-patterns", rather than "nested patterns".
On 22/08/2012 08:38, Gael Mulat wrote:
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 ?
Over the years I've taken quite a strong line against extensions. The intention is that Poly/ML follows the Definition of Standard ML (Revised) i.e. ML97. That isn't to say that I couldn't be persuaded otherwise but I think it would require more than this.
David
I'd prefer to see no language extensions at all, except by agreement among the sml community as a whole.
--lcp
On 23 Aug 2012, at 13:02, David Matthews David.Matthews@prolingua.co.uk wrote:
Over the years I've taken quite a strong line against extensions. The intention is that Poly/ML follows the Definition of Standard ML (Revised) i.e. ML97. That isn't to say that I couldn't be persuaded otherwise but I think it would require more than this.
I believe Successor ML (http://successor-ml.org) is a reasonable route for proposing and discusing language extensions. As far as agreement and standardisation goes, it's usually better if the language features are implemented and tested and used and appreciated before they are codified into (normative) standards. Thus it would make sense for compiler implementors to support extensions to the current standard as long as they are hidden behind compiler flags or pragmas or something. This doesn't mean such extensions shouldn't start life as descriptive standards/specifications, which many compiler writers may or may not choose to implement experimentally.
On Thu, Aug 23, 2012 at 1:11 PM, Lawrence Paulson lp15@cam.ac.uk wrote:
I'd prefer to see no language extensions at all, except by agreement among the sml community as a whole.
--lcp
On 23 Aug 2012, at 13:02, David Matthews David.Matthews@prolingua.co.uk wrote:
Over the years I've taken quite a strong line against extensions. The intention is that Poly/ML follows the Definition of Standard ML (Revised) i.e. ML97. That isn't to say that I couldn't be persuaded otherwise but I think it would require more than this.
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
I would understand a simplified process here, as or-patterns are already implemented / used by SML/NJ for a long time.
Gael.
From: polyml-bounces@inf.ed.ac.uk [mailto:polyml-bounces@inf.ed.ac.uk] On Behalf Of Ramana Kumar Sent: Thursday, August 23, 2012 3:35 PM To: Lawrence Paulson Cc: David Matthews; polyml@inf.ed.ac.uk Subject: Re: [polyml] From SML/NJ to Poly/ML
I believe Successor ML (http://successor-ml.org) is a reasonable route for proposing and discusing language extensions. As far as agreement and standardisation goes, it's usually better if the language features are implemented and tested and used and appreciated before they are codified into (normative) standards. Thus it would make sense for compiler implementors to support extensions to the current standard as long as they are hidden behind compiler flags or pragmas or something. This doesn't mean such extensions shouldn't start life as descriptive standards/specifications, which many compiler writers may or may not choose to implement experimentally. On Thu, Aug 23, 2012 at 1:11 PM, Lawrence Paulson <lp15@cam.ac.ukmailto:lp15@cam.ac.uk> wrote: I'd prefer to see no language extensions at all, except by agreement among the sml community as a whole.
--lcp
On 23 Aug 2012, at 13:02, David Matthews <David.Matthews@prolingua.co.ukmailto:David.Matthews@prolingua.co.uk> wrote:
Over the years I've taken quite a strong line against extensions. The intention is that Poly/ML follows the Definition of Standard ML (Revised) i.e. ML97. That isn't to say that I couldn't be persuaded otherwise but I think it would require more than this.
_______________________________________________ polyml mailing list polyml@inf.ed.ac.ukmailto:polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
I personally would welcome a renewed effort to update Standard ML. Successor ML is clearly dead (better than Standard ML, which is ironic given its rather arrogant manifesto), but a small group of well-organised people might be able to put together some modest and well-thought-out revisions to the language. But I don't think that making ad hoc changes to Poly/ML would be a great idea. Larry
On 23 Aug 2012, at 14:34, Ramana Kumar ramana.kumar@gmail.com wrote:
I believe Successor ML (http://successor-ml.org) is a reasonable route for proposing and discusing language extensions. As far as agreement and standardisation goes, it's usually better if the language features are implemented and tested and used and appreciated before they are codified into (normative) standards. Thus it would make sense for compiler implementors to support extensions to the current standard as long as they are hidden behind compiler flags or pragmas or something. This doesn't mean such extensions shouldn't start life as descriptive standards/specifications, which many compiler writers may or may not choose to implement experimentally.
On Thu, Aug 23, 2012 at 1:11 PM, Lawrence Paulson lp15@cam.ac.uk wrote: I'd prefer to see no language extensions at all, except by agreement among the sml community as a whole.
--lcp
On 23 Aug 2012, at 13:02, David Matthews David.Matthews@prolingua.co.uk wrote:
Over the years I've taken quite a strong line against extensions. The intention is that Poly/ML follows the Definition of Standard ML (Revised) i.e. ML97. That isn't to say that I couldn't be persuaded otherwise but I think it would require more than this.
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
I suggest using the existing SML evolution mailing list ( https://mailman.cs.uchicago.edu/mailman/listinfo/sml-evolution), which is currently very low traffic, for the small group of people to discuss the modest revision. That way, the discussion is public and anyone interested in SML is free to join in. (Various people, especially implementers, ought to be invited, of course, too.)
Crary and Harper's Mechanized Definition of SML may be a good starting point for making a revised definition. The list of "immediate" changes on the successor ML wiki page ( http://successor-ml.org/index.php?title=Main_Page#Immediate) would make a respectable final goal for this project.
I suggest that someone going to the ML workshop next month (which is unfortunately not me) take the lead, and see who is interested there.
On Fri, Aug 24, 2012 at 11:12 AM, Lawrence Paulson lp15@cam.ac.uk wrote:
I personally would welcome a renewed effort to update Standard ML. Successor ML is clearly dead (better than Standard ML, which is ironic given its rather arrogant manifesto), but a small group of well-organised people might be able to put together some modest and well-thought-out revisions to the language. But I don't think that making ad hoc changes to Poly/ML would be a great idea. Larry
On 23 Aug 2012, at 14:34, Ramana Kumar ramana.kumar@gmail.com wrote:
I believe Successor ML (http://successor-ml.org) is a reasonable route for proposing and discusing language extensions. As far as agreement and standardisation goes, it's usually better if the language features are implemented and tested and used and appreciated before they are codified into (normative) standards. Thus it would make sense for compiler implementors to support extensions to the current standard as long as they are hidden behind compiler flags or pragmas or something. This doesn't mean such extensions shouldn't start life as descriptive standards/specifications, which many compiler writers may or may not choose to implement experimentally.
On Thu, Aug 23, 2012 at 1:11 PM, Lawrence Paulson lp15@cam.ac.uk wrote:
I'd prefer to see no language extensions at all, except by agreement among the sml community as a whole.
--lcp
On 23 Aug 2012, at 13:02, David Matthews David.Matthews@prolingua.co.uk wrote:
Over the years I've taken quite a strong line against extensions. The intention is that Poly/ML follows the Definition of Standard ML (Revised) i.e. ML97. That isn't to say that I couldn't be persuaded otherwise but I think it would require more than this.
polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
I have to say I'm not convinced by the arguments in favour of tinkering with the language. For all its deficiencies the Revised Definition does give us a document where we can agree on what is or is not Standard ML. The proposals I have seen appear to be fairly minor changes that really make little difference to real coding, perhaps saving a line or two here or there. I really wonder if it is worth the disruption.
I think the problem is that any change seems to involve adding complexity to an already complex language. When I did my PhD I was heavily influenced by Tony Hoare's 1980 Turing Award lecture in which he argued that the successors to a language were usually worse than the original. In his case he was comparing Algol 60 with Algol 68 and Pascal with Ada.
I wonder if it is possible to design a modern, small strict functional language. I certainly think that a language where most of the data is immutable has enormous potential particularly for parallel or distributed applications.
David
On Fri, Aug 24, 2012 at 3:31 PM, David Matthews < David.Matthews@prolingua.co.uk> wrote:
I have to say I'm not convinced by the arguments in favour of tinkering with the language. For all its deficiencies the Revised Definition does give us a document where we can agree on what is or is not Standard ML. The proposals I have seen appear to be fairly minor changes that really make little difference to real coding, perhaps saving a line or two here or there. I really wonder if it is worth the disruption.
I think the problem is that any change seems to involve adding complexity to an already complex language. When I did my PhD I was heavily influenced by Tony Hoare's 1980 Turing Award lecture in which he argued that the successors to a language were usually worse than the original. In his case he was comparing Algol 60 with Algol 68 and Pascal with Ada.
Changes don't have to add complexity. The point here is to make it even possible to add those changes that are actually simplifications (like degrading abstype), or which are simple conveniences (like line comments, or bars before first match clauses).
I wonder if it is possible to design a modern, small strict functional language. I certainly think that a language where most of the data is immutable has enormous potential particularly for parallel or distributed applications.
That sounds like strict Haskell. Certainly the world is missing a pure strict language. (Though Scott Owens does have a formal semantics for such a language, called "MiniML", in HOL4; but the language is nowhere near ready for real use yet.)
David
______________________________**_________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/**mailman/listinfo/polymlhttp://lists.inf.ed.ac.uk/mailman/listinfo/polyml
On Fri, 24 Aug 2012, Ramana Kumar wrote:
Changes don't have to add complexity. The point here is to make it even possible to add those changes that are actually simplifications (like degrading abstype), or which are simple conveniences (like line comments, or bars before first match clauses).
I've never quite understood what was wrong with poor old abstype. When I learned SML in 1993, I was told "abstype is bad, use functors instead". And when the awkward functorial style became unfashionable, there was opaque signature matching :> as newcomer.
Much later we discovered that :> actually has some problems of abstract types and toplevel pretty printing, even in SML/NJ. This proves that the later tinkering on the SML'97 module system was never fully pushed through the implementations, both SML/NJ and Poly/ML. And I've become a happy user of old abstype with old non-opaque signature matching in recent years.
Makarius
An HTML attachment was scrubbed... URL: http://lists.inf.ed.ac.uk/mailman/private/polyml/attachments/20120824/1c5aa3...
On Fri, 24 Aug 2012, Michael Moeller wrote:
Although 'features' are in vogue, SML is well advised to resist. Of course it's nice Poly/ML connects to the net, for example. On the other hand I won't like to see it choked by tons of libraries turning a small nice language into a bloated software monster which can do everything. It surely is a matter of taste what's worth to be kept in a new library and what's up to the programmer. Keeping things clean and simple never did any harm. Think twice before proposing a new feature an experienced programmer is able to develop by himself easily.
I also subscribe to this.
Incidently, I've worked a lot both on Isabelle/ML (based on Poly/ML) and Isabelle/Scala (based on the great thing by Odersky on the JVM) in the past few years.
Even though Scala is suffiently flexible to imitate SML programming style (and a bit more), the two worlds are somehow complementary: ML the super-clean high-performance symbolic computation engine, Scala the huge monster with the industrial-strength JVM stuff in the background.
When I need some socket programming, I do it in a few lines of Scala. When I need sophisticated symbolic manipulations I do it in ML. (Sometimes there is a conceptual overlap, and I get the wrong side in the first go, but it is then reasonably easy to port to the other side.)
So instead of trying to connect to Poly/ML via the C interface, I better use Scala/JVM stuff over an explicit protocol.
What is also interesting to see is how the latest improvements of the Poly/ML runtime system (parallel GC, heap management with online sharing of immutable data) compares to what Oracle tries to achieve with the JVM. Here a very sophisticated runtime system provided single-handedly by David Matthews, there a multi-billion dollar company with thousands of developers. Let's see what Oracle does next to catch up ... :-)
Makarius
On Fri, 24 Aug 2012, Makarius wrote:
When I need some socket programming, I do it in a few lines of Scala. When I need sophisticated symbolic manipulations I do it in ML. (Sometimes there is a conceptual overlap, and I get the wrong side in the first go, but it is then reasonably easy to port to the other side.)
So instead of trying to connect to Poly/ML via the C interface, I better use Scala/JVM stuff over an explicit protocol.
I fully agree to this. Programming languages are tools, not objects of worship. There is no intrinsic magic and in the end it compiles to 'test and jump'. Yes, I've done lots of asm programming back then :)
Regards, Michael
On Thu, 2012-08-23 at 13:11 +0100, Lawrence Paulson wrote:
I'd prefer to see no language extensions at all, except by agreement among the sml community as a whole.
I wonder if the SML community as a whole has suitable processes in place to reach such agreement?
Best regards, Tjark
On Thu, 23 Aug 2012, Lawrence Paulson wrote:
I'd prefer to see no language extensions at all, except by agreement among the sml community as a whole.
This also raises the question how much active SML community is still there -- people doing some actual work in compiler implementation and maintenance. Too much activity in proposing new language features means an extra burden on the rare people who are still there to keep the implementations going.
David Matthews made huge steps forward in the past few years, without ever touching the SML'97 standard as such.
Makarius
-
David.Matthews＠prolingua.co.uk -
Gael.Mulat＠mathworks.fr -
itz＠buug.org -
lp15＠cam.ac.uk -
makarius＠sketis.net -
mmoel＠t-online.de -
phil.clayton＠lineone.net -
ramana.kumar＠gmail.com -
tjark.weber＠gmx.de