Poly/ML

polyml@lists.polyml.org

695 discussions

namespacing a functor in a nested module
by philneaton95＠gmail.com 02 Mar '16

02 Mar '16

Hello list, I am building a library with nested modules. There happen to be certain functors within certain nested modules. Here is an example: mylib/ml_bind.ML ============== structure Mylib = struct structure B = B end mylib/B/C.sml ============== structure C = struct end (* Here so C.sml is discoverable *) signature Sig = sig ... end functor CFunctor (S: Sig) = struct ... end mylib/B/ml_bind.ML ============== structure B = struct local open C in end end I want the CFunctor to be exported both inside the library and to the end-user using the library. This is the only way I could get the library to compile because Poly/ML (and the standard) does not support functors within structs or signatures. This works, but CFunctor is now in the "global" namespace - this is just really ugly. Is there any way to get Poly/ML to export CFunctor within the Mylib.B namespace? On a separate note, is there a namespace to access the Basis namespace? For instance if I redefine a String structure within Mylib and want to reference the basis String structure, I get a circular dependency error. I was able to solve this by explicitly creating a Basis structure with an internal structure String in my "build.sml" script that makes Mylib and the files that depend on it. However, I'd rather do this within the library itself and not rely on the user to provide this namespace. Thank you! -- Phil Eaton

1 0

Fixed precision int and compatibility
by David.Matthews＠prolingua.co.uk 24 Feb '16

24 Feb '16

Thanks for the various comments on fixed precision integer. I've now implemented two different mechanisms for compatibility with arbitrary precision int. There is a configure option --enable-intinf-as-int. This causes polyimport to build the basis library with int as arbitrary precision integer rather than fixed precision. The second mechanism is to build a module. Calling PolyML.loadModule "IntAsIntInf"; loads a module that sets the compiler's default overloading to arbitrary precision and loads replacements for most of the basis library. I added modules to Poly/ML 5.6 as a way of providing extensions to the existing basis library and this is the first example. Note that this assumes that "poly" has been installed using "make install" and the module has been copied to its installation location. If you're testing it within the build tree you need PolyML.loadModule "modules/IntAsIntInf/IntAsIntInf"; There are a few cases that aren't covered but they are only likely to affect a few people. Specifically, when installing pretty printers the "depth" argument is always FixedInt.int. There may be a few other case where functions are tightly integrated into the compiler. The IntAsIntInf module covers most of the basis library but currently excludes socket IO and a few other cases. It can probably be extended as necessary. David

2 2

Poly/ML on Stackoverflow
by makarius＠sketis.net 18 Feb '16

18 Feb '16

Dear friends of the best unknown programming language on the planet. Someone with sufficiently many points on Stackoverflow has recently created a "polyml" tag. I have already brushed up its wiki http://stackoverflow.com/tags/polyml/info and added the tag to some existing questions. Often there is the odd situation that people ask questions about "ml" or "sml" and can only think of "smlnj" as the one and only implementation. People on this mailing list should know better, and are invited to populate the "polyml" section of Stackoverflow further. (It has presently 2 followers and 18 questions.) It is also possible to vote for questions and answers that are relevant for Poly/ML, and thus improve its visibility. Makarius

2 1

Fixed precision int
by David.Matthews＠prolingua.co.uk 10 Feb '16

10 Feb '16

Anthony, I'm copying the mailing list to my replies because this is of general interest. On 10/02/2016 16:02, Anthony Fox wrote: > I just occurred to me that I could have done: > > structure Int :> INTEGER = IntInf > > if I wanted IntInf everywhere (rather than having the choice of fixed ot arbitrary). I still think it would be nice to have a command line option for this? At the very least, this way of getting the old behaviour should be advertised. > That would work if you use the Int structure but there are lots of places that pick up the default "int". For instance, if you have an overloaded function: fun f x y = x+y; that will fall back to the default "int". Also, all the library functions that use "int" e.g. Array.sub, String.size, List.length or TextIO.inputN, will still have the fixed precision int. I'm inclined to think that having a "configure" option would be the answer. David

3 3

Fixed precision int
by David.Matthews＠prolingua.co.uk 10 Feb '16

10 Feb '16

On 10/02/2016 16:18, Anthony Fox wrote: >> Can you provide some more information and try to narrow the problem down? There certainly shouldn't be bus errors or segmentation faults anywhere. > > I removed the files > > $POLYDIR/lib/libpoly* > > before doing an Poly/ML install and that seemed to fix things. OK. The libraries have the same version number as the last release so that may cause problems. I seem to recall reading that one was supposed to increment the version number just before a release but maybe it would be better to increment the version immediately after so that versions from git always have a different version from the last release. David

1 0

Fixed precision int
by David.Matthews＠prolingua.co.uk 10 Feb '16

10 Feb '16

On 10/02/2016 15:41, Anthony Fox wrote: > This is significant change. Would it be possible to make this user selectable? MLton has the command line flag > > -default-type intinf > > when IntInf is preferred for Int. Perhaps there could be a switch to "configure". It's really a question of how the basis library is built. > I had been programming on the basis that Int was arbitrary precision in Poly/ML. I certainly need IntInf in places and it was very convenient to not have to worry about this sort of thing. Having to use ?to? and ?from? functions is a nuisance. I?ve attempted to update my code for this change and the diff was > > 19 files changed, 334 insertions(+), 275 deletions(-) > > In itself this wasn?t too bad. However, after this I have less confidence in the robustness of the code. Poly/ML programmer?s have not needed to insert ?handle Overflow? before now, which is great advantage over ?performance obsessed? compilers. > > Anyhow, HOL4 doesn?t build using the FixedPrecisionInt branch. An early problem was due to Position.int no longer being the same as Int.int. Then I got a > > Segmentation fault: 11 > > error when trying to build a parser. This problem may be related to > > Bus error: 10 > > errors that I?ve been getting. For example, if I use polyc to compile > > val main = PolyML.rootFunction > > then the resulting program gives this bus error when trying to process anything (such as ?val x = 1;?). Can you provide some more information and try to narrow the problem down? There certainly shouldn't be bus errors or segmentation faults anywhere. David

1 0

Fixed precision int
by David.Matthews＠prolingua.co.uk 10 Feb '16

10 Feb '16

From the start int in Poly/ML has been arbitrary precision. After around thirty years I think it's time to make a change. The current plan is to introduce a fixed precision integer type and use that as the default int. Arbitrary precision will remain as LargeInt.int/IntInf.int. The reason for the change is that it is becoming clear that having arbitrary precision int as the only integer type imposes restrictions on the code both as regards the integer type itself but also more widely. The arbitrary precision type in Poly/ML is implemented using a tagged representation. Small values that will fit in 31/63 bits are represented as the value shifted one bit left and with the bottom bit set. Larger values are represented as pointers to arrays of bytes, either in the GMP format or Poly's own format. Since pointers are always word-aligned it's possible to distinguish the two forms by looking at the bottom bit. The "tag-bit" also serves another purpose. The garbage-collector can use it to distinguish pointers from non-pointers so all non-pointer values, e.g. bool, char and word, are represented using the tagged form. Arbitrary precision operations are handled directly by the code-generator. The idea is that when the values are small, as they usually are, the machine can execute the appropriate instruction directly. For example, addition is generated as an add instruction. It is preceded by a test on the tags and followed by a test for overflow. If the arguments were not tagged or the result overflowed there is a call into the run-time system. This emulates the instruction and returns with the result in the correct register. Emulation has limitations. Currently only (in)equality, comparison, addition and subtraction are emulated. Other operations such as multiplication and division involve calls to assembly code. This means that code that makes significant use of arithmetic incurs overheads even if it only ever uses small values. There is also a more subtle cost. Because emulating addition and subtraction could involve allocating memory on the heap for the long-format result every addition and subtraction could result in a garbage-collection. This means that the registers, which could be holding intermediate results, have to be treated as the roots for the GC. That in turn means that they must always contain either valid pointers or tagged values. This sometimes involves adding extra instructions simply to ensure this is the case. It also means that whenever the code returns from the run-time system to ML all the registers have to be loaded with known values, adding to the cost of a RTS call. The plan is to retain the existing arbitrary precision using the current tagged values but remove emulation. All arbitrary precision operations will involve an ML function call to the assembly code. This will compute the result directly if it is short and call into the run-time system if it is long. This is actually likely to faster than the current scheme if the values are long. Some cases, for example equality between an arbitrary precision value and a short constant, can continue to be handled by the code-generator since they do not require emulation. Fixed precision int will be based on the current short format i.e. 31 bits on 32-bit machines, 63 bits on 63-bit machines. Operations on these can be handled directly by the code-generator. These changes are currently being tested in the FixedPrecisionInt branch. This requires at least one, preferably two, calls to "make compiler" to build a version of the compiler that generates fixed precision operations. For backwards compatibility it does not yet gain all the advantages of the change; in particular it still clears all the registers on return from the run-time system.

1 0

ML debugging within Isabelle/PIDE
by makarius＠sketis.net 04 Feb '16

04 Feb '16

Dear users of the best unknown programming language in the world. Isabelle/ML is based on Poly/ML and thus benefits from the source-level debugger of that implementation of Standard ML. The Prover IDE provides the Debugger dockable to connect to running ML threads, inspect the stack frame with local ML bindings, and evaluate ML expressions in a particular run-time context. More explanations with a screenshot on http://sketis.net/2016/ml-debugging-within-the-prover-ide Makarius

2 11

Assertion `costMin > userGCRatio' failed
by phil.clayton＠lineone.net 28 Jan '16

28 Jan '16

I am getting the following assertion failure with Poly/ML 5.6: eg_test: heapsizing.cpp:602: bool HeapSizeParameters::getCostAndSize(POLYUNSIGNED&, double&, bool): Assertion `costMin > userGCRatio' failed. To get some timing stats, I was running a test application repeatedly to take an average time. It would appear that the sooner I re-run the application after the previous run has terminated, the more likely the above failure is to occur. There is no failure when I run the test once per second manually. Running the test application in quick succession using the command ./eg_test ; ./eg_test gives the failure every 3 to 4 invocations. Is there more information I can provide? Poly/ML 5.5.2 doesn't exhibit this issue. Phil

2 3

Rounding Mode
by jrtc27＠jrtc27.com 27 Jan '16

27 Jan '16

Hi David (cc?d mailing list back in), Of course "bytes 00 00 00 00 00 followed by 00 00 00/01/02" is meant to be "bytes 00 00 00 00 followed by 00 00 00 00/01/02". Regards, James > On 26 Jan 2016, at 14:13, James Clarke <jrtc27 at jrtc27.com> wrote: > > Hi David, > I initially tried to do something like you did (I had val supported = (setRoundingMode TO_NEAREST; true) handle Fail _ => false or similar, and wrapped the whole thing in one if succeeded let ... in () end else ()), but ran into issues where it was failing on x86; I imagine that was because the compiler was performing the operations on constants at compile-time like you said, as it didn?t seem to be following the rounding mode. > > Yes, when I was making the S/390 port, all the streams had streamNo 0 (bytes 00 00 00 00 00 followed by 00 00 00/01/02), so it thought fd 1 and 2 had closed early, causing polyimport to exit with status code 1 without printing anything. The same thing was happening on big-endian 64-bit PPC. > > Regards, > James > >> On 26 Jan 2016, at 14:05, David Matthews <David.Matthews at prolingua.co.uk> wrote: >> >> Hi James, >> I was trying to separate out the change to the tests from the change to reals.cpp. I don't like the idea of changing the test driver and I'd prefer to alter the test itself to deal correctly with the fact that setRoundingMode may raise an exception. I'm aware that it doesn't do that at the moment and it will need your patch or something like it. >> >> You're right that the change I've made is wrong and will also catch the exception raised in "check". Fixing that has, though, shown up a different bug where the compiler is trying to perform the real operations on constants at compile-time before the rounding mode has been set. That didn't show up when they were all top-level expressions. >> >> On your other patch: Was there an issue with the "streamNo" that caused you to make that change? I can see the possibility that unsigned might be different from POLYUNSIGNED (it certainly is on Windows/X64) and that the effect could be to set the wrong part of a word. I'll have to make some further changes because there are now warnings on Windows/64-bit. >> >> Regards, >> David >> >> On 26/01/2016 12:43, James Clarke wrote: >>> Hi, >>> I notice you committed https://github.com/polyml/polyml/commit/891e8122dcca36f9c2e9eea5a3eca7cf5de…. However, as it stands, on armel the calls do not raise an exception like https://github.com/polyml/polyml/pull/16, which could be misleading for the user, as as far as they are aware setting the mode has succeeded (and getting the mode may return the new mode). Also, unless I?m mistaken, you have effectively just completely disabled that test on every platform, as any failure will be caught. >>> >>> Regards, >>> James >>> >>> >>> >>> _______________________________________________ >>> polyml mailing list >>> polyml at inf.ed.ac.uk >>> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml >>> >

2 3

← Newer
1
...
16
17
18
19
20
21
22
...
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