Poly/ML March 2026

polyml@lists.polyml.org

4 participants
4 discussions

Interrupting the read-eval-print loop
by Rob Arthan 28 Mar '26

28 Mar '26

I am seeing non-deterministic behaviour in the way keyboard interrupts are handled in the REPL. Some unknown factor seems to be causing some instances of poly to ignore them while other instances do what I would expect: Here in one terminal window, no matter how long I wait, there is no response to a Ctrl-C: rda]- poly Poly/ML 5.9.2 Release > ([ # ^C In another terminal window, I see what I would expect: rda]- poly Poly/ML 5.9.2 Release > ([ # ^CCompilation interrupted > I see exactly the same behaviour if I send the signal from another terminal window using kill -INT. This is all on Mac OS Sequoia 15.3.2. I don’t recall having any problems like this on older releases of Poly/ML say prior to 15.9, though I can’\t say exactly when it started. The behaviour I would expect is very useful as, if you’ve mistakenly copied in some badly formed input, it can be quite fiddly to work out how to continue the input to get back to the top-level prompt of the REPL without accidentally executing something you don’t want to be executed. Any suggestions? Rob.

2 2

Issue with vector header file during Poly/ML build
by Rob Arthan 24 Mar '26

24 Mar '26

I am trying to build Poly/ML from the 5.9.2 tarball on Mac OS Sequoia 15.3.2 and it is failing as follows on my Mac Mini: rda]- make /Library/Developer/CommandLineTools/usr/bin/make all-recursive Making all in libpolyml /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -O3 -DMACOSX -Wall -DMODULEDIR=\"/usr/local/poly/5.9.2-fixed/lib/polyml/modules\" -O3 -MT arb.lo -MD -MP -MF .deps/arb.Tpo -c -o arb.lo arb.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -O3 -DMACOSX -Wall -DMODULEDIR=\"/usr/local/poly/5.9.2-fixed/lib/polyml/modules\" -O3 -MT arb.lo -MD -MP -MF .deps/arb.Tpo -c arb.cpp -fno-common -DPIC -o .libs/arb.o In file included from arb.cpp:93: ./memmgr.h:27:10: fatal error: 'vector' file not found 27 | #include <vector> | ^~~~~~~~ 1 error generated. make[2]: *** [arb.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 It builds fine on my MacBook which is running the same OS and the same version of the Xcode tools. There are suggested fixes to similar problems (but not with Poly/ML) on the Web but the proposed solutions don’t work for me. Any suggestions gratefully received. Regards, Rob.

1 1

Symbolic identifiers for module names
by David Matthews 21 Mar '26

21 Mar '26

A student at KCL, Enzo Bestetti, has been doing a systematic analysis of Poly/ML's lexer. There weren't any serious problems but he did mention something that made me look more closely. It turns out that Poly/ML has been accepting symbolic identifiers, those made up of the symbols +, - etc, for structure, signature and functor names. It looks as though this changed between SML90 and SML97 and I hadn't realised. The SML90 definition explicitly includes symbolic identifiers for signature and functors and doesn't appear to rule them out for structures. The SML97 restricts them to alphanumeric only but I can't see this included in the list of changes in Appendix G which is why it slipped through. I'm proposing to restrict module names to alphanumeric to bring Poly/ML into line with the SML97 Definition. I can't imagine that this will affect anyone but I thought I'd mention it. David

2 1

Type Constraints and Overloading
by Duke Normandin 03 Mar '26

03 Mar '26

Taken from Paulson's book: Chap2.4 A) fun square x = x * x; > Error- Unable to resolve overloading for * I understand the above! B) fun square(x : real) = x * x; I understand: x is declared as a real C) fun square x = x * x : real; I see this as declaring a function w/o parentheses AND that the r_result_ is a 'real' I have a problem with this declaration: D) fun square x : real = x * x; I see this as declaring a function w/o parentheses, AND declaring x to be a 'real' I do NOT see/understand that this syntax indicates that the type of the _result_ is a 'real' I suppose that I'm free to ignore D) and use the more IMHO intuitive C) declaration. I thought that I'd ask to make sure that I wasn't missing something in the D) one. TIA .... -- Duke

6 13

2026

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 March 2026