Poly/ML June 2008

polyml@lists.polyml.org

3 participants
4 discussions

structure sharing
by ldixon＠inf.ed.ac.uk 02 Jul '08

02 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been trying to use the module system and come across a few issues, some of which I cannot easily pin down, and one which I can. The issue I can clearly identify concerns what seems to be failure of associativity in structure sharing, and is demonstrated in the following: signature ORD_DATA = sig type data end; signature VERTEX = sig type name type data end; signature BVERTEX = sig structure Boundary : ORD_DATA include VERTEX end; signature GRAPH = sig structure Vertex : VERTEX type T; end; signature BGRAPH = sig include GRAPH; structure BVertex : BVERTEX sharing Vertex = BVertex end; signature RG_VERTEX = sig include BVERTEX where type Boundary.data = unit end; signature RG_GRAPH = sig include BGRAPH structure RGVertex : RG_VERTEX sharing BVertex = RGVertex (* why is it OK if I change BVertex to Vertex? *) end Running this gives the error: Error: in '/tmp/sml25644bEn', line 26. Cannot share: (unit) is a type function Found near sig include BGRAPH structure RGVertex : RG_VERTEX sharing BVertex = RGVertex end Exception- Fail Static errors (pass2) raised Apart from just being confused by what the error means, I am confused that given, in BGraph, "sharing Vertex = BVertex", later I get an error if "BVertex = RGVertex" but not if "Vertex = RGVertex". Is there some subtle (or obvious?) thing I'm missing? Another thing I don't quite understand, but which I suspect is just part of the definition of ML, is that you cannot write "sharing type localtype = globaltype", is there some clever reason why this isn't allowed? Or even "sharing local_structure = global_structure", would sometimes be nice. :) The other issue I have is with the names given to types being printed in error messages; is there any way to control this? I sometimes seem to get mis-typed types; which makes errors hard to spot. A common thing I find is that a parameterised type loses it's parameter. I have example of this I can repeat, but they require a large amount of code... I'll try to find a smaller example. any suggestions/corrections/infomration, and possibly bug fixes, very welcome! :) cheers, lucas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFINuQvogMqU4edHsMRAnq3AKDEOOZK6W4Yl9qLIybMvIYRmrGu8ACeKZIG 2RtB76HxIEiw+Kxd/xiYvGw= =mxpJ -----END PGP SIGNATURE-----

4 8

Real.fromDecimal and Real.~
by fluet＠tti-c.org 18 Jun '08

18 Jun '08

* One bug with the implementation of Real.fromDecimal (which also affects Real.scan and Real.fromString) in PolyML 5.2. The string_buffer[30] in Real_convc in <src>/libpolyml/reals.cpp limits the length of the string seen by strtod to 29 characters. However, the construction of the ML string at <src>/basis/Real.sml:359 can construct an arbitrarily large string. In particular, the "E" and exponent can be pushed beyond the end of the string seen by strtod: Poly/ML 5.2 Release > Real.fromString "1234567890.12345678901234"; val it = SOME 1234567890.0 : Real.real option > Real.fromString "1234567890.123456789012345"; val it = SOME 1.23456789 : Real.real option > Real.fromString "1234567890.1234567890123456"; val it = NONE : Real.real option > Real.fromString "1234567890.1234567890123456789"; val it = SOME 0.123456789 : Real.real option * Real.~ doesn't properly flip the sign bit on zero: Poly/ML 5.2 Release > Real.signBit 0.0; val it = false : bool > Real.signBit (Real.~ 0.0); val it = false : bool > Real.signBit 1.0; val it = false : bool > Real.signBit (Real.~ 1.0); val it = true : bool This, in turn, makes 'Real.fromString "~0.0"' get the sign bit wrong: > Real.signBit (valOf (Real.fromString "~0.0")); val it = false : bool

2 1

Release 5.2 issues
by David.Matthews＠prolingua.co.uk 17 Jun '08

17 Jun '08

I've been away for the last week or so since releasing version 5.2 and there have been a few emails about various issues. Rather than deal with each individually I'm responding to all of them together. > I have installed polyml 5.2 (sources) under > MacOSX 10.4.* and 10.5.*. Both times I had > to manually change in the "make install"-step > the attribute of the file install-sh to 755. > Otherwise the make process would refuse to > finish with permission denied message. Maybe > I have been stupid, but it could also be a bug. The version of install-sh in the CVS repository on sourceforge does not have execute permission and I don't believe it's possible to add it to an existing file. I exported from the repository and forgot to set it explicitly before creating the tar file for the version 5.2 release. It only seems to be a problem on certain platforms. I don't generally like changing a distribution once it has been uploaded but I think the easiest way would be for me to upload a new tar file with execute permissions set on install-sh. > The PolyML.get_print_depth function appears to be missing from 5.2. > Should I rework my code to do without it or was this an unintentional > omission? The PolyML structure has been reworked and in particular PolyML.Compiler has changed. In the old persistent storage version (PolyML 4 and earlier) the print depth and similar values were special kinds of references. From version 5 these are just simple references. The reference set by PolyML.print_depth is now in PolyML.Compiler.printDepth so you can define get_print_depth as ! PolyML.Compiler.printDepth. This is used if the compiler is invoked by means of the usual top-level or with "use" but if PolyML.compiler is called with a value passed in with PolyML.Compiler.CPPrintDepth then this is used in place of the reference. > Has there been a change to the semantics of the function Unix.execute? > > Previously, it executed the programme with respect to the current > path. Now, it seems to require an absolute pathname. There were some changes to Unix.execute and while I was doing it I took a closer look at the Basis Library document. This says that the "cmd" argument should name an executable file. Previously the code used "/bin/sh -c" to run the command. It's easy to add this in the call if you want it to search the path. David.

1 0

Release 5.2
by David.Matthews＠prolingua.co.uk 03 Jun '08

03 Jun '08

I've now released version 5.2 on SourceForge. There are no major changes in this release but it contains some updates and bug fixes. I'll update the release notes shortly but these are the major changes. Change to PolyML.compiler to allow more control over parameters and addition of "name space". The current PolyML.compiler has a different type from previously so this will affect code that uses it. Improvement to real numbers on X86 (32 and 64 bit). Fix to a hot-spot in the compiler. This and other changes seem to have speeded up the compiler by about 10%. Improvement to the source-level debugger (i.e. when compiling with PolyML.debug set to true), especially tracing. Addition of weak references. The Weak structure contains functions to create weak references and arrays and a condition variable and associated mutex that is signalled when a weak reference has been deleted by the garbage collector. Changes to handling of signals by the Signal structure. Rather than forking a new thread to process each signal there is a single thread that executes all the signal handlers. This should improve the responsiveness to an asynchronous signals such as SIGINT. The original control-C handler has been removed and the Poly/ML read-eval-print loop now installs a simple handler for control-C that just generates an Interrupt exception. There have been various bug fixes and probably a few other things that I've forgotten. As always, let me know how it goes. David

1 0

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 June 2008