Poly/ML

polyml@lists.polyml.org

704 discussions

Joint IFL/TFP 2003 Call For Papers, Edinburgh, September 2003
by stg＠inf.ed.ac.uk 23 May '03

23 May '03

[Apologies for multiple copies of this message.] Joint IFL/TFP 2003 Call For Papers Between 8th and 12th September 2003 the - 15th Int. Workshop on the Implementation of Functional Languages http://www.macs.hw.ac.uk/~ifl03 - 4th Int. Symposium on Trends in Functional Programming http://homepages.inf.ed.ac.uk/stg/workshops/TFP/ will be co-located in Edinburgh Both calls for papers are appended below. ============================================================= IFL 2003 15th International Workshop on the IMPLEMENTATION OF FUNCTIONAL LANGUAGES Edinburgh Scotland September 8th - 10th, 2003 http://www.macs.hw.ac.uk/~ifl03 ============================================================= Important dates --------------- Registration deadline: August 1st, 2003 Submission deadline : August 22nd, 2003 Workshop : September 8-10th, 2003 ============================================================= Scope of IFL 2003 ----------------- The aim of the workshop is to bring together researchers and users actively engaged in the implementation and application of functional programming languages to discuss results and new directions of research. The workshop is intended to provide an open forum for researchers who wish to present and discuss new ideas and concepts, work in progress, preliminary results etc. related primarily but not exclusively to the implementation of functional or function-based languages. A not necessarily exhaustive list of topics includes language concepts type checking compilation techniques (abstract) interpretation automatic program generation (abstract) machine architectures array processing concurrent/parallel programming and program execution heap management runtime profiling and performance measurements debugging and tracing verification of functional programs tools and programming techniques Contributions on applications of functional programming, e.g., in teaching, or on theoretical work in any of the above areas are also welcome. This year's workshop is co-located with the 4th International Symposium on Trends in Functional Programming (TFP'03) <http://homepages.inf.ed.ac.uk/stg/workshops/ISTFP/>. Contributions ------------- All attendees are encouraged to submit papers to be published in the draft proceedings and to give presentations at the workshop. Submitted papers must be written in English, conform to the LNCS format (available at: http://www.springer.de/comp/authors/index.html) and not exceed 16 pages. Papers should be submitted by August 22nd as postscript or pdf files using the submission page of the workshop accessible through http://www.macs.hw.ac.uk/~ifl03 After the workshop, a high-quality subset of contributions will be published in the Springer LNCS series. All speakers attending the workshop are invited to submit a paper. Papers for the LNCS proceedings will be refereed according to normal conference standards. Greg Michaelson and Phil Trinder (Organizing Committee Chairs) School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, EH14 4AS E-mail: {greg,trinder}(a)macs.hw.ac.uk Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.macs.hw.ac.uk/~greg http://www.macs.hw.ac.uk/~trinder ============================================================ TFP 2003 Fourth International symposium on Trends in Functional Programming Edinburgh, Scotland September 11th - 12th, 2003 http://homepages.inf.ed.ac.uk/stg/workshops/TFP/ The international symposium on Trends in Functional Programming continues the Scottish Functional Programming Workshop series. These workshops bring together researchers with interests in all aspects of functional programming languages. Papers on all aspects of functional programming are welcomed, be they implementation-oriented, theoretical, or experience papers. This year's workshop is co-located with the 15th International Workshop on the Implementation of Functional Languages (IFL '03) <http://www.macs.hw.ac.uk/~ifl03>. Workshop Topics Papers on any aspect of functional programming are welcome. Papers on the following subject areas are particularly welcome. * rich type systems, including type systems for expressing resource bounds or other safety properties; * linear type systems, soft type systems, typeful programming; * reasoning about functional programs, semantics of functional languages; * inductive or co-inductive techniques, proof nets; * mobile-code functional programming languages; * parallel programming with functional languages, cost models for functional programs; * compilation of functional languages for the Java Virtual Machine; * functional aspects of imperative programming, functional bytecode; * interoperability with imperative programming languages, calling imperative from functional or vice versa; * type inference algorithms, type error repair, deep types; * strongly-typed imperative languages with inference (e.g. Cyclone); * performance measurements, optimisation techniques, implementation techniques; * experience papers: applications of functional programming or functional programming in education. The above list is not exhaustive. Papers on other topics are also welcome. Contributions All attendees are encouraged to submit papers to be published in the draft proceedings and to give presentations at the workshop. Submitted papers must be written in English and not exceed 16 pages. Papers should be submitted as postscript (or pdf) by email to the workshop chair, Stephen Gilmore <stg(a)inf.ed.ac.uk>. Proceedings We intend to publish a high-quality subset of contributions in a highly-regarded series. All speakers attending the workshop are invited to submit a paper. Papers for the proceedings will be refereed according to normal conference standards. This implies (among other things) that: * the paper should be written in English * the paper is well written * topic of the paper should be stated clearly * the approach to solve the problem should be outlined clearly * a detailed discussion of the solution has to be given * the solution is compared with relevant related work * there is an abstract, introduction and conclusion. * the conclusion should summarise the problem, the solution, and how this solves the problem. * the paper should not exceed 16 pages. * the paper should be submitted as postscript (or pdf) by email to the workshop chair, Stephen Gilmore <stg(a)inf.ed.ac.uk>. Dates Aug 2nd 2003 : Submission for draft proceedings Sept 11th - Sept 12th 2003 : Workshop Oct 31st 2003 : Submission for referees process Dec 12th 2003 : Notification of acceptance/rejection Jan 23rd 2004 : Camera-ready papers Event Site The workshop will take place at The Pollock Halls in the city center of Edinburgh <http://www.accom.ed.ac.uk/maps/pollock.htm>. Previous workshops The TFP workshop continues the Scottish Functional Programming Workshop series. The previous SFPW meetings were Stirling (2001), St. Andrews (2000), Stirling (1999). Program Committee (provisional) Sharon Curtis <http://wwwcms.brookes.ac.uk/~p0073860/> Oxford Brookes University Stephen Gilmore (Chair) <http://homepages.inf.ed.ac.uk/stg/> The University of Edinburgh Kevin Hammond <http://www.dcs.st-and.ac.uk/~kh/> University of St Andrews Hans-Wolfgang Loidl <http://www.tcs.informatik.uni-muenchen.de/~hwloidl/> Ludwig-Maximilians-Universitat, Munchen Bruce McAdam <http://www.scms.rgu.ac.uk/staff/bjm/> Robert Gordon University Greg Michaelson <http://www.cee.hw.ac.uk/~greg/> Heriot-Watt University John O'Donnell <http://www.dcs.gla.ac.uk/~jtod/> University of Glasgow Phil Trinder <http://www.cee.hw.ac.uk/~trinder/> Heriot-Watt University -- Stephen Gilmore Laboratory for Foundations of Computer Science The University of Edinburgh Edinburgh EH9 3JZ Scotland

1 0

Closing Motif Shell Windows
by rda＠lemma-one.com 11 Feb '03

11 Feb '03

Dear All, I have a Poly/ML Motif-based tool that is intended to be run from inside an interactive Poly/ML session. If you just take the defaults, when you use the window manager to close the shell window for the tool, the default value of XmDELETE for the deleteResponse resource on the shell widget means that the process gets killed, and the process in question is the Poly/ML session and that's not what I want. What I want to do is to tidy up without killing the interactive session so that the tool can be restarted in the same session if the user wants to. I have a quit callback which does this tidy up when you press a quit pushbutton in the tool. The C code to do this looks like this: XtVaSetValues(shell, XmNdeleteResponse, XmDO_NOTHING, NULL); WM_DELETE_WINDOW = XmInternAtom(XtDisplay(shell), "WM_DELETE_WINDOW", False); XmAddWMProtocolCallback(shell, WM_DELETE_WINDOW, quit, shell); Unfortunately, XmAddWMProtocolCallback and XmInternAtom aren't supported in the Poly/ML Motif structure. The Xlib interfaces you need to set up the WM protocols and handle client message events from the window manager are also not all provided. I'm currently using the following work-around. I set the deleteResponse resource on the shell widget to XmUNMAP then arrange for the function that starts the tool to attempt to map it again. If this fails, then the tool was killed by the quit pushbutton and I rebuild the widget hierarchy. Luckily, this gives the functionality I want, but it does mean that the window manager close differs from the quit pushbutton in not freeing the client and server memory and other resources occupied by the tool. Also, my quit callback is only able to destroy the widget hierarchy, since the interface hides application contexts behind the scenes. Does XtDestroyWidget cause the application context to be destroyed if you destroy the shell widget? I couldn't see any calls to XtDestroyApplicationContext in the driver code - so presumably I have a small memory leak with things as they are. Is there a better way with the existing Motif and X support? If not, is there a simple recipe for adding in extra Motif and X library functions? Regards, Rob.

1 0

Comparison bug in LargeWord
by richards＠CS.Princeton.EDU 23 Jan '03

23 Jan '03

LargeWord's <, >, <=, and >= operators seem to be doing signed comparisons, contrary to their intended behavior (and the behavior of LargeWord.compare). A transcript follows -- note the last line: Poly/ML RTS version I386-4.1.3 (13:57:33 Sep 30 2002) Copyright (c) 2002 CUTS and contributors. Running with heap parameters (h=10240K,ib=2048K,ip=100%,mb=6144K,mp=20%) Mapping /u/richards/local/i386/lib/poly/ML_dbase Poly/ML 4.1.3 Release > LargeWord.compare(0w1, 0wx7FFFFFFF); val it = LESS : General.order > LargeWord.<=(0w1,0wx7FFFFFFF); val it = true : bool > LargeWord.compare(0w1, 0wx80000000); val it = LESS : General.order > LargeWord.<=(0w1,0wx80000000); val it = false : bool -- Chris

4 4

Handling Interrupts
by Frank Pfenning 31 Dec '02

31 Dec '02

Along similar lines: I have a Twelf top-level function in server that should interrupt the current computation and return to the Twelf top-level, not to an ML debugger or the ML top-level. I saw the documentation on signals, but I don't see how to achieve the desired effect because the handler will be run in a different thread. Any advice or help would be appreciated. - Frank

3 5

Poly/ML -- Exporting stand-alone applications
by Frank Pfenning 20 Dec '02

20 Dec '02

I have ported the Twelf logical framework implementation from SML/NJ to Poly/ML. The changes were significant, because Twelf was not SML'97 standards compliant as far as its uses of module features are concerned. The only other change had to do with the absence of a Word32 structure in Poly/ML. Now I would like to export a standalone Twelf server. Usually, this is run as an inferior process to Emacs and should not carry the ML compiler, for example. The FAQ gives a method to achieve this (sort of) using PolyML.onEntry. Has there been any progress on making it possible to export stand-along executables? Thanks, - Frank ---------------------------------------------------------------------- Frank Pfenning Phone: +1 412 268-6343 Department of Computer Science Fax: +1 412 268-3608 Carnegie Mellon University Email: fp(a)cs.cmu.edu Pittsburgh, PA 15213-3891, U.S.A. URL: http://www.cs.cmu.edu/~fp/ ----------------------------------------------------------------------

1 0

Re: basis/Net* and basis/*Sock* modules (polyml digest, Vol 1 #26)
by jeremy＠discus.anu.edu.au 26 Nov '02

26 Nov '02

Another question: are the basis/Net* and basis/*Sock* modules documented anywhere? I have a version of the Basis document dated August 5, 1997 by Jonh Reppy. Has it been amended since? If yes, where can I get the current version? http://sml.sourceforge.net/Basis/ Jeremy

1 0

proc-enums?
by itz＠speakeasy.org 25 Nov '02

25 Nov '02

The documentation for CInterface says among many other things: We would like to convert C-enumerations like colour into an equivalent ML datatype, together with functions to convert between values of the datatype and ML integers. This can be achieved automatically by using the script proc-enums, contained in the scripts subdirectory of the source tree. I don't see any such script anywhere in the tarballs from which I built PolyML: driver, mlsource, or basis. In fact, if I should believe "locate" it isn't anywhere on my machine :) Where oh where is it hiding? -- Ian Zimmerman, Oakland, California, U.S.A. I did not vote for Emperor Bush. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087

2 2

feature request: make
by itz＠speakeasy.org 19 Nov '02

19 Nov '02

Would it be possible for PolyML.make to return a boolean indicating success/failure? -- Ian Zimmerman, Oakland, California, U.S.A. I did not vote for Emperor Bush. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087

2 2

PolyML 4.1.3 now released
by David.Matthews＠prolingua.co.uk 04 Oct '02

04 Oct '02

PolyML version 4.1.3 is now available. Below are a list of the major changes and bug fixes since the 4.1.2 release taken from the release notes. Version 4.1.3 has been available unofficially for a while but the release on the web site is now complete and this incorporates a few bug fixes which were only found during testing. As usual I welcome comments and bug reports and I'll try to respond fairly quickly but the response will depend on pressure of other work. David New features and Changes Printing control switches New switches have been added to the Poly/ML.Compiler structure to control the printing of declarations. In both cases the default setting is true. Setting PolyML.Compiler.printInAlphabeticalOrder causes declarations to be printed in the order in which they were made rather than in alphabetical order. Setting PolyML.Compiler.printTypesWithStructureName to false causes types to be printed without the structure from which they came. Large database support The support for large databases has been improved and it is now possible to create a database which will occupy all of the virtual memory reserved for it. The actual limits vary between operating systems and platforms but are typically around 400Mbytes. To aid this the -S option when running the disc garbage-collector (-d option), introduced in 4.1.1, has been extended with -Smin and -Smax. The options can be written using either -s or -S and with or without a space. Setting a size is now "sticky" so if no -s/-S option is given the previous limits are retained rather than being reset to the default. The -Smax option sets the limits to the maximum space available. This space now depends only on the size reserved for any parent databases and not, as before, on the history of the database. The -Smin option compacts the database into a size whose upper limit is set to the size actually in use before compaction. To make best use of it it is probably best to run it twice, once to compact the database and again to set the upper limits to the now reduced size. It is useful when a database has been created which will not be modified further but where child databases may be created. Compacting a database to the minimum size allows any child databases to occupy as much space as possible. The disc garbage collection has been changed so that it is now possible to use all the address space. Previously it was always necessary to reserve a certain portion of the space to allow the database to be collected. Bugs fixed Mac OS X 10.2 Mac OS X 10.2 introduced a undocumented change to the kernel interface when delivering signals. This meant that the original binaries will not run on 10.2. This has now been fixed. Crash on delivering console interrupt on PowerPC There was a bug in the Poly/ML process (lightweight thread) code on the PowerPC which caused a crash when a process terminated. This could happen when a user-installed signal handler was called, for example the console interrupt handler in Isabelle. Crash in equality code An error in the compilation of the equality function meant that certain expressions involving equality could cause a crash. This has been fixed.

2 3

Poly/ML on Mac OS X
by David.Matthews＠prolingua.co.uk 20 Sep '02

20 Sep '02

Several people contacted me about Mac OS X 10.2 so I decided to take the plunge and buy it. I managed to track down the problem and you can find an updated version of Poly/ML in http://www.polyml.org/distrib/polyml-macosx.4.1.3.tar.gz . This contains executable and database and will only run on version 10.2 . I'll update the source in due course. For those who are interested, the problem was that the kernel included with 10.2 calls a signal handler with different parameters from previous versions. Previously it was called with a sigcontext structure containing register information, now the kernel seems to follow Solaris in providing a ucontext structure. Poly/ML needs this information because it uses a variety of signals to deal with things such as writes to database mutables, long-precision arithmetic and garbage-collection traps. Needless to say the change was not documented and the signal man page still refers to sigcontext, indeed it appears not to have changed since 1994. The only way I managed to find out what was going on was to download the Darwin kernel source and look at that. At least the source is available. The way the change was made means that it would be difficult to provide a binary that would work under 10.2 and also earlier versions of Mac OS X. It's also difficult to provide source that will automatically select the correct version when it's compiled. I'm going to assume that most people will have upgraded to 10.2 and concentrate on that. Let me know if there are any further problems. David.

1 0

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