Poly/ML

polyml@lists.polyml.org

2 participants
698 discussions

Fwd: [Sml-basis-discuss] Evolving the SML Basis Library
by David.Matthews＠prolingua.co.uk 24 Sep '12

24 Sep '12

I received this message from John Reppy just now and thought it might be of interest to the Poly/ML list. In general I'm in favour of evolving libraries rather than the language so I'd tend to look favourably on this but I wondered if there were any views from users of Poly/ML. David -------- Original Message -------- Subject: [Sml-basis-discuss] Evolving the SML Basis Library Date: Mon, 24 Sep 2012 08:15:59 -0500 From: John Reppy <jhr(a)cs.uchicago.edu> To: Sml-basis-discuss(a)mailman.cs.uchicago.edu The SML Basis Library specification was finalized and published about eight years ago. I think that it is past time to consider changes. I see these as falling into three groups: 1) incremental additions of operations to existing modules 2) addition of new signatures, structures, and functors 3) changes to the semantics (including APIs) of existing Basis Library modules We need a process to manage these changes; something like the Scheme RFI (http://srfi.schemers.org) approach should work. We can host the proposals and specifications at Chicago. We also need agreement from maintainers of the major SML implementations that they are willing to support the process by implementing the changes. I hope that this message will start a discussion about the process and provoke suggestions for improvements to the Basis Library (I've got my own list of incremental additions that I'll post soon). - John _______________________________________________ Sml-basis-discuss mailing list Sml-basis-discuss(a)mailman.cs.uchicago.edu https://mailman.cs.uchicago.edu/mailman/listinfo/sml-basis-discuss

2 1

Console i/o issue
by lhe＠it.uu.se 22 Sep '12

22 Sep '12

Hi, I've noticed that Poly/ML handles console I/O differently than at least SML/NJ and Moscow ML. When you read from stdIO in the interactive system, reading starts immediately after the end of the ML compiler input: Poly/ML 5.5.0 Release > TextIO.inputLine TextIO.stdIn;Hello. val it = SOME "Hello.\n": string option ...while in SML/NJ and Moscow ML, reading starts with the next input line: Standard ML of New Jersey v110.74 [built: Tue Jan 31 16:23:10 2012] - TextIO.inputLine TextIO.stdIn; Hello. val it = SOME "Hello.\n" : string option This matters especially if you are writing an interactive program which writes prompts to stdOut. Using Poly/ML, the program must do a dummy read to "consume" the rest of the compiler input before writing a prompt. This causes an incompatibility with SML/NJ and Moscow ML. Worse, if you run a stand-alone application of the program built using Poly/ML there is no compiler input to read, so Poly/ML becomes incompatible with itself... I feel that the reasonable behavior is that of SML/NJ and Moscow ML. Is it possible to change this in Poly/ML? Lars-Henrik Lars-Henrik Eriksson, PhD, Senior Lecturer Computing Science, Dept. of Information Technology, Uppsala University, Sweden E-mail: lhe(a)it.uu.se, Web: http://www.it.uu.se/katalog/lhe?lang=en Phone: +46 18 471 10 57, Mobile: +46 705-36 39 16, Fax: +46 18 51 19 25

4 5

Poly/ML 5.5
by David.Matthews＠prolingua.co.uk 21 Sep '12

21 Sep '12

I have finally released Poly/ML 5.5 on the SourceForge site. I still need to finish the release notes and update the Poly/ML web site. The major change is of course the complete rewrite of the storage management with the garbage-collector now parallelised. In testing the GC sharing pass made a dramatic difference to large Isabelle examples. It would be interesting to know if this makes a difference to other examples. Other major changes are: PolyML.shareCommonData has been parallelised and improved. Support for 64-bit under Windows (Visual Studio or mingw). Object files now use standard "text" and "data" areas when exporting. In particular this means that it is no longer necessary to use --segprot on Mac OS X to avoid a bus error. Libffi is used for the foreign-function interface (CInterface structure). In particular this means that the full range of data types are supported on X86/64. Support for native code on PPC and Sparc has been withdrawn. There are quite a few other minor changes and bug fixes. David

7 11

Type inference issue with phantom types
by phil.clayton＠lineone.net 06 Sep '12

06 Sep '12

I have been making use of phantom types (for encoding a single-inheritance class hierarchy) and have encountered a case where code accepted by MLton does not type check with Poly/ML. After investigating, it appears that MLton, Poly/ML and SML/NJ all take different views on what is a valid program! Attached are two small examples with a slight difference where type checking accepts/rejects as follows: test-1.sml test-2.sml MLton 20100608 accept accept Poly/ML 5.4, latest reject accept SML/NJ 110.73 reject reject I don't know which of the above is consistent with the Definition yet. (I would be very glad if test-1 is a legal program though!) Phil

4 12

End of life for native code Sparc and PPC
by David.Matthews＠prolingua.co.uk 05 Sep '12

05 Sep '12

I'm in the final stages of preparing Poly/ML 5.5 for release and making the pre-built compilers for the various architectures. I have decided not to include support for native code on Sparc and PPC. I don't expect anyone will still be using these architectures for real work and the interpreted version should continue to work. David

1 0

Storage management update
by David.Matthews＠prolingua.co.uk 30 Aug '12

30 Aug '12

The version of Poly/ML in SVN is the result of over a year's work on the storage management. I'm currently testing the final phase of that and I'd be interested in feedback. The garbage collector has been almost completely rewritten and is now parallelised. The minor GC is completely different and uses a copying collector rather than the mark-sweep scheme used for major collections. The final phase is the heap sizing strategy. From the user's point of view the main differences are the options that control the heap management. The old --heap, --mutable and --immutable arguments have been removed. In their place are a new set of arguments: --minheap, --maxheap, --gcpercent and --gcthreads. I have retained the -H argument as a synonym for --minheap. The storage management adjusts the heap size within the range --minheap (default 1/8th of the physical memory) to --maxheap (default 100% of the physical memory) to keep the garbage collection overhead close to --gcpercent (default 10%). If it detects paging it may reduce the heap size to try to avoid paging since the effect of paging is to slow the whole execution down quite substantially. In that case the GC overhead will rise above the target. If necessary it may run an extra "sharing" pass in the GC to reduce the heap size. This is a sort of cut-down version of PolyML.shareCommonData. It adds a considerable overhead to the GC so is only run when absolutely necessary but reducing the live data size can allow a program to proceed when it is bumping up against the --maxheap limit or the paging limit. The overall aim is to try to adjust the heap size for optimum performance with a wide range of programs on a wide range of memory sizes. The larger the heap available the less frequent the GC needs to run so the faster the program runs. This holds up to the point that paging sets in. The available memory, though, depends on what else is running on the machine so in general the heap starts off small and grows while watching for paging. If you know how much memory you have available you may get better performance by setting --minheap and --maxheap. The --gcthreads option sets the number of threads to be used for the parallel GC. The default, 0, uses as many threads as there are processors (cores) on the machine. Setting this to 1 makes the GC single-threaded. It's probably best left at the default unless you want to run other programs at the same time on other cores. I have tested the latest version with Isabelle, primarily on 64-bit Linux. The paging avoidance seems to work well and even large examples will run in 2Gbytes. I haven't tested it much on other platforms. I did notice occasional cases of poly being killed by the over-commit manager. This was fixed by increasing the amount of swap space available. I'd be interested in feedback, particularly if there are pathological cases where the performance is significantly worse. David

2 3

From SML/NJ to Poly/ML
by Gael.Mulat＠mathworks.fr 24 Aug '12

24 Aug '12

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.

9 20

Word31 from SMLNJ
by Gael.Mulat＠mathworks.fr 23 Aug '12

23 Aug '12

Hi, Trying to port my code from SML/NJ to Poly/ML, I'm stuck with the Word31 structure. In SML/NJ, Word = Word31 and WORD signature defines operators <<, >> and ~>> like this: val op << : word * Word31.word -> word This means that Word31 is the right operand for this operator, even in word32 and in Word64 structures. My code base is built on this signature (would be hard to change it everywhere; and would no more be OK for SML/NJ). Does someone have a trick to port this to Poly/ML ? Thanks, Gael.

4 6

CInterface and CType union
by pabourdi＠laas.fr 23 Aug '12

23 Aug '12

Hi, i'm looking for an easy way to map CType union. By easy way i mean, either a Conversion or a make_union/break_union. Having a look at the source code of CInterface, i see that conversion are managed by a union signature so i guess there's a way. But is there a solution that already exists ? Regards, Pierre-Alain

3 7

Emacs mode
by Gael.Mulat＠mathworks.fr 17 Aug '12

17 Aug '12

Hi, I'm new to Poly/ML. I'd like to start using it, but I still have to work with SML/NJ. I use the well-known sml-mode-4.0. What should I use also to be able to work both with SML/NJ and Poly/ML? I've found this link: http://www.cs.cmu.edu/~fp/courses/98-linear/lib/emacs/sml-poly-ml.el Allows to start. But I'm not able to go back to SML/NJ after using Poly/ML. And 'next-error seems to be missing. Would someone have advices there? Thanks, Gael.

2 1

← Newer
1
...
32
33
34
35
36
37
38
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Poly/ML