Poly/ML November 2007

polyml@lists.polyml.org

4 participants
13 discussions

Release of version 5.1
by David.Matthews＠prolingua.co.uk 03 Dec '07

03 Dec '07

I've now installed the official release of Poly/ML 5.1 on sourceforge. I'll update the web site shortly. As well as the various fixes and updates I mentioned earlier, such as threading and saving state, there were also some last-minute fixes to get Poly/ML working on the new Mac OS X release. There are a few minor bugs that were reported that I have held over to the next release rather than risk breaking existing code. I'll add the fixes to CVS. That version will become a testing release of 5.2. It would be helpful to be kept aware if anyone is planning to package Poly/ML for any of the distributions just to keep track of them and to avoid duplication of effort. David.

3 2

Compilation errors
by karabot＠gmail.com 25 Nov '07

25 Nov '07

Hi, I am having problems compiling Poly-ML 5.1 for Linux (Slackware distro). Here's a partial output of the compilation: % ./configure .... % make .... /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -Wall -O3 -MT xwindows.lo -MD -MP -MF .deps/xwindows.Tpo -c -o xwindows.lo xwindows.cpp g++ -DHAVE_CONFIG_H -I. -I.. -Wall -O3 -MT xwindows.lo -MD -MP -MF .deps/xwindows.Tpo -c xwindows.cpp -fPIC -DPIC -o .libs/xwindows.o /usr/include/X11/VendorP.h:87: error: previous declaration of 'VendorShellClassRec vendorShellClassRec' with 'C++' linkage /usr/include/Xm/VendorSP.h:58: error: conflicts with new declaration with 'C' linkage As well as some info on my system. % uname -a Linux kalamata 2.6.23.1 #3 SMP Fri Oct 19 15:48:57 EDT 2007 i686 Intel(R) Pentium(R) D CPU 3.40GHz GenuineIntel GNU/Linux Has anyone run into such problems? Any suggestions will be appreciated. George

2 1

Patch to Socket.sml and a portable asynchronous programming library for SML
by vesa.a.j.k＠gmail.com 14 Nov '07

14 Nov '07

QXR0YWNoZWQgaXMgYSBwYXRjaCB0byBtYWtlIFBvbHkvTUwncyBTb2NrZXQuaW9EZXNjIGNvbmZv cm0gdG8gdGhlCkJhc2lzIGxpYnJhcnkgc3BlY2lmaWNhdGlvbgooaHR0cDovL3d3dy5zdGFuZGFy ZG1sLm9yZy9CYXNpcy9zb2NrZXQuaHRtbCNTSUc6U09DS0VULmlvRGVzYzpWQUwpLgoKTk9URTog SSBoYXZlbid0IHRlc3RlZCB0aGlzIHBhdGNoIG90aGVyIHRoYW4gYnkgY29tcGlsaW5nIGEgcHJv Z3JhbQooc21sYm90KSB0aGF0IHVzZXMgc29ja2V0cy4gIFlvdSBjYW4gZmluZCB0aGUgcHJvZ3Jh bSBmcm9tIG1sdG9ubGliOgoKICBodHRwOi8vbWx0b24ub3JnL2NnaS1iaW4vdmlld3N2bi5jZ2kv bWx0b25saWIvdHJ1bmsvY29tL3NzaC9hc3luYy91bnN0YWJsZS9leGFtcGxlL3NtbGJvdC8KClRo ZSBwcm9ncmFtIGlzIGFuIGV4YW1wbGUgb2YgdXNpbmcgYSBwb3J0YWJsZSAoY29tcGlsZXMgbm93 IHdpdGgKTUxLaXQsIE1MdG9uLCBQb2x5L01MLCBhbmQgU01ML05KKSBhc3luY2hyb25vdXMgcHJv Z3JhbW1pbmcgbGlicmFyeQpmb3IgU01MOgoKICBodHRwOi8vbWx0b24ub3JnL2NnaS1iaW4vdmll d3N2bi5jZ2kvKmNoZWNrb3V0Ki9tbHRvbmxpYi90cnVuay9jb20vc3NoL2FzeW5jL3Vuc3RhYmxl L1JFQURNRQogIGh0dHA6Ly9tbHRvbi5vcmcvY2dpLWJpbi92aWV3c3ZuLmNnaS8qY2hlY2tvdXQq L21sdG9ubGliL3RydW5rL2NvbS9zc2gvYXN5bmMvdW5zdGFibGUvcHVibGljL2FzeW5jLnNpZwoK LVZlc2EgS2Fydm9uZW4KLS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0tCkEg bm9uLXRleHQgYXR0YWNobWVudCB3YXMgc2NydWJiZWQuLi4KTmFtZTogc29ja2V0LnBhdGNoClR5 cGU6IHRleHQveC1kaWZmClNpemU6IDE0MDIgYnl0ZXMKRGVzYzogbm90IGF2YWlsYWJsZQpVcmwg OiBodHRwOi8vbGlzdHMuaW5mLmVkLmFjLnVrL21haWxtYW4vcHJpdmF0ZS9wb2x5bWwvYXR0YWNo bWVudHMvMjAwNzExMTQvYjI1ZmI0NzIvc29ja2V0LmJpbgo=

2 1

Re: [Alice-users] hello world in Alice
by vesa.a.j.k＠gmail.com 14 Nov '07

14 Nov '07

T24gTm92IDE0LCAyMDA3IDU6NDggUE0sIE1pY2hlbGUgU2ltaW9uYXRvIDxtaWNoZWxlLnNpbWlv bmF0b0BnbWFpbC5jb20+IHdyb3RlOgo+IE9uIE5vdiAxNCwgMjAwNyA0OjMwIFBNLCAgPHJvc3Ni ZXJnQG1waS1zd3MubXBnLmRlPiB3cm90ZToKWy4uLl0KPiBXZWxsLCBpZiBhIGxhbmd1YWdlIGhh cyBhbiBpbnRlcmFjdGl2ZSB0b3BsZXZlbCAob3IgYSB2ZXJ5IGZhc3QgY29tcGlsZXIpIEkKPiBk b24ndCBzZWUgd2h5IG5vdCB0byB1c2UgaXQgYSBzY3JpcHRpbmcgbGFuZ3VhZ2UuIFsuLi5dCgpS aWdodC4gIFBvbHkvTUwgaGFzIGEgdmVyeSBmYXN0IGNvbXBpbGVyICh0aG91c2FuZHMgb2YgbGlu ZXMgcGVyIHNlY29uZCkuCgo+IFlvdSBkb24ndCBuZWVkIHRvIGNoYW5nZSB0aGUgc3ludGF4IG9m IFNNTC4KClJpZ2h0IGFnYWluLgoKPiBZb3UganVzdCBuZWVkIHRvIHB1dCBhIGZyb250LWVuZCBz dHJpcHBpbmcgdGhlIGZpcnN0IGxpbmUgaWYgaXQgYmVnaW5zIHdpdGgKPiAjISBhbmQgZGlzcGF0 Y2hpbmcgdGhlIGNvZGUgdG8gdGhlIGludGVyYWN0aXZlIGludGVycHJldGVyLgoKSW5kZWVkLiAg SSBqdXN0IHdyb3RlIGEgdG95L2tsdWRnZSBzY3JpcHQgbGlrZSB0aGF0IGZvciBleHBlcmltZW50 aW5nCndpdGggd3JpdGluZyBQb2x5L01MIHNjcmlwdHMuICBZb3UgY291bGQgcHJvYmFibHkgYWRh cHQgaXQgZm9yIEFsaWNlCk1MLiAgTm90ZSwgaG93ZXZlciwgdGhhdCB0aGUgc2NyaXB0ICJwb2x5 c2NyaXB0IiBpcyBkZWZpbml0ZWx5IGtsdW5reQphbmQgZG9lc24ndCBoYW5kbGUgYWxsIGtpbmRz IG9mIGlucHV0IHByb3Blcmx5LiAgSW4gcGFydGljdWxhciwgdGhlCndheSBpdCBwYXNzZXMgdGhl IHBhcmFtZXRlcnMgdG8gdGhlIHNjcmlwdCBpcyB0b3RhbGx5IHVnbHkgYW5kCmZyYWdpbGUuICBU aGUgc2FtZSBnb2VzIGZvciB0aGUga2x1ZGdlIHRvIHN0cmlwIG9mIHVud2FudGVkIG91dHB1dApw ZXJmb3JtZWQgYnkgUG9seS9NTC4gIEl0IHdvdWxkIGJlIGJldHRlciB0byBleHRlbmQgdGhlIFBv bHkvTUwKY29tcGlsZXIgd2l0aCBhbiBvcHRpb24gdG8gc3RvcCBwcm9jZXNzaW5nIGFyZ3VtZW50 cyAoYW5kIG1ha2UKIkNvbW1hbmRMaW5lLmFyZ3VtZW50cyAoKSIgcmV0dXJuIHRoZSByZXN0IG9m IHRoZSBhcmd1bWVudHMpLCBhbm90aGVyCm9wdGlvbiB0byBub3QgcHJpbnQgYW55IHByb21wdCBh bmQgb25lIG1vcmUgb3B0aW9uIHRvIHNldCB0aGUKcHJpbnRfZGVwdGggKHRoZXNlIG9wdGlvbnMg c2hvdWxkIG5vdCBiZSB0b28gZGlmZmljdWx0IHRvIGltcGxlbWVudCkuCgotVmVzYSBLYXJ2b25l bgotLS0tLS0tLS0tLS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0KAnontextattachmentwa sscrubbedNameargssmlTypeapplication/smilSize214bytesDescnotavailableUrlhttp/ /listsinfedacuk/mailman/private/polyml/attachments/20071114/fff17980/argssmi LS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0tCkEgbm9uLXRleHQgYXR0YWNo bWVudCB3YXMgc2NydWJiZWQuLi4KTmFtZTogcG9seXNjcmlwdApUeXBlOiBhcHBsaWNhdGlvbi9v Y3RldC1zdHJlYW0KU2l6ZTogMTAzMyBieXRlcwpEZXNjOiBub3QgYXZhaWxhYmxlClVybCA6IGh0 dHA6Ly9saXN0cy5pbmYuZWQuYWMudWsvbWFpbG1hbi9wcml2YXRlL3BvbHltbC9hdHRhY2htZW50 cy8yMDA3MTExNC9mZmYxNzk4MC9wb2x5c2NyaXB0Lm9iago=

1 0

Bug in lexing of selectors
by vesa.a.j.k＠gmail.com 14 Nov '07

14 Nov '07

Consider the following interaction with Poly/ML: Poly/ML 5.1 Testing > val e = ("a", "b") ; val e = ("a", "b") : string * string > #1e ; Error: malformed real number: 1E Error: Identifier expected but 1E was found Static errors (pass 1) The correct way to lex the above is to first lex "#1" as a selector and then "e" as an identifier. -Vesa Karvonen

1 0

shebangs
by vesa.a.j.k＠gmail.com 14 Nov '07

14 Nov '07

On Nov 14, 2007 8:22 AM, Michele Simionato <michele.simionato(a)gmail.com> wrote: [...] > My expectation would be can a script can be executed by > writing something like > > #!/usr/bin/env alice > print "Hello World\n" > > and making the script executable, but this is clearly unsupported, since > running that gives > > $ ./hello.aml > Alice 1.4 ("Kraftwerk 'Equaliser' Album") mastered 2007/04/24 > ### loaded signature from x-alice:/lib/system/Print > ### loaded signature from x-alice:/lib/tools/Inspector > ### loaded signature from x-alice:/lib/distribution/Remote > ### evaluating file /Users/micheles/md/ml/hello.aml > hello.aml:1.0-1.3: unknown value or constructor `#!/' Yes, the characters sequence #!/ is a valid symbolic identifier in SML. Also, the syntax # lab is special and explained on page 49 (60) of http://www.cs.cmu.edu/~rwh/smlbook/online.pdf . Personally, particularly after having experienced the (very fast!) speed at which Poly/ML compiles code, I think that interactive SML implementations should simply add a non-standard special case for shebangs (perhaps with a suitable command-line argument). That would allow SML to be used as a powerful scripting language. In practice, ordinary SML source files never start with the symbolic identifier #!/. -Vesa Karvonen

1 0

Bug in parsing strexps with a signature ascription
by vesa.a.j.k＠gmail.com 09 Nov '07

09 Nov '07

Poly/ML doesn't seem to parse strexps with a signature ascription. IOW, the following productions do not seem to be accepted by Poly/ML: strexp ::= strexp : sigexp strexp :> sigexp See Figure 6 on page 13 in the Definition. I can see that at least a part of the bug is located in the PARSE_DEC.ML file around line 2133. I encountered this bug while attempting to compile my generics library [1] with Poly/ML. Some of the generics make essential use of the following form of sealing [e.g. at bottom of #2]: functor WithXXX (...) = let structure Result = struct ... end in Result :> XXX where type (...) t = (...) Result.t end If I comment out the ascription, Poly/ML seems to compile the code correctly. -Vesa Karvonen [1] http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/generic/unstabl… [2] http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/generic/unstabl…

2 2

ANN: Initial port of several libraries to Poly/ML
by vesa.a.j.k＠gmail.com 09 Nov '07

09 Nov '07

SSBoYXZlIG5vdyBmaW5pc2hlZCBhbiBpbml0aWFsIHBvcnQgb2Ygc2V2ZXJhbCBsaWJyYXJpZXMg KHRoYXQgSQpkZXZlbG9wKSBmcm9tIE1MdG9uJ3MgbGlicmFyeSBwcm9qZWN0IHJlcG9zaXRvcnkK KGh0dHA6Ly9tbHRvbi5vcmcvcGlwZXJtYWlsL21sdG9uLzIwMDYtRGVjZW1iZXIvMDI5NDY0Lmh0 bWwpIHRvClBvbHkvTUwuICBUbyBiZSBwcmVjaXNlLCB0aGUgdHdvIGJ1Z3MgdGhhdCBJIHJlcG9y dGVkIHJlY2VudGx5ICh0aGUKcGFyc2luZyBvZiBzdHJleHBzIGJ1ZyBhbmQgdGhlIHR5cGUgY2hl Y2tpbmcgYnVnKSBuZWVkIHRvIGJlIGZpeGVkCmZpcnN0LCBidXQgeW91IGNhbiB0ZW1wb3Jhcmls eSB3b3JrIGFyb3VuZCB0aG9zZSBidWdzIGFzIEkgaGF2ZQpkZXNjcmliZWQuICBUaGlzIGUtbWFp bCBhbHNvIGNvbnRhaW5zIGEgcGF0Y2ggdGhhdCB5b3UgY2FuIGFwcGx5IGFzIGEKd29ya2Fyb3Vu ZCB1bnRpbCB0aGUgYnVncyBpbiBQb2x5L01MIGFyZSBmaXhlZCAobm90ZSB0aGF0IHRoZSBwYXRj aCBpcwpyZWxhdGl2ZSB0byB0aGUgPG1sdG9ubGliPi9jb20vc3NoIGRpcmVjdG9yeSkuCgpIZXJl IGFyZSBsaW5rcyB0byB0aGUgUkVBRE1FIGZpbGVzIG9mIHRoZSBwb3J0ZWQgbGlicmFyaWVzOgoK KiBFeHRlbmRlZCBCYXNpcyBMaWJyYXJ5OgpodHRwOi8vbWx0b24ub3JnL2NnaS1iaW4vdmlld3N2 bi5jZ2kvbWx0b25saWIvdHJ1bmsvY29tL3NzaC9leHRlbmRlZC1iYXNpcy91bnN0YWJsZS9SRUFE TUU/dmlldz1tYXJrdXAKKiBHZW5lcmljIFByb2dyYW1taW5nIExpYnJhcnk6Cmh0dHA6Ly9tbHRv bi5vcmcvY2dpLWJpbi92aWV3c3ZuLmNnaS9tbHRvbmxpYi90cnVuay9jb20vc3NoL2dlbmVyaWMv dW5zdGFibGUvUkVBRE1FP3ZpZXc9bWFya3VwCiogUHJldHR5IFByaW50aW5nIExpYnJhcnk6Cmh0 dHA6Ly9tbHRvbi5vcmcvY2dpLWJpbi92aWV3c3ZuLmNnaS9tbHRvbmxpYi90cnVuay9jb20vc3No L3ByZXR0aWVyL3Vuc3RhYmxlL1JFQURNRT92aWV3PW1hcmt1cAoqIFJhbmRvbSBHZW5lcmF0b3Ig TGlicmFyeToKaHR0cDovL21sdG9uLm9yZy9jZ2ktYmluL3ZpZXdzdm4uY2dpL21sdG9ubGliL3Ry dW5rL2NvbS9zc2gvcmFuZG9tL3Vuc3RhYmxlL1JFQURNRT92aWV3PW1hcmt1cAoqIFVuaXQgVGVz dGluZyBMaWJyYXJ5OgpodHRwOi8vbWx0b24ub3JnL2NnaS1iaW4vdmlld3N2bi5jZ2kvbWx0b25s aWIvdHJ1bmsvY29tL3NzaC91bml0LXRlc3QvdW5zdGFibGUvUkVBRE1FP3ZpZXc9bWFya3VwCiog VXNlIExpYnJhcnk6IGh0dHA6Ly9tbHRvbi5vcmcvY2dpLWJpbi92aWV3c3ZuLmNnaS9tbHRvbmxp Yi90cnVuay9vcmcvbWx0b24vdmVzYWsvdXNlLWxpYi91bnN0YWJsZS9SRUFETUU/dmlldz1tYXJr dXAKCkkgZW5jb3VyYWdlIFBvbHkvTUwgdXNlcnMgdG8gdGFrZSBhIGxvb2sgYXQgdGhlIGxpYnJh cmllcyBhcyBJIGJlbGlldmUKc29tZSBtaWdodCBmaW5kIHRoZW0gdXNlZnVsLiAgTm93LCBob3cg ZG8gSSBnZXQgeW91IHRvIGxvb2suLi4gIElmCnRoZXJlIGV4aXN0cyBhIDExLWxpbmUgcHJvZ3Jh bSB0aGF0IGp1c3QgbWFrZXMgeW91IHdhbnQgdG8gbG9vaywgdGhlbgptYXliZSBpdCBpcyB0aGUg YmVsb3cgZXhhbXBsZSBmcm9tIG15IHNsaWRlcyBhdCB0aGUgTUwgd29ya3Nob3AKKGh0dHA6Ly9y ZXNlYXJjaC5taWNyb3NvZnQuY29tL35jcnVzc28vbWwyMDA3L3NsaWRlcy9tbDA4cnAta2Fydm9u ZW4tc2xpZGVzLnBkZik6Cgp1c2UgIm9yZy9tbHRvbi92ZXNhay91c2UtbGliL3Vuc3RhYmxlL3Bv bHltbC51c2UiIDsKdXNlICJjb20vc3NoL3VuaXQtdGVzdC91bnN0YWJsZS9saWItd2l0aC1kZWZh dWx0LnVzZSIgOwpsZXQgb3BlbiBHZW5lcmljIFVuaXRUZXN0IGluCiAgIHVuaXRUZXN0cwogICAg ICAodGl0bGUgIlJldmVyc2UgKGluY29ycmVjdCkiKQogICAgICAodGVzdEFsbCAoc3EgKGxpc3Qg aW50KSkKICAgICAgICAgICAgICAgKGZuICh4cywgeXMpID0+CiAgICAgICAgICAgICAgICAgICB0 aGF0RXEgKGxpc3QgaW50KQogICAgICAgICAgICAgICAgICAgICAgICAgIHtleHBlY3QgPSByZXYg KHhzIEAgeXMpLAogICAgICAgICAgICAgICAgICAgICAgICAgICBhY3R1YWwgPSByZXYgeHMgQCBy ZXYgeXN9KSkgJAplbmQgOwoKVGhlIGFib3ZlIGlzIGFuIGV4YW1wbGUgdXNpbmcgdGhlIFVuaXQg VGVzdGluZyBsaWJyYXJ5LiAgWW91IGNhbiByZWFkCnRoZSBhYm92ZSB0ZXN0IGFzIGZvbGxvd3M6 CgogICAgVGVzdCBmb3IgYWxsIHBhaXJzIG9mIGxpc3RzIG9mIGludGVnZXJzIHhzIGFuZCB5cywg dGhhdCB0aGUKICAgIGxpc3RzIG9mIGludGVnZXJzIGV4cGVjdCBhbmQgYWN0dWFsIGFyZSBlcXVh bCwgd2hlcmUgdGhlCiAgICBleHBlY3QgbGlzdCBpcyB0aGUgcmV2ZXJzZSBvZiB0aGUgY29uY2F0 ZW5hdGlvbiBvZiB4cyBhbmQgeXMKICAgIGFuZCB0aGUgYWN0dWFsIGxpc3QgaXMgdGhlIGNvbmNh dGVuYXRpb24gb2YgdGhlIHJldmVyc2Ugb2YgeHMKICAgIGFuZCB0aGUgcmV2ZXJzZSBvZiB5cy4K Ck9mIGNvdXJzZSwgdGhpcyBwcm9wZXJ0eSBkb2VzIG5vdCBob2xkLiAgUnVubmluZyB0aGUgYWJv dmUganVzdCBub3cKd2l0aCBQb2x5L01MIGdhdmUgbWU6CgpbLi4uXQoxLiBSZXZlcnNlIChpbmNv cnJlY3QpIHRlc3QKICBGQUlMRUQ6CiAgICB3aXRoIChbMV0sIFt+MV0pCiAgICBlcXVhbGl0eSB0 ZXN0IGZhaWxlZDogZXhwZWN0ZWQgW34xLCAxXSwgYnV0IGdvdCBbMSwgfjFdLgoKV2hhdCB0aGUg b3V0cHV0IG1lYW5zIGlzIHRoYXQgdGhlIHRlc3QgZmFpbGVkIHdpdGggdGhlIGNvdW50ZXJleGFt cGxlCihbMV0sIFt+MV0pIGFuZCB0aGUgcmVhc29uIHdoeSBpdCBmYWlsZWQgaXMgdGhhdCB0aGUg ZXhwZWN0IGxpc3QgW34xLAoxXSB3YXNuJ3QgZXF1YWwgdG8gdGhlIGFjdHVhbCBsaXN0IFsxLCB+ MV0uCgpJdCBpcyBlYXN5IHRvIHNlZSB0aGF0IGluIG9yZGVyIHRvIGltcGxlbWVudCB0aGlzIGJl aGF2aW9yLCB5b3UgbmVlZAphdCBsZWFzdCB0byBiZSBhYmxlIHRvIGdlbmVyYXRlIGxpc3RzIG9m IGludGVnZXJzLCBjb21wYXJlIHRoZW0gZm9yCmVxdWFsaXR5LCBhbmQgcHJldHR5IHByaW50IHRo ZW0uICBUaGF0J3Mgbm90IGFsbCwgaG93ZXZlci4gIEl0IGlzIG5vdApqdXN0IGEgbHVja3kgY29p bmNpZGVuY2UgdGhhdCB0aGUgbGlzdHMgaW4gdGhlIGNvdW50ZXJleGFtcGxlIHdlcmUKc2luZ2xl dG9uIGxpc3RzIGFuZCB0aGF0IHRoZSBlbGVtZW50cyBvZiB0aGUgbGlzdHMgd2VyZSBudW1lcmlj YWxseQpzbWFsbC4gIEluIGZhY3QsIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uIG1ha2VzIHVz ZSBvZiBhIHRvdGFsIG9mIDkKZ2VuZXJpYyB1dGlsaXR5IG9wZXJhdGlvbnM6Ci0gVGhlIEFyYml0 cmFyeSBnZW5lcmljIGlzIHVzZWQgdG8gZ2VuZXJhdGUgcmFuZG9tIHZhbHVlcyB3aGlsZQpzZWFy Y2hpbmcgZm9yIGEgY291bnRlcmV4YW1wbGUuCi0gVGhlIFNocmluayBnZW5lcmljIGlzIHVzZWQg dG8gcmVkdWNlIHRoZSBzaXplIG9mIGNvdW50ZXJleGFtcGxlcyB0bwptYWtlIHRoZW0gbW9yZSBy ZWFkYWJsZS4KLSBUaGUgU2l6ZSBnZW5lcmljIGlzIHVzZWQgdG8gb3JkZXIgY291bnRlcmV4YW1w bGVzIGJ5IHNpemUgYW5kIHRoZQpPcmQgZ2VuZXJpYyBpcyB1c2VkIHRvIG9yZGVyIGNvdW50ZXJl eGFtcGxlcyBieSBhIGxpbmVhciBvcmRlcmluZwp3aGlsZQpzaHJpbmtpbmcgY291bnRlcmV4YW1w bGVzLgotIFRoZSBFcSBnZW5lcmljIGlzIHVzZWQgdG8gY29tcGFyZSB2YWx1ZXMgZm9yIGVxdWFs aXR5LgotIFRoZSBQcmV0dHkgZ2VuZXJpYyBpcyB1c2VkIHRvIHByZXR0eSBwcmludCB2YWx1ZXMu Ci0gVGhlIEhhc2ggZ2VuZXJpYyBpcyB1c2VkIHRvIGhhc2ggdmFsdWVzIGFuZCBpcyB1c2VkIGlu dGVybmFsbHkgYnkKc2V2ZXJhbCBvdGhlciBnZW5lcmljcy4KLSBUaGUgVHlwZUhhc2ggYW5kIFR5 cGVJbmZvIGdlbmVyaWNzIGFyZSBhbHNvIHVzZWQgaW50ZXJuYWxseSBieSBvdGhlciBnZW5lcmlj cy4KVGhlc2UsIGFuZCBzZXZlcmFsIG90aGVyLCBnZW5lcmljIGZ1bmN0aW9ucyBhcmUgcHJvdmlk ZWQgYnkgdGhlCkdlbmVyaWMgUHJvZ3JhbW1pbmcgbGlicmFyeSBhbmQgdGhlIFVuaXQgVGVzdGlu ZyBsaWJyYXJ5IHVzZXMgdGhlbS4KCkkgbXVzdCBzYXkgdGhhdCBQb2x5L01MIGNvbXBpbGVzIGFt YXppbmdseSBxdWlja2x5IGNvbXBhcmVkIHRvIGV2ZXJ5Cm90aGVyIFNNTCBpbXBsZW1lbnRhdGlv biB0aGF0IEkgaGF2ZSB1c2VkLiAgRm9yIGV4YW1wbGUsIFBvbHkvTUwKZXhlY3V0ZXMgdGhlIGZp cnN0IHR3byB1c2UgbGluZXMgaW4gdGhlIGFib3ZlIGV4YW1wbGUgaW4gYWJvdXQgMwpzZWNvbmRz IG9uIG15IGxpZ2h0bHkgbG9hZGVkIGxhcHRvcC4gIFRoZSBzYW1lICh3aXRoIHBvbHltbC51c2UK cmVwbGFjZWQgd2l0aCBzbWxuai51c2UpIHRha2VzIGFib3V0IDEgbWludXRlIGFuZCAyMCBzZWNv bmRzIHdpdGgKU01ML05KLiAgU28sIGluIHRoaXMgY2FzZSwgUG9seS9NTCB3YXMgYWJvdXQgMjV4 IGZhc3RlciBhdCBjb21waWxpbmcKdGhhbiBTTUwvTkouICBJbXByZXNzaXZlIQoKVG8gdHJ5IHRo ZSBhYm92ZSBleGFtcGxlIHlvdXJzZWxmLCBzYXZlIHRoZSBwYXRjaCBmcm9tIHRoaXMgbWVzc2Fn ZSwKY2hlY2sgb3V0IHRoZSBtbHRvbmxpYiByZXBvc2l0b3J5LCB1c2UgdGhlIHBhdGNoIHRvIHdv cmsgYXJvdW5kIHRoZQpidWdzIGluIFBvbHkvTUwsIGJ1aWxkIHRoZSB1c2UtbGliIGxpYnJhcnks IGdvIHRvIHRoZSBtbHRvbmxpYiByb290CmRpcmVjdG9yeSwgc3RhcnQgUG9seS9NTCBhbmQgZW50 ZXIgdGhlIGV4YW1wbGUgYXQgdGhlIFJFUEwuICBIZXJlIGlzIGEKc2hlbGwgc2NyaXB0IHRvIGRv IGV2ZXJ5dGhpbmcgYnV0IHRoZSBmaXJzdCBhbmQgbGFzdCBzdGVwczoKCnN2biBjbyBzdm46Ly9t bHRvbi5vcmcvbWx0b25saWIvdHJ1bmsgbWx0b25saWIKY2QgbWx0b25saWIvY29tL3NzaC8KcGF0 Y2ggLXAwIDwgLi4vLi4vLi4vbWx0b25saWItcG9seW1sLXdvcmthcm91bmRzLnBhdGNoCmNkIC4u Ly4uL29yZy9tbHRvbi92ZXNhay91c2UtbGliL3Vuc3RhYmxlLwouL01ha2Uuc2gKY2QgLi4vLi4v Li4vLi4vLi4KcG9seQoKSGF2ZSBmdW4hCgotVmVzYSBLYXJ2b25lbgotLS0tLS0tLS0tLS0tLSBu ZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0KQSBub24tdGV4dCBhdHRhY2htZW50IHdhcyBzY3J1YmJl ZC4uLgpOYW1lOiBtbHRvbmxpYi1wb2x5bWwtd29ya2Fyb3VuZHMucGF0Y2gKVHlwZTogdGV4dC94 LWRpZmYKU2l6ZTogNTE5OSBieXRlcwpEZXNjOiBub3QgYXZhaWxhYmxlClVybCA6IGh0dHA6Ly9s aXN0cy5pbmYuZWQuYWMudWsvbWFpbG1hbi9wcml2YXRlL3BvbHltbC9hdHRhY2htZW50cy8yMDA3 MTEwOS9jNTgwOTc1OC9tbHRvbmxpYi1wb2x5bWwtd29ya2Fyb3VuZHMuYmluCg==

1 0

A type checking bug in Poly/ML
by vesa.a.j.k＠gmail.com 08 Nov '07

08 Nov '07

While attempting to compile my random value generator library with Poly/ML, I encountered a type checking bug in Poly/ML (compiled from CVS). Steps to reproduce: 1. Get MLton lib revision 6146. 2. Run ./Make.sh in the <mltonlib>/org/mlton/vesak/use-lib/unstable directory. 3. Run poly in the <mltonlib> directory and enter the following two expressions: use "org/mlton/vesak/use-lib/unstable/polyml.use" ; use "com/ssh/random/unstable/lib.use" ; The output [...] Error: in '[...]/mltonlib-6146/com/ssh/random/unstable/detail/mk-random-gen.fun', line 7. Can't match 'a MkRandomGen().cod to 'a [...] indicates a type checking bug in Poly/ML. For convenience, here is a shell script for triggering the bug: svn -r 6146 co svn://mlton.org/mltonlib/trunk mltonlib-6146 cd mltonlib-6146/org/mlton/vesak/use-lib/unstable/ ./Make.sh cd ../../../../.. echo 'use "org/mlton/vesak/use-lib/unstable/polyml.use" ; use "com/ssh/random/unstable/lib.use" ;' | poly Part of the code that triggers the bug are the following type definitions in the file <mltonlib>/com/ssh/random/unstable/detail/mk-random-gen.fun: type 'a dom = Int.t * RNG.t and 'a cod = 'a type 'a t = 'a dom -> 'a cod If the definitions of 'a dom and 'a cod are substituted into 'a t type 'a t = Int.t * RNG.t -> 'a the code compiles with Poly/ML. This shouldn't be necessary however. For the curious, the dom and cod tycons are a leftover from an earlier signature that revealed that the t tycon is an arrow. The same code compiles fine without modification with SML/NJ, MLton, and MLKit. -Vesa Karvonen

1 0

Forthcoming 5.1 release
by David.Matthews＠prolingua.co.uk 08 Nov '07

08 Nov '07

There has been quite a lot of work on Poly/ML over the last year and I'm intending to release version 5.1 shortly. This is an invitation to try the CVS version and let me know if there are any bugs that need to be fixed before the final release. The two major changes are the addition of true multi-threading and the ability to save and load changes without having to build an executable. There have also been changes to the Windows interface structures and other minor changes. The multi-threading changes (thanks to the Verisoft project and TUM) involved a major re-working of the run-time system to allow the code to use kernel threads, in turn allowing multi-threaded programs to make use of multiple cores. A new Thread structure has been written to make effective use of this and the details are at http://www.polyml.org/docs/Threads.html . The old Process structure has been rewritten in terms of this but it will generally be better to use the Thread structure directly. A new substructure, PolyML.SaveState, has been added (thanks to Qinetiq), to allow the state of a session to be saved and then reloaded in another session. This is a lighter-weight version of the PolyML.export and does not require a linking step. Details of the structure can be found at http://www.polyml.org/docs/SaveState.html . As well as simple saved states it is also possible to build chains of saved states in which each saved state contains only the changes from the one above. The current plan is to release version 5.1 towards the end of this month so any feedback would be appreciated as soon as possible. David.

2 2

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 November 2007