mlton-user — [MLton-user] User community discussion

[MLton-user] [Call for submissions TFPiE 2024] Trends in Functional Programming in Education - January 9 2024, Seton Hall University, USA

[Peter A. <P.A...@cs...>]

TFPIE 2024 Call for papers
https://wiki.tfpie.science.ru.nl/TFPIE2024
(January 9th 2024, West Orange, NJ, USA, co-located with TFP 2024 at
Seton Hall University)

TFPIE 2024 welcomes submissions describing techniques used in the classroom,
tools used in and/or developed for the classroom and any creative use of
functional programming (FP) to aid education in or outside Computer Science.
Topics of interest include, but are not limited to:

   FP and beginning CS students
   FP and Computational Thinking
   FP and Artificial Intelligence
   FP in Robotics
   FP and Music
   Advanced FP for undergraduates
   FP in graduate education
   Engaging students in research using FP
   FP in Programming Languages
   FP in the high school curriculum
   FP as a stepping stone to other CS topics
   FP and Philosophy
   The pedagogy of teaching FP
   FP and e-learning: MOOCs, automated assessment etc.
   Best Lectures - more details below

In addition to papers, we are requesting best lecture presentations. 
What's your
best lecture topic in an FP related course? Do you have a fun way to 
present FP
concepts to novices or perhaps an especially interesting presentation of a
difficult topic? In either case, please consider sharing it. Best 
lecture topics
will be selected for presentation based on a short abstract describing the
lecture and its interest to TFPIE attendees. The length of the presentation
should be comparable to that of a paper. In addition, the speaker can 
provide
commentary on effectiveness or student feedback.

Submissions

Potential presenters are invited to submit an extended abstract (4-6 
pages) or
a draft paper (up to 20 pages) in EPTCS style. The authors of accepted
presentations
will have their preprints and their slides made available on the
workshop's website.
Papers and abstracts can be submitted via easychair at the following link:

https://easychair.org/conferences/?conf=tfpie2024

After the workshop, presenters are invited to submit (a revised
version of) their
article for the formal review. The PC will select the best articles
for publication
in the Electronic Proceedings in Theoretical Computer Science (EPTCS). 
Articles
rejected for presentation and extended abstracts will not be formally 
reviewed
by the PC.

Important Dates

Submission deadline: December 26th 2023, Anywhere on Earth
Notification: by December 30th 2023 (Note: submissions will be
evaluated on a rolling basis, so earlier submissions will receive an
earlier response)
TFPIE Registration Deadline: TBA
Workshop: January 9th 2024
Submission for formal review: April 19th 2024, Anywhere on Earth.
Notification of full article: May 24th 2024
Camera ready: June 28th 2024

Program Committee - TBD

         Stephen Chang (Chair) - UMass Boston, USA

Registration information

See https://wiki.tfpie.science.ru.nl/TFPIE2024 for updated information.

Registration and attendance are mandatory for at least one author of 
every paper
that is presented at the workshop. Presenters will have their
registration fee waived.

Only papers that have been presented at TFPIE may be submitted to the
post-reviewing
process.

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] ICFP 2023: Call for Participation

['ICFP P. v. MLton-u. <mlt...@ml...>]

=====================================================================
                        Call for Participation

            The 28th ACM SIGPLAN International Conference
              on Functional Programming (ICFP 2023) and
                          affiliated events

                      https://icfp23.sigplan.org
                     Seattle, USA; Sep 4-9, 2023
=====================================================================

ICFP is a celebration of the art and science of functional
programming, providing a forum for researchers and developers to
engage on a variety of topics, from foundations to features, and from
abstraction to application.

You are invited to participate in a full week dedicated to functional
programming, featuring the ICFP main conference as well as several
other related events.

 * Accepted Papers:
   https://icfp23.sigplan.org/track/icfp-2023-papers#event-overview

 * Registration:
   https://icfp23.sigplan.org/attending/registration
   The early-bird deadline is August 5, 2023

 * Hotel: The Westin Seattle
   https://icfp23.sigplan.org/venue/icfp-2023-venue
   Conference hotel reservation cutoff: August 11, 2023

There are several events affiliated with ICFP:

 September 4
   Erlang
     - https://icfp23.sigplan.org/home/erlang-2023
   FHPN
     - https://icfp23.sigplan.org/home/FHPNC-2023
   HIW
     - https://icfp23.sigplan.org/home/hiw-2023
   HOPE
     - https://icfp23.sigplan.org/home/hope-2023
   PLMW
     - https://icfp23.sigplan.org/track/plmw-icfp-2023
   TyDe
     - https://icfp23.sigplan.org/home/TyDe-2023

 September 5-7
   ICFP - Main conference

 September 8
   Haskell
     - https://icfp23.sigplan.org/home/haskellsymp-2023
   FARM
     - https://icfp23.sigplan.org/home/farm-2023
   FUNARCH
     - https://icfp23.sigplan.org/home/FUNARCH-2023
   ML
     - https://icfp23.sigplan.org/home/mlworkshop-2023
   miniKanren
     - https://icfp23.sigplan.org/home/minikanren-2023
   Tutorial: Vehicle, A Specification Language for Neural Network Properties
   Tutorial: Porting Lwt applications to OCaml 5 and Eio

 September 9
   Haskell
     - https://icfp23.sigplan.org/home/haskellsymp-2023
   Scheme
     - https://icfp23.sigplan.org/home/scheme-2023
   OCaml
     - https://icfp23.sigplan.org/home/ocaml-2023
   DeclMed
     - https://icfp23.sigplan.org/home/declmed-2023
   Tutorial: Teaching and Learning Compilers Incrementally
   Tutorial: Teaching functional programming

Conference organizers:

  https://icfp23.sigplan.org/committee/icfp-2023-organizing-committee

=====================================================================

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] mlton-user@mlton.org

[Peter A. <P.A...@cs...>]

# TFP 2024 -- Call for Papers
(trendsfp.github.io)

## Important Dates

Submission deadline: pre-symposium, full papers,  Saturday 4 November, 2023
Submission deadline: pre-symposium, draft papers, Wednesday 30 November, 
2023
Notification:        pre-symposium submissions,   Friday 8 December, 2023
TFPIE Workshop:                                   Tuesday 9 January, 2024
TFP Symposium:                                    Wednesday 10 - Friday 
12 January, 2024
Submission deadline: post-symposium review,       Friday 23 February, 2024
Notification:        post-symposium submissions,  Friday 5 April, 2024

The Symposium on Trends in Functional Programming (TFP) is an international
forum for researchers with interests in all aspects of functional 
programming,
taking a broad view of current and future trends in the area. It aspires to
be a lively environment for presenting the latest research results, and 
other
contributions.

This year, TFP will take place in-person at Seton Hall University, in South
Orange, NJ in the United States. It is co-located with the Trends in 
Functional
Programming in Education (TFPIE) workshop, which will take on the day 
before
the main symposium.

Please be aware that TFP has several submission deadlines. The first, 
November 4,
is for authors that wish to have their full paper reviewed prior to the 
symposium.
Papers that are accepted in this way must also be presented at the 
symposium. The
second, November 30, is for authors that wish to present their work or 
work-in
progress at the symposium first without submitting to the full review 
process for
publication. These authors can then take into account feedback received 
at the
symposium and submit a full article for review by the third deadline, 
February 23.

## Scope

The symposium recognizes that new trends may arise through various 
routes. As part
of the Symposium's focus on trends we therefore identify the following 
five article
categories. High-quality articles are solicited in any of these categories:

* Research Articles:
   Leading-edge, previously unpublished research work
* Position Articles:
   On what new trends should or should not be
* Project Articles:
   Descriptions of recently started new projects
* Evaluation Articles:
   What lessons can be drawn from a finished project
* Overview Articles:
   Summarizing work with respect to a trendy subject

Articles must be original and not simultaneously submitted for 
publication to any
other forum. They may consider any aspect of functional programming: 
theoretical,
implementation-oriented, or experience-oriented. Applications of functional
programming techniques to other languages are also within the scope of 
the symposium.

Topics suitable for the symposium include, but are not limited to:

* Functional programming and multicore/manycore computing
* Functional programming in the cloud
* High performance functional computing
* Extra-functional (behavioural) properties of functional programs
* Dependently typed functional programming
* Validation and verification of functional programs
* Debugging and profiling for functional languages
* Functional programming in different application areas:
   security, mobility, telecommunications applications, embedded
   systems, global computing, grids, etc.
* Interoperability with imperative programming languages
* Novel memory management techniques
* Program analysis and transformation techniques
* Empirical performance studies
* Abstract/virtual machines and compilers for functional languages
* (Embedded) domain specific languages
* New implementation strategies
* Any new emerging trend in the functional programming area

If you are in doubt on whether your article is within the scope of TFP, 
please contact
the TFP 2024 program chair, Jason Hemann.

## Best Paper Awards

TFP awards two prizes for the best papers each year.

First, to reward excellent contributions, TFP awards a prize for the 
best overall paper
accepted for the post-conference formal proceedings.

Second, each year TFP also awards a prize for the best student paper. 
TFP traditionally
pays special attention to research students, acknowledging that students 
are almost by
definition part of new subject trends. A student paper is one for which 
the authors
state that the paper is mainly the work of students, the students are 
the paper’s first
authors, and a student would present the paper.

In both cases, it is the PC of TFP that awards the prize. In case the 
best paper happens
to be a student paper, then that paper will receive both prizes.


## Instructions to Authors

Authors must submit papers to:

   <https://easychair.org/conferences/?conf=tfp24>

Authors of papers have the choice of having their contributions formally 
reviewed either
before or after the Symposium. Further, pre-symposium submissions may 
either be full
(earlier deadline) or draft papers (later deadline).


## Pre-symposium formal review

Papers to be formally reviewed before the symposium should be submitted 
before the early
deadline and will receive their reviews and notification of acceptance 
for both presentation
and publication before the symposium. A paper that has been rejected for 
publication but
accepted for presentation may be resubmitted for the post-symposium 
formal review.


## Post-symposium formal review

Draft papers will receive minimal reviews and notification of acceptance 
for presentation at
the symposium. Authors of draft papers will be invited to submit revised 
papers based on the
feedback receive at the symposium. A post-symposium refereeing process 
will then select a
subset of these articles for formal publication.


## Paper categories

Draft papers and papers submitted for formal review are submitted as 
extended abstracts (4 to
10 pages in length) or full papers (20 pages). The submission must 
clearly indicate which
category it belongs to: research, position, project, evaluation, or 
overview paper. It should
also indicate which authors are research students, and whether the main 
author(s) are students.
A draft paper for which all authors are students will receive additional 
feedback by one of the
PC members shortly after the symposium has taken place.


## Format

Papers must be written in English, and written using the LNCS style. For 
more information about
formatting please consult the Springer LNCS Guidelines web site:

<https://www.springer.com/gp/computer-science/lncs/conference-proceedings-guidelines>


## Organizing Committee
Jason Hemann      PC Chair            Seton Hall University, USA
Stephen Chang     Symposium Chair     University of Massachusetts 
Boston, USA
Shajina Anand     Local Arrangements  Seton Hall University, South 
Orange, USA

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] ICFP 2023: Call for Volunteers (Deadline: 30 June!)

['ICFP P. v. MLton-u. <mlt...@ml...>]

ICFP 2023
CALL FOR VOLUNTEERS
28th ACM SIGPLAN International Conference on Functional Programming

https://icfp23.sigplan.org/track/icfp-2023-volunteers

Sign up to be a Volunteer and help us make ICFP 2023 a unique
experience for all attendants!

ICFP 2023 is pleased to offer a number of opportunities for
volunteers, who are vital to the efficient operation and continued
success of the conference each year. The volunteer program is a chance
for people from around the world to participate in the conferences
whilst assisting us in preparing and running the event.

The Volunteer Program helps more people attend the ICFP conference by
covering conference fees, including access to the banquet (but not
travel or lodging expenses) in exchange for a fixed number of work
hours (usually from 12 to 15) helping with the conference
organization.

## How to apply

Please apply using this form (https://forms.gle/27pzbztJq5PVCZeW9).
The deadline is June 30th

## Eligibility

Everyone is welcome to apply. Priority is given to junior members of
our community, e.g. full- or part-time students of computer science
and related fields.

## Expectation

Applicants must be available for at least four (4) full days between
September 4th and September 9th, 2023, and will be expected to provide
a total of 12-15 hours of volunteering work in that time.

The skills, talents, and dedication of our Volunteers contribute to
the overall quality of the conference. The Volunteer role this year
will mainly involve working with the organizers to prepare for the
conference by providing technical assistance to attendees, managing
online Q&A and poster sessions, and supporting active communication in
our online environment.

## Compensation

* A Complimentary Conference Registration, offering access to all open
sessions (i.e., parallel paper presentations, demonstrations, and
workshops) and conference proceedings.
* Free lunches and refreshments during breaks.
* Volunteer garments.
* Free admission to all social events.

Please note that volunteers are responsible for their own travel and
accommodation arrangements.

If you need additional travel funding, please consider SIGPLAN PAC
Funding (http://www.sigplan.org/PAC/) and PLMW
(https://icfp23.sigplan.org/track/plmw-icfp-2023).

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] user structure `Position` being hidden or overwritten?

[Matthew F. <mat...@gm...>]

The typical way of structuring a utility library (like your
impossible.mlb and values.mlb) would be like:

impossible.mlb::
local
  $(SML_LIB)/basis/basis.mlb
in
  impossible.sml
end

values.mlb::
local
  $(SML_LIB)/basis/basis.mlb
  $(SML_LIB)/smlnj-lib/smlnj-lib.mlb
  $(SML_LIB)/smlnj-lib/Util/smlnj-lib.mlb
  impossible.mlb
in
  generator.sml

  hash-mlton.sml

  cset.sml
  seq.sml
  table.sml
  set.sml
end

The Basis to which an MLB file elaborates is the Basis in scope at the
end of the file.  So, something like:

impossible.mlb::
$(SML_LIB)/basis/basis.mlb
impossible.sml

has everything from the Standard Basis plus impossible.sml in its
Basis.  Similarly, with your original values.mlb.  Then in icon.mlb,
when you write:

icon.mlb::
  ...
  position.sml
  ...
  parse.sml

  values.mlb

  error.sml
  ...

the `structure Position` introduced by `position.sml` is shadowed by
the `structure Position` (re)introduced by `values.mlb`.  (The dynamic
semantics of MLB files is that they are only evaluated on their first
occurrence in a project; subsequent occurrences simply bring into
scope the dynamic (resp. static) Basis to which the first occurrence
evaluated (resp. elaborated).)

-Matthew


On Tue, Jun 13, 2023 at 3:04 PM Norman Ramsey <nr...@cs...> wrote:
>
>  > There is `structure Position: INTEGER` in the Basis Library.
>
> Ah, that would explain it.  I never thought to look there.
>
> It is getting spliced in at an odd placed, though, because sometimes
> Position has resolved to my version, and sometimes not.
>
>  > What does the MLB file that includes the mllex/mlyacc
>  > generated files look like?
>
> They are attached below; the one I compile is `icon.mlb`.
> File `ast.sml` contains a reference to `Position` that resolves to my
> version.  The other two files that refer to it (`scanning.sml` and
> `eval.sml`, as shown in the error message) are getting the Basis
> version.
>
> Since there is in fact a `Position` in the basis, renaming mine sounds
> like an appropriate, permanent fix.
>
>
> Norman
>
>
>  > On Fri, Jun 9, 2023 at 11:48 AM Norman Ramsey <nr...@cs...> wrote:
>  >
>  > > I ran into an odd issue trying to name one of my own structures
>  > > `Position`.  Some uses are just fine, but once code generated by
>  > > mllex/mlyacc intervenes, it looks as if some other `Position` is taking
>  > > its place:
>  > >
>  > >     /usr/local/mlton-20210117-1.amd64-linux-glibc2.23/bin/mlton -output
>  > > ii.opt -verbose 1 icon.mlb
>  > >     MLton 20210117 starting
>  > >        Compile SML starting
>  > >     Error: scanning.sml 25.14-25.34.
>  > >       Undefined type: Position.section_type.
>  > >     Error: scanning.sml 36.27-36.44.
>  > >       Undefined variable: Position.leftIndex.
>  > >     Error: eval.sml 97.21-97.38.
>  > >       Undefined variable: Position.leftIndex.
>  > >     Error: eval.sml 101.21-101.38.
>  > >       Undefined variable: Position.leftIndex.
>  > >        Compile SML reported errors in 1.23 + 0.97 (44% GC)
>  > >     MLton 20210117 reported errors in 1.23 + 0.97 (44% GC)
>  > >
>

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] user structure `Position` being hidden or overwritten?

[Norman R. <nr...@cs...>]

 > There is `structure Position: INTEGER` in the Basis Library.  

Ah, that would explain it.  I never thought to look there.

It is getting spliced in at an odd placed, though, because sometimes
Position has resolved to my version, and sometimes not.

 > What does the MLB file that includes the mllex/mlyacc
 > generated files look like?

They are attached below; the one I compile is `icon.mlb`.
File `ast.sml` contains a reference to `Position` that resolves to my
version.  The other two files that refer to it (`scanning.sml` and
`eval.sml`, as shown in the error message) are getting the Basis
version.

Since there is in fact a `Position` in the basis, renaming mine sounds
like an appropriate, permanent fix.


Norman


 > On Fri, Jun 9, 2023 at 11:48 AM Norman Ramsey <nr...@cs...> wrote:
 > 
 > > I ran into an odd issue trying to name one of my own structures
 > > `Position`.  Some uses are just fine, but once code generated by
 > > mllex/mlyacc intervenes, it looks as if some other `Position` is taking
 > > its place:
 > >
 > >     /usr/local/mlton-20210117-1.amd64-linux-glibc2.23/bin/mlton -output
 > > ii.opt -verbose 1 icon.mlb
 > >     MLton 20210117 starting
 > >        Compile SML starting
 > >     Error: scanning.sml 25.14-25.34.
 > >       Undefined type: Position.section_type.
 > >     Error: scanning.sml 36.27-36.44.
 > >       Undefined variable: Position.leftIndex.
 > >     Error: eval.sml 97.21-97.38.
 > >       Undefined variable: Position.leftIndex.
 > >     Error: eval.sml 101.21-101.38.
 > >       Undefined variable: Position.leftIndex.
 > >        Compile SML reported errors in 1.23 + 0.97 (44% GC)
 > >     MLton 20210117 reported errors in 1.23 + 0.97 (44% GC)
 > >

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] user structure `Position` being hidden or overwritten?

[Matthew F. <mat...@gm...>]

There is `structure Position: INTEGER` in the Basis Library.  If you've
imported the Basis Library to satisfy the requirements of the generated
mllex/mlyacc code, then perhaps you've not sufficiently limited the scope
of the import.  What does the MLB file that includes the mllex/mlyacc
generated files look like?


On Fri, Jun 9, 2023 at 11:48 AM Norman Ramsey <nr...@cs...> wrote:

> I ran into an odd issue trying to name one of my own structures
> `Position`.  Some uses are just fine, but once code generated by
> mllex/mlyacc intervenes, it looks as if some other `Position` is taking
> its place:
>
>     /usr/local/mlton-20210117-1.amd64-linux-glibc2.23/bin/mlton -output
> ii.opt -verbose 1 icon.mlb
>     MLton 20210117 starting
>        Compile SML starting
>     Error: scanning.sml 25.14-25.34.
>       Undefined type: Position.section_type.
>     Error: scanning.sml 36.27-36.44.
>       Undefined variable: Position.leftIndex.
>     Error: eval.sml 97.21-97.38.
>       Undefined variable: Position.leftIndex.
>     Error: eval.sml 101.21-101.38.
>       Undefined variable: Position.leftIndex.
>        Compile SML reported errors in 1.23 + 0.97 (44% GC)
>     MLton 20210117 reported errors in 1.23 + 0.97 (44% GC)
>
> I've confirmed that the issue is with the name; if I change the name
> to `MyPosition`, everything works as I expect.
>
> I see there's a `Position` in `basis-extra` and that it is mentioned
> in ml-lpt-lib.mlb, but it doesn't look as if it leaks out.
>
> Is there a way for me to configure my own MLB files so that I can use
> the name `Position`?  It's not mentioned in any of the code generated
> by mlyacc or mllex.
>
>
> Norman
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlt...@ml....
>
>
>
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user
>

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] user structure `Position` being hidden or overwritten?

[Norman R. <nr...@cs...>]

I ran into an odd issue trying to name one of my own structures
`Position`.  Some uses are just fine, but once code generated by
mllex/mlyacc intervenes, it looks as if some other `Position` is taking
its place:

    /usr/local/mlton-20210117-1.amd64-linux-glibc2.23/bin/mlton -output ii.opt -verbose 1 icon.mlb
    MLton 20210117 starting
       Compile SML starting
    Error: scanning.sml 25.14-25.34.
      Undefined type: Position.section_type.
    Error: scanning.sml 36.27-36.44.
      Undefined variable: Position.leftIndex.
    Error: eval.sml 97.21-97.38.
      Undefined variable: Position.leftIndex.
    Error: eval.sml 101.21-101.38.
      Undefined variable: Position.leftIndex.
       Compile SML reported errors in 1.23 + 0.97 (44% GC)
    MLton 20210117 reported errors in 1.23 + 0.97 (44% GC)

I've confirmed that the issue is with the name; if I change the name
to `MyPosition`, everything works as I expect.

I see there's a `Position` in `basis-extra` and that it is mentioned
in ml-lpt-lib.mlb, but it doesn't look as if it leaks out.

Is there a way for me to configure my own MLB files so that I can use
the name `Position`?  It's not mentioned in any of the code generated
by mlyacc or mllex.


Norman

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] LOPSTR 2023 - Final CFP - Extended paper deadline: June 9, 2023

[<dan...@im...>]

** Apologies for multiple postings **

33rd International Symposium on Logic-based Program Synthesis and
Transformation (LOPSTR 2023)
Co-located with PPDP 2023 as part of SPLASH 2023

October 23-24, 2023 - Cascais, Lisbon, Portugal

https://lopstr.github.io/2023/

Important dates:
 - Paper submission: June 9, 2023 (AoE)
 - Author notification: July 24, 2023 (AoE)
 - Camera-ready: August 18, 2023 
 - Symposium: October 23-24, 2023

OVERVIEW

The aim of the LOPSTR series is to stimulate and promote international
research and collaboration on logic-based program development. LOPSTR
is open to contributions in logic-based program development in any
language paradigm. LOPSTR has a reputation for being a lively,
friendly forum for presenting and discussing work in progress.

LOPSTR 2023 will be held in-person at Hotel Cascais Miragem in
Cascais, Lisbon, Portugal and will be co-located with PPDP 2023 as
part of SPLASH 2023. At least one of the authors of the accepted paper
is expected to attend the conference and present the paper. Information
about venue and travel is available on the SPLASH 2023 website.

Topics of interest cover all aspects of logic-based program
development, all stages of the software life cycle, and issues of both
programming-in-the-small and programming-in-the-large, including, but
not limited to:

 - synthesis
 - transformation
 - specialization
 - inversion
 - composition
 - optimisation
 - specification
 - analysis and verification
 - testing and certification
 - program and model manipulation
 - AI-methods for program development
 - verification and testing of AI-based systems
 - transformational techniques in software engineering
 - logic-based methods for security, cyber-physical and distributed
   system
 - applications, tools and industrial practice

Survey papers that present some aspects of the above topics from a new
perspective and papers that describe experience with industrial
applications and case studies are also welcome.

PAPER SUBMISSION

Submissions can be made in two categories:

 - Regular Papers (15 pages max.)
 - Short Papers (8 pages max.)

References do NOT count towards the page limit. Additional pages may
be used for appendices not intended for publication. Reviewers are not
required to read the appendices, and thus papers should be
intelligible without them. All submissions must be written in English.

Submissions must not substantially overlap with papers/tools that have
been published or that are simultaneously submitted to a journal,
conference, or workshop with refereed proceedings.

Submissions of Regular Papers must describe the original work. Work
that already appeared in unpublished or informally published workshop
proceedings may be submitted (please contact the PC chair in case of
questions).

Submissions of Short Papers may include presentations of exciting if
not fully polished research and tool demonstrations that are of
academic and industrial interest. Tool demonstrations should describe
the relevant system, usability, and implementation aspects of a tool.

All accepted papers will be included in the conference proceedings and
published by Springer as a Lecture Notes in Computer Science (LNCS)
volume.

After the symposium, a selection of a few best papers will be invited
for submission to rapid publication in the Journal of Theory and
Practice of Logic Programming (TPLP). Authors of selected papers will
be invited to revise and/or extend their submissions to be considered
for publication. The papers submitted to TPLP will be subject to the
standard reviewing process of the journal.

SUBMISSION GUIDELINES

Authors should submit an electronic copy of the paper (written in
English) in PDF, formatted in the Lecture Notes in Computer Science
style. Each submission must include on its first page the paper title;
authors and their affiliations; contact author's email; abstract; and
three to four keywords which will be used to assist the PC in
selecting appropriate reviewers for the paper. Authors should consult
Springer's authors' instructions at the author's page, and use their
proceedings templates, either for LaTeX (available also in overleaf)
or for Word, for the preparation of their papers. Springer encourages
authors to include their ORCIDs in their papers. In addition, upon
acceptance, the corresponding author of each paper, acting on behalf
of all of the authors of that paper, must complete and sign a
Consent-to-Publish form. The corresponding author signing the
copyright form should match the corresponding author marked on the
paper. Once the files have been sent to Springer, changes relating to
the authorship of the papers cannot be made.

Page numbers (and, if possible, line numbers) should appear on the
manuscript to help the reviewers in writing their report. So, for
LaTeX, we recommend that authors use:

\pagestyle{plain}
\usepackage{lineno}
\linenumbers

Papers should be submitted via EasyChair:
https://easychair.org/conferences/?conf=lopstr2023

BEST PAPER AWARD

Thanks to Springer's sponsorship, two best paper awards (one for each
submission category), with a 500 EUR prize, will be given at LOPSTR
2023. The program committee will select the winning papers based on
relevance, originality and technical quality but may also take
authorship into account (e.g. a student paper).

PROGRAM CHAIRS

Robert Glück, University of Copenhagen, Denmark
Bishoksan Kafle, IMDEA Software Institute, Spain

PUBLICITY CHAIR

Daniel Jurjo Rivas, IMDEA Software Institute, Spain

PROGRAM COMMITTEE MEMBERS

Slim Abdennadher, German International University, Egypt
José Júlio Alferes, Universidade Nova de Lisboa, Portugal
Roberto Amadini, University of Bologna, Italy
William Byrd, University of Alabama at Birmingham, USA
Michael Codish, Ben-Gurion University of the Negev, Israel
Gregory Duck, National University of Singapore, Singapore
Isabel García-Contreras, University of Waterloo, Canada
Ashutosh Gupta, IIT Bombay, India
Gopal Gupta, The University of Texas at Dallas, USA
Michael Hanus, University of Kiel, Germany
Temesghen Kahsai, Amazon, USA
Maja Hanne Kirkeby, Roskilde University, Denmark
Michael Leuschel, Heinrich Heine University Düsseldorf, Germany
Nai-Wei Lin, National Chung Cheng University, Taiwan
Fred Mesnard, University of Reunion, France
José F. Morales, IMDEA Software Institute, Spain
Carlos Olarte, Universitè Sorbonne Paris Nord, France
Alberto Pettorossi, Università di Roma Tor Vergata, Italy
Christoph Reichenbach, Lund University, Sweden
Peter Schachte, The University of Melbourne, Australia
Helge Spieker, Simula Research Laboratory, Norway
Theresa Swift, Universidade Nova de Lisboa, Portugal
Laura Titolo, National Institute of Aerospace, USA
Kazunori Ueda, Waseda University, Japan
Germán Vidal, Universitat Politècnica de València, Spain
Nisansala Yatapanage, Australian National University, Australia
Florian Zuleger, Vienna University of Technology, Austria

HISTORY

LOPSTR is a renowned symposium that has been held for more than 30
years.  The first meeting was held in Manchester, UK in
1991. Information about previous symposia:
http://lopstr.webs.upv.es/. You might have a look at the contents of
past LOPSTR symposia at DBLP
(https://dblp.uni-trier.de/db/conf/lopstr/index.html) and past LNCS
proceedings at Springer (https://link.springer.com/conference/lopstr).
    
Cheers, 

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] ICFP 2023: Call for Tutorial, Panel, and Discussion Proposals

['ICFP P. v. MLton-u. <mlt...@ml...>]

ICFP 2023
CALL FOR TUTORIAL, PANEL, AND DISCUSSION PROPOSALS
28th ACM SIGPLAN International Conference on Functional Programming


September 4 - 9, 2023
Seattle, WA, USA
https://icfp23.sigplan.org/


The 28th ACM SIGPLAN International Conference on Functional
Programming will be held in Seattle, WA, USA on September 4 - 9,
2023, with the option of virtual participation. ICFP provides a forum
for researchers and developers to hear about the latest work on the
design, implementations, principles, and uses of functional
programming.

Proposals are invited for tutorials, lasting approximately 3 hours each,
to be presented during ICFP and its co-located workshops and other events.
The tutorials may target an audience who is interested in commercial uses
of functional programming, but we also welcome tutorials whose primary
audience is researchers rather than practitioners. Tutorials may focus either
on a concrete technology or on a theoretical or mathematical tool. Ideally,
tutorials will have a concrete result, such as "Learn to do X with Y"
rather than "Learn language Y".

Just like last year, following the success of the #ShutDownPL event, we are also
inviting proposals for panels and discussions on topics of broader interest
to the PL community.

Tutorials, panels, and discussions may occur before or after ICFP,
co-located with the associated workshops, on September 4 or September 8-9.


----------------------------------------------------------------------

Submission details

Deadline for submission: May 23rd, 2023
Notification of acceptance: May 26th, 2023

Prospective organizers of tutorials are invited to submit a completed
tutorial proposal form in plain text format to the ICFP 2023 workshop
co-chairs (Arthur Azevedo de Amorim and Yannick Forster), via email to

icfp-workshops-2023 AT googlegroups.com

by May 23rd, 2023. Please note that this is a firm deadline.

The proposal form is available at:

http://www.icfpconference.org/icfp2023-files/icfp23-panel-form.txt
http://www.icfpconference.org/icfp2023-files/icfp23-tutorials-form.txt

----------------------------------------------------------------------

Selection committee

The proposals will be evaluated by a committee comprising the
following members of the ICFP 2023 organizing committee, together
with the members of the SIGPLAN executive committee.

Workshop Co-Chair: Arthur Azevedo de Amorim (Boston University)
Workshop Co-Chair: Yannick Forster (Inria Nantes)
General Chair: Nikhil Swamy (Microsoft Research)
Program Chair: Sam Lindley (University of Edinburgh)

----------------------------------------------------------------------

Further information

Any queries should be addressed to the workshop co-chairs (Arthur
Azevedo de Amorim and Yannick Forster), via email to
icfp-workshops-2023 AT googlegroups.com

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] LOPSTR 2023 (Lisbon) - Final Call for Papers - Paper Deadline: May 26, 2023.

[<dan...@im...>]

** Apologies for multiple postings **

33rd International Symposium on Logic-based Program Synthesis and
Transformation (LOPSTR 2023)
Co-located with PPDP 2023 as part of SPLASH 2023

October 23-24, 2023 - Cascais, Lisbon, Portugal

https://lopstr.github.io/2023/

Important dates:
 - Abstract submission: May 19, 2023 (AoE)
 - Paper submission: May 26, 2023 (AoE)
 - Author notification: July 24, 2023 (AoE)
 - Camera-ready: August 18, 2023 
 - Symposium: October 23-24, 2023

OVERVIEW

The aim of the LOPSTR series is to stimulate and promote international
research and collaboration on logic-based program development. LOPSTR
is open to contributions in logic-based program development in any
language paradigm. LOPSTR has a reputation for being a lively,
friendly forum for presenting and discussing work in progress.

LOPSTR 2023 will be held in-person at Hotel Cascais Miragem in
Cascais, Lisbon, Portugal and will be co-located with PPDP 2023 as
part of SPLASH 2023. At least one of the authors of the accepted paper
is expected to attend the conference and present the paper. Information
about venue and travel is available on the SPLASH 2023 website.

Topics of interest cover all aspects of logic-based program
development, all stages of the software life cycle, and issues of both
programming-in-the-small and programming-in-the-large, including, but
not limited to:

 - synthesis
 - transformation
 - specialization
 - inversion
 - composition
 - optimisation
 - specification
 - analysis and verification
 - testing and certification
 - program and model manipulation
 - AI-methods for program development
 - verification and testing of AI-based systems
 - transformational techniques in software engineering
 - logic-based methods for security, cyber-physical and distributed
   system
 - applications, tools and industrial practice

Survey papers that present some aspects of the above topics from a new
perspective and papers that describe experience with industrial
applications and case studies are also welcome.

PAPER SUBMISSION

Submissions can be made in two categories:

 - Regular Papers (15 pages max.)
 - Short Papers (8 pages max.)

References do NOT count towards the page limit. Additional pages may
be used for appendices not intended for publication. Reviewers are not
required to read the appendices, and thus papers should be
intelligible without them. All submissions must be written in English.

Submissions must not substantially overlap with papers/tools that have
been published or that are simultaneously submitted to a journal,
conference, or workshop with refereed proceedings.

Submissions of Regular Papers must describe the original work. Work
that already appeared in unpublished or informally published workshop
proceedings may be submitted (please contact the PC chair in case of
questions).

Submissions of Short Papers may include presentations of exciting if
not fully polished research and tool demonstrations that are of
academic and industrial interest. Tool demonstrations should describe
the relevant system, usability, and implementation aspects of a tool.

All accepted papers will be included in the conference proceedings and
published by Springer as a Lecture Notes in Computer Science (LNCS)
volume.

After the symposium, a selection of a few best papers will be invited
for submission to rapid publication in the Journal of Theory and
Practice of Logic Programming (TPLP). Authors of selected papers will
be invited to revise and/or extend their submissions to be considered
for publication. The papers submitted to TPLP will be subject to the
standard reviewing process of the journal.

SUBMISSION GUIDELINES

Authors should submit an electronic copy of the paper (written in
English) in PDF, formatted in the Lecture Notes in Computer Science
style. Each submission must include on its first page the paper title;
authors and their affiliations; contact author's email; abstract; and
three to four keywords which will be used to assist the PC in
selecting appropriate reviewers for the paper. Authors should consult
Springer's authors' instructions at the author's page, and use their
proceedings templates, either for LaTeX (available also in overleaf)
or for Word, for the preparation of their papers. Springer encourages
authors to include their ORCIDs in their papers. In addition, upon
acceptance, the corresponding author of each paper, acting on behalf
of all of the authors of that paper, must complete and sign a
Consent-to-Publish form. The corresponding author signing the
copyright form should match the corresponding author marked on the
paper. Once the files have been sent to Springer, changes relating to
the authorship of the papers cannot be made.

Page numbers (and, if possible, line numbers) should appear on the
manuscript to help the reviewers in writing their report. So, for
LaTeX, we recommend that authors use:

\pagestyle{plain}
\usepackage{lineno}
\linenumbers

Papers should be submitted via EasyChair:
https://easychair.org/conferences/?conf=lopstr2023

BEST PAPER AWARD

Thanks to Springer's sponsorship, two best paper awards (one for each
submission category), with a 500 EUR prize, will be given at LOPSTR
2023. The program committee will select the winning papers based on
relevance, originality and technical quality but may also take
authorship into account (e.g. a student paper).

PROGRAM CHAIRS

Robert Glück, University of Copenhagen, Denmark
Bishoksan Kafle, IMDEA Software Institute, Spain

PUBLICITY CHAIR

Daniel Jurjo Rivas, IMDEA Software Institute, Spain

PROGRAM COMMITTEE MEMBERS

Slim Abdennadher, German International University, Egypt
José Júlio Alferes, Universidade Nova de Lisboa, Portugal
Roberto Amadini, University of Bologna, Italy
William Byrd, University of Alabama at Birmingham, USA
Michael Codish, Ben-Gurion University of the Negev, Israel
Gregory Duck, National University of Singapore, Singapore
Isabel García-Contreras, University of Waterloo, Canada
Ashutosh Gupta, IIT Bombay, India
Gopal Gupta, The University of Texas at Dallas, USA
Michael Hanus, University of Kiel, Germany
Temesghen Kahsai, Amazon, USA
Maja Hanne Kirkeby, Roskilde University, Denmark
Michael Leuschel, Heinrich Heine University Düsseldorf, Germany
Nai-Wei Lin, National Chung Cheng University, Taiwan
Fred Mesnard, University of Reunion, France
José F. Morales, IMDEA Software Institute, Spain
Carlos Olarte, Universitè Sorbonne Paris Nord, France
Alberto Pettorossi, Università di Roma Tor Vergata, Italy
Christoph Reichenbach, Lund University, Sweden
Peter Schachte, The University of Melbourne, Australia
Helge Spieker, Simula Research Laboratory, Norway
Theresa Swift, Universidade Nova de Lisboa, Portugal
Laura Titolo, National Institute of Aerospace, USA
Kazunori Ueda, Waseda University, Japan
Germán Vidal, Universitat Politècnica de València, Spain
Nisansala Yatapanage, Australian National University, Australia
Florian Zuleger, Vienna University of Technology, Austria

HISTORY

LOPSTR is a renowned symposium that has been held for more than 30
years.  The first meeting was held in Manchester, UK in
1991. Information about previous symposia:
http://lopstr.webs.upv.es/. You might have a look at the contents of
past LOPSTR symposia at DBLP
(https://dblp.uni-trier.de/db/conf/lopstr/index.html) and past LNCS
proceedings at Springer (https://link.springer.com/conference/lopstr).
    
Cheers, 

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] LOPSTR 2023 (Lisbon) - Second Call for Papers - Paper Deadline: May 26, 2023.

[<dan...@im...>]

** Apologies for multiple postings **

33rd International Symposium on Logic-based Program Synthesis and
Transformation (LOPSTR 2023)
Co-located with PPDP 2023 as part of SPLASH 2023

October 23-24, 2023 - Cascais, Lisbon, Portugal

https://lopstr.github.io/2023/

Important dates:
 - Abstract submission: May 19, 2023 (AoE)
 - Paper submission: May 26, 2023 (AoE)
 - Author notification: July 24, 2023 (AoE)
 - Camera-ready: August 18, 2023 
 - Symposium: October 23-24, 2023

OVERVIEW

The aim of the LOPSTR series is to stimulate and promote international
research and collaboration on logic-based program development. LOPSTR
is open to contributions in logic-based program development in any
language paradigm. LOPSTR has a reputation for being a lively,
friendly forum for presenting and discussing work in progress.

LOPSTR 2023 will be held in-person at Hotel Cascais Miragem in
Cascais, Lisbon, Portugal and will be co-located with PPDP 2023 as
part of SPLASH 2023. At least one of the authors of the accepted paper
is expected to attend the conference and present the paper. Information
about venue and travel is available on the SPLASH 2023 website.

Topics of interest cover all aspects of logic-based program
development, all stages of the software life cycle, and issues of both
programming-in-the-small and programming-in-the-large, including, but
not limited to:

 - synthesis
 - transformation
 - specialization
 - inversion
 - composition
 - optimisation
 - specification
 - analysis and verification
 - testing and certification
 - program and model manipulation
 - AI-methods for program development
 - verification and testing of AI-based systems
 - transformational techniques in software engineering
 - logic-based methods for security, cyber-physical and distributed
   system
 - applications, tools and industrial practice

Survey papers that present some aspects of the above topics from a new
perspective and papers that describe experience with industrial
applications and case studies are also welcome.

PAPER SUBMISSION

Submissions can be made in two categories:

 - Regular Papers (15 pages max.)
 - Short Papers (8 pages max.)

References do NOT count towards the page limit. Additional pages may
be used for appendices not intended for publication. Reviewers are not
required to read the appendices, and thus papers should be
intelligible without them. All submissions must be written in English.

Submissions must not substantially overlap with papers/tools that have
been published or that are simultaneously submitted to a journal,
conference, or workshop with refereed proceedings.

Submissions of Regular Papers must describe the original work. Work
that already appeared in unpublished or informally published workshop
proceedings may be submitted (please contact the PC chair in case of
questions).

Submissions of Short Papers may include presentations of exciting if
not fully polished research and tool demonstrations that are of
academic and industrial interest. Tool demonstrations should describe
the relevant system, usability, and implementation aspects of a tool.

All accepted papers will be included in the conference proceedings and
published by Springer as a Lecture Notes in Computer Science (LNCS)
volume.

After the symposium, a selection of a few best papers will be invited
for submission to rapid publication in the Journal of Theory and
Practice of Logic Programming (TPLP). Authors of selected papers will
be invited to revise and/or extend their submissions to be considered
for publication. The papers submitted to TPLP will be subject to the
standard reviewing process of the journal.

SUBMISSION GUIDELINES

Authors should submit an electronic copy of the paper (written in
English) in PDF, formatted in the Lecture Notes in Computer Science
style. Each submission must include on its first page the paper title;
authors and their affiliations; contact author's email; abstract; and
three to four keywords which will be used to assist the PC in
selecting appropriate reviewers for the paper. Authors should consult
Springer's authors' instructions at the author's page, and use their
proceedings templates, either for LaTeX (available also in overleaf)
or for Word, for the preparation of their papers. Springer encourages
authors to include their ORCIDs in their papers. In addition, upon
acceptance, the corresponding author of each paper, acting on behalf
of all of the authors of that paper, must complete and sign a
Consent-to-Publish form. The corresponding author signing the
copyright form should match the corresponding author marked on the
paper. Once the files have been sent to Springer, changes relating to
the authorship of the papers cannot be made.

Page numbers (and, if possible, line numbers) should appear on the
manuscript to help the reviewers in writing their report. So, for
LaTeX, we recommend that authors use:

\pagestyle{plain}
\usepackage{lineno}
\linenumbers

Papers should be submitted via EasyChair:
https://easychair.org/conferences/?conf=lopstr2023

BEST PAPER AWARD

Thanks to Springer's sponsorship, two best paper awards (one for each
submission category), with a 500 EUR prize, will be given at LOPSTR
2023. The program committee will select the winning papers based on
relevance, originality and technical quality but may also take
authorship into account (e.g. a student paper).

PROGRAM CHAIRS

Robert Glück, University of Copenhagen, Denmark
Bishoksan Kafle, IMDEA Software Institute, Spain

PUBLICITY CHAIR

Daniel Jurjo Rivas, IMDEA Software Institute, Spain

PROGRAM COMMITTEE MEMBERS

Slim Abdennadher, German International University, Egypt
José Júlio Alferes, Universidade Nova de Lisboa, Portugal
Roberto Amadini, University of Bologna, Italy
William Byrd, University of Alabama at Birmingham, USA
Michael Codish, Ben-Gurion University of the Negev, Israel
Gregory Duck, National University of Singapore, Singapore
Isabel García-Contreras, University of Waterloo, Canada
Ashutosh Gupta, IIT Bombay, India
Gopal Gupta, The University of Texas at Dallas, USA
Michael Hanus, University of Kiel, Germany
Temesghen Kahsai, Amazon, USA
Maja Hanne Kirkeby, Roskilde University, Denmark
Michael Leuschel, Heinrich Heine University Düsseldorf, Germany
Nai-Wei Lin, National Chung Cheng University, Taiwan
Fred Mesnard, University of Reunion, France
José F. Morales, IMDEA Software Institute, Spain
Carlos Olarte, Universitè Sorbonne Paris Nord, France
Alberto Pettorossi, Università di Roma Tor Vergata, Italy
Christoph Reichenbach, Lund University, Sweden
Peter Schachte, The University of Melbourne, Australia
Helge Spieker, Simula Research Laboratory, Norway
Theresa Swift, Universidade Nova de Lisboa, Portugal
Laura Titolo, National Institute of Aerospace, USA
Kazunori Ueda, Waseda University, Japan
Germán Vidal, Universitat Politècnica de València, Spain
Nisansala Yatapanage, Australian National University, Australia
Florian Zuleger, Vienna University of Technology, Austria

HISTORY

LOPSTR is a renowned symposium that has been held for more than 30
years.  The first meeting was held in Manchester, UK in
1991. Information about previous symposia:
http://lopstr.webs.upv.es/. You might have a look at the contents of
past LOPSTR symposia at DBLP
(https://dblp.uni-trier.de/db/conf/lopstr/index.html) and past LNCS
proceedings at Springer (https://link.springer.com/conference/lopstr).
    
Cheers, 

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] [CFP] ML'23: Higher-order, Typed, Inferred, Strict: ACM SIGPLAN ML Family Workshop

[Matthew F. <mat...@gm...>]

Higher-order, Typed, Inferred, Strict: ACM SIGPLAN ML Family Workshop
September 8, 2023 (Friday) Seattle, WA, USA (day after main ICFP)

Call for presentations: https://icfp23.sigplan.org/home/mlworkshop-2023

ML Family Workshop is an established informal workshop aiming to
recognize the entire extended ML family and to provide the forum to
present and discuss common issues: all aspects of the design,
semantics, theory, application, implementation, and teaching of the
members of the ML family. We also encourage presentations from related
languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*,
Eff, ATS, etc), to promote the exchange of ideas and experience.  The
ML family workshop will be held in close coordination with the OCaml
Users and Developers Workshop.

We plan the workshop to an be in-person event with remote participation
(streamed live).  Speakers are generally expected to present in person
(we will work to make remote presentations possible).

We solicit proposals for contributed talks, in PDF format, with a
short summary at the beginning and the indication of the submission
category: Research Presentations, Experience Reports, Demos, and
Informed Positions. The point of the submission should be clear from
its first two pages (PC members are not obligated to read any
further.) We particularly encourage talks about works in progress,
presentations of negative results (things that were expected to but
did not quite work out) and informed positions.

* Deadline for talk proposals: ** Thursday June 1, 2023 **
* Notification of acceptance:  ** Thursday July 6, 2023 **
* Workshop:                    ** Friday September 8, 2023 **


Program Committee

Lars Bergstrom                  Google, USA
Martin Elsman                   University of Copenhagen, Denmark
Matthew Fluet                   Rochester Institute of Technology, USA
Jacques Garrigue                Nagoya University, Japan
Oleg Kiselyov                   Tohoku University, Japan (Chair)
Julia Lawall                    Inria-Paris, France
Andrey Mokhov                   Jane Street, UK
Benoît Montagu                  Inria-Rennes, France
Guillaume Munch-Maccagnoni      Inria, France
Matija Pretnar                  University of Ljubljana, Slovenia
Andreas Rossberg                Germany
Gabriel Scherer                 Inria-Saclay, France

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] CORRECTION - OPLSS 2023: Application Deadline April 13

[Stephanie B. <ba...@cs...>]

*** CORRECTION: APPLICATION DEADLINE IS APRIL 13 !!! ***


We are pleaded to announce the Program of this year’s Oregon Programming Languages Summer School (OPLSS)

https://www.cs.uoregon.edu/research/summerschool/summer23/topics.php

The school will take place from June 26 to July 8, 2023, at the University of Oregon in Eugene, USA.

Please apply by April 13, 2023 at

https://www.cs.uoregon.edu/research/summerschool/summer23/registration.php

We are looking forward to getting together!

OPLSS 2023 Organization Team
Zena Ariola, Stephanie Balzer, and Stephanie Weirich



-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] OPLSS 2023: Application Deadline April 23

[Stephanie B. <ba...@cs...>]

We are pleaded to announce the Program of this year’s Oregon Programming Languages Summer School (OPLSS)

https://www.cs.uoregon.edu/research/summerschool/summer23/topics.php

The school will take place from June 26 to July 8, 2023, at the University of Oregon in Eugene, USA.

Please apply by April 23, 2023 at

https://www.cs.uoregon.edu/research/summerschool/summer23/registration.php

We are looking forward to getting together!

OPLSS 2023 Organization Team
Zena Ariola, Stephanie Balzer, and Stephanie Weirich



-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] How is closure compiled?

[Matthew F. <mat...@gm...>]

If you are interested in measuring allocations, then it is probably easiest
to allocate data structures, like lists or trees.

If you are specifically interested in measuring allocations due to
closures, then you will need to make sure that the functions are really
used in a truly first-class manner, such as placed into a data structure at
one point in the program and then extracted and applied at another point in
the program.  When the use of a function is immediately after its
allocation, then MLton will quite often be able to inline the function and
eliminate the closure object entirely.

Moreover, a closure in MLton, when explicitly allocated, simply holds the
free variables of the function that are not also globals.  In your
binomialCoefficient, the only free variables are the Basis Library
functions `!`, `op <=`,  `op +`, `op *`, `op :=` -- all of which will be
globals and not need to be captured by closures.

Finally, the `-inline <n>` option sets a limit on the amount of code
duplication that can be incurred by inlining, but inlining that does not
duplicate code (such as inlining a function at its one and only call site)
is still allowed.  Your binomialCoefficient function is called at exactly
one place, so will be inlined.

Can you say more about what you are trying to measure?  Microbenchmarks in
MLton require careful consideration, because MLton will often optimize away
the aspect of the program that is being investigated.  One has to be very
careful to actually use the results of the computation (else MLton will
happily eliminate all of the code that is used to generate an unused
result).


On Mon, Mar 20, 2023 at 10:49 PM Cong Ma <co...@uw...> wrote:

> Thanks for the help! Inlining may explain what I see.
>
> However, I would like to write a program that does a lot of closure
> allocation on the heap for benchmarking purposes. I modified the program
> before so that the inner function is a bit more complicated, and I compiled
> it with "-inline 0” to turn off inlining. But the profiling data still
> shows there is not much heap allocation going on.
>
> What am I missing? How can I modify the program or the compiling option to
> make heap allocation happen?
>
> fun loop n acc =
>   if n > 10000000 then acc
>   else let
>          val binomialCoefficient = fn n => fn k =>
>           let
>               val numerator = ref n
>               val denominator = ref 1
>               val result = ref 1
>               val i = ref 1
>           in
>               while !i <= k do (
>                   result := !result * !numerator div !denominator;
>                   numerator := !numerator - 1;
>                   denominator := !denominator + 1;
>                   i := !i + 1
>               );
>               abs(acc - !result)
>           end;
>        in
>          loop (n + 1) (binomialCoefficient (n mod 5) (acc mod 5))
>        end;
> val _ = print (Int.toString(loop 0 0) ^ "\n”);
>
>
>
>
> > mlton -profile alloc -profile-stack true -inline 0 -cc-opt -fno-inline
> heap_alloc.sml
> > ./heap_alloc
> > mlprof -show-line true heap_alloc mlmon.out
>
> 5,048 bytes allocated (1,024 bytes by GC)
>                        function                         cur  stack  GC
> ------------------------------------------------------ ----- ----- -----
> <main>                                                 82.6% 83.1% 10.7%
> <gc>                                                   16.9%  0.0% 16.9%
> _res_Integer.fmt  $(SML_LIB)/basis/integer/int.sml: 74  0.5%  0.5%  0.0%
> General.o  $(SML_LIB)/basis/general/general.sml: 29     0.0%  0.0% 10.7%
>
>
> > On Mar 20, 2023, at 8:56 PM, Pierpaolo Bernardi <olo...@gm...>
> wrote:
> >
> > On Tue, Mar 21, 2023 at 1:52 AM Pierpaolo Bernardi <olo...@gm...>
> wrote:
> >>
> >> The function has no effect at all. So, I *guess*  that it is just
> >> optimized away.
> >>
> >> Try an example where the function does something which has an effect
> >> on the result of the computation. For example you could accumulate the
> >> results, like (just an example):
> >
> > But then, a function this simple, not escaping the definition
> > environment, and used only in one place, will probably be inlined, So
> > again, no closure...
> >
> > --
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to mlt...@ml....
> >
> >
> >
> > _______________________________________________
> > MLton-user mailing list
> > MLt...@li...; mlt...@ml...
> > https://lists.sourceforge.net/lists/listinfo/mlton-user
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlt...@ml....
>
>
>
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user
>

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] How is closure compiled?

[Cong Ma <co...@uw...>]

Thanks for the help! Inlining may explain what I see.

However, I would like to write a program that does a lot of closure allocation on the heap for benchmarking purposes. I modified the program before so that the inner function is a bit more complicated, and I compiled it with "-inline 0” to turn off inlining. But the profiling data still shows there is not much heap allocation going on.

What am I missing? How can I modify the program or the compiling option to make heap allocation happen?

fun loop n acc =
  if n > 10000000 then acc
  else let
         val binomialCoefficient = fn n => fn k =>
          let
              val numerator = ref n
              val denominator = ref 1
              val result = ref 1
              val i = ref 1
          in
              while !i <= k do (
                  result := !result * !numerator div !denominator;
                  numerator := !numerator - 1;
                  denominator := !denominator + 1;
                  i := !i + 1
              );
              abs(acc - !result)
          end;
       in
         loop (n + 1) (binomialCoefficient (n mod 5) (acc mod 5))
       end;  
val _ = print (Int.toString(loop 0 0) ^ "\n”);




> mlton -profile alloc -profile-stack true -inline 0 -cc-opt -fno-inline heap_alloc.sml
> ./heap_alloc
> mlprof -show-line true heap_alloc mlmon.out                                          
5,048 bytes allocated (1,024 bytes by GC)
                       function                         cur  stack  GC  
------------------------------------------------------ ----- ----- -----
<main>                                                 82.6% 83.1% 10.7%
<gc>                                                   16.9%  0.0% 16.9%
_res_Integer.fmt  $(SML_LIB)/basis/integer/int.sml: 74  0.5%  0.5%  0.0%
General.o  $(SML_LIB)/basis/general/general.sml: 29     0.0%  0.0% 10.7% 


> On Mar 20, 2023, at 8:56 PM, Pierpaolo Bernardi <olo...@gm...> wrote:
> 
> On Tue, Mar 21, 2023 at 1:52 AM Pierpaolo Bernardi <olo...@gm...> wrote:
>> 
>> The function has no effect at all. So, I *guess*  that it is just
>> optimized away.
>> 
>> Try an example where the function does something which has an effect
>> on the result of the computation. For example you could accumulate the
>> results, like (just an example):
> 
> But then, a function this simple, not escaping the definition
> environment, and used only in one place, will probably be inlined, So
> again, no closure...
> 
> -- 
> To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....
> 
> 
> 
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] How is closure compiled?

[Pierpaolo B. <olo...@gm...>]

On Tue, Mar 21, 2023 at 1:52 AM Pierpaolo Bernardi <olo...@gm...> wrote:
>
> The function has no effect at all. So, I *guess*  that it is just
> optimized away.
>
> Try an example where the function does something which has an effect
> on the result of the computation. For example you could accumulate the
> results, like (just an example):

But then, a function this simple, not escaping the definition
environment, and used only in one place, will probably be inlined, So
again, no closure...

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] How is closure compiled?

[Pierpaolo B. <olo...@gm...>]

The function has no effect at all. So, I *guess*  that it is just
optimized away.

Try an example where the function does something which has an effect
on the result of the computation. For example you could accumulate the
results, like (just an example):

fun loop n acc
...
    loop (n + 1) (acc + f n)

val _ = loop 0 0

On Sun, Mar 19, 2023 at 2:18 PM Cong Ma <co...@uw...> wrote:
>
> Hi all,
>
> I’m a graduate student at UWaterloo and I’m working on a compiler that uses MLton as the backend. To understand MLton’s behaviour, I ran this microbenchmark
>
> fun loop n =
>   if n > 100100100 then ()
>   else let
>          val f = fn x => x + n
>        in
>          f n;
>          loop (n + 1)
>        end;
> val _ = loop 0;
>
> I was expecting that during the runtime, a closure for "fn x” is heap-allocated in each recursive call. However, the profiling data shows that only very few bytes are allocated.
>
> 408 bytes allocated (448 bytes by GC)
>                    function                     cur  stack  GC
> ---------------------------------------------- ----- ----- -----
> <gc>                                           52.3%  0.0% 52.3%
> <main>                                         47.7% 47.7% 30.8%
> Exit.exit  $(SML_LIB)/basis/mlton/exit.sml: 31  0.0%  0.0% 30.8%
>
> My question is, how does MLton compile closures? Aren’t they heap-allocated?
>
> Regards
> Cong Ma
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] How is closure compiled?

[Cong Ma <co...@uw...>]

Hi all,

I’m a graduate student at UWaterloo and I’m working on a compiler that uses MLton as the backend. To understand MLton’s behaviour, I ran this microbenchmark

fun loop n =
  if n > 100100100 then ()
  else let
         val f = fn x => x + n
       in
         f n;
         loop (n + 1)
       end;
val _ = loop 0;

I was expecting that during the runtime, a closure for "fn x” is heap-allocated in each recursive call. However, the profiling data shows that only very few bytes are allocated.

408 bytes allocated (448 bytes by GC)
                   function                     cur  stack  GC
---------------------------------------------- ----- ----- -----
<gc>                                           52.3%  0.0% 52.3%
<main>                                         47.7% 47.7% 30.8%
Exit.exit  $(SML_LIB)/basis/mlton/exit.sml: 31  0.0%  0.0% 30.8%

My question is, how does MLton compile closures? Aren’t they heap-allocated?

Regards
Cong Ma

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] LOPSTR 2023 - Call for Papers

[<dan...@im...>]

** Apologies for multiple postings **

33rd International Symposium on Logic-based Program Synthesis and
Transformation (LOPSTR 2023)
Co-located with PPDP 2023 as part of SPLASH 2023

October 23-24, 2023 - Cascais, Lisbon, Portugal

https://lopstr.github.io/2023/

Important dates:
 - Abstract submission: May 19, 2023 (AoE)
 - Paper submission: May 26, 2023 (AoE)
 - Author notification: July 24, 2023 (AoE)
 - Camera-ready: August 18, 2023 
 - Symposium: October 23-24, 2023

OVERVIEW

The aim of the LOPSTR series is to stimulate and promote international
research and collaboration on logic-based program development. LOPSTR
is open to contributions in logic-based program development in any
language paradigm. LOPSTR has a reputation for being a lively,
friendly forum for presenting and discussing work in progress.

LOPSTR 2023 will be held in-person at Hotel Cascais Miragem in
Cascais, Lisbon, Portugal and will be co-located with PPDP 2023 as
part of SPLASH 2023. At least one of the authors of the accepted paper
is expected to attend the conference and present the paper. Information
about venue and travel is available on the SPLASH 2023 website.

Topics of interest cover all aspects of logic-based program
development, all stages of the software life cycle, and issues of both
programming-in-the-small and programming-in-the-large, including, but
not limited to:

 - synthesis
 - transformation
 - specialization
 - inversion
 - composition
 - optimisation
 - specification
 - analysis and verification
 - testing and certification
 - program and model manipulation
 - AI-methods for program development
 - verification and testing of AI-based systems
 - transformational techniques in software engineering
 - logic-based methods for security, cyber-physical and distributed
   system
 - applications, tools and industrial practice

Survey papers that present some aspects of the above topics from a new
perspective and papers that describe experience with industrial
applications and case studies are also welcome.

PAPER SUBMISSION

Submissions can be made in two categories:

 - Regular Papers (15 pages max.)
 - Short Papers (8 pages max.)

References do NOT count towards the page limit. Additional pages may
be used for appendices not intended for publication. Reviewers are not
required to read the appendices, and thus papers should be
intelligible without them. All submissions must be written in English.

Submissions must not substantially overlap with papers/tools that have
been published or that are simultaneously submitted to a journal,
conference, or workshop with refereed proceedings.

Submissions of Regular Papers must describe the original work. Work
that already appeared in unpublished or informally published workshop
proceedings may be submitted (please contact the PC chair in case of
questions).

Submissions of Short Papers may include presentations of exciting if
not fully polished research and tool demonstrations that are of
academic and industrial interest. Tool demonstrations should describe
the relevant system, usability, and implementation aspects of a tool.

All accepted papers will be included in the conference proceedings and
published by Springer as a Lecture Notes in Computer Science (LNCS)
volume.

After the symposium, a selection of a few best papers will be invited
for submission to rapid publication in the Journal of Theory and
Practice of Logic Programming (TPLP). Authors of selected papers will
be invited to revise and/or extend their submissions to be considered
for publication. The papers submitted to TPLP will be subject to the
standard reviewing process of the journal.

SUBMISSION GUIDELINES

Authors should submit an electronic copy of the paper (written in
English) in PDF, formatted in the Lecture Notes in Computer Science
style. Each submission must include on its first page the paper title;
authors and their affiliations; contact author's email; abstract; and
three to four keywords which will be used to assist the PC in
selecting appropriate reviewers for the paper. Authors should consult
Springer's authors' instructions at the author's page, and use their
proceedings templates, either for LaTeX (available also in overleaf)
or for Word, for the preparation of their papers. Springer encourages
authors to include their ORCIDs in their papers. In addition, upon
acceptance, the corresponding author of each paper, acting on behalf
of all of the authors of that paper, must complete and sign a
Consent-to-Publish form. The corresponding author signing the
copyright form should match the corresponding author marked on the
paper. Once the files have been sent to Springer, changes relating to
the authorship of the papers cannot be made.

Page numbers (and, if possible, line numbers) should appear on the
manuscript to help the reviewers in writing their report. So, for
LaTeX, we recommend that authors use:

\pagestyle{plain}
\usepackage{lineno}
\linenumbers

Papers should be submitted via EasyChair:
https://easychair.org/conferences/?conf=lopstr2023

BEST PAPER AWARD

Thanks to Springer's sponsorship, two best paper awards (one for each
submission category), with a 500 EUR prize, will be given at LOPSTR
2023. The program committee will select the winning papers based on
relevance, originality and technical quality but may also take
authorship into account (e.g. a student paper).

PROGRAM CHAIRS

Robert Glück, University of Copenhagen, Denmark
Bishoksan Kafle, IMDEA Software Institute, Spain

PUBLICITY CHAIR

Daniel Jurjo Rivas, IMDEA Software Institute, Spain

PROGRAM COMMITTEE MEMBERS

Slim Abdennadher, German International University, Egypt
José Júlio Alferes, Universidade Nova de Lisboa, Portugal
Roberto Amadini, University of Bologna, Italy
William Byrd, University of Alabama at Birmingham, USA
Michael Codish, Ben-Gurion University of the Negev, Israel
Gregory Duck, National University of Singapore, Singapore
Isabel García-Contreras, University of Waterloo, Canada
Ashutosh Gupta, IIT Bombay, India
Gopal Gupta, The University of Texas at Dallas, USA
Michael Hanus, University of Kiel, Germany
Temesghen Kahsai, Amazon, USA
Maja Hanne Kirkeby, Roskilde University, Denmark
Michael Leuschel, Heinrich Heine University Düsseldorf, Germany
Nai-Wei Lin, National Chung Cheng University, Taiwan
Fred Mesnard, University of Reunion, France
José F. Morales, IMDEA Software Institute, Spain
Carlos Olarte, Universitè Sorbonne Paris Nord, France
Alberto Pettorossi, Università di Roma Tor Vergata, Italy
Christoph Reichenbach, Lund University, Sweden
Peter Schachte, The University of Melbourne, Australia
Helge Spieker, Simula Research Laboratory, Norway
Theresa Swift, Universidade Nova de Lisboa, Portugal
Laura Titolo, National Institute of Aerospace, USA
Kazunori Ueda, Waseda University, Japan
Germán Vidal, Universitat Politècnica de València, Spain
Nisansala Yatapanage, Australian National University, Australia
Florian Zuleger, Vienna University of Technology, Austria

HISTORY

LOPSTR is a renowned symposium that has been held for more than 30
years.  The first meeting was held in Manchester, UK in
1991. Information about previous symposia:
http://lopstr.webs.upv.es/. You might have a look at the contents of
past LOPSTR symposia at DBLP
(https://dblp.uni-trier.de/db/conf/lopstr/index.html) and past LNCS
proceedings at Springer (https://link.springer.com/conference/lopstr).
    
Cheers, 

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] OPLSS 2023: Summer School Dates

[Stephanie W. <swe...@se...>]

We are pleased to announce the dates of the 21st annual Oregon Programming
Languages Summer School (OPLSS) to be held from June 26th to July 8th, 2023
at
the University of Oregon in Eugene. We are looking forward to getting
together
in person!

The theme of the summer school will be "types, semantics, and logic".
More details about the program and the registration process will be
available soon.

OPLSS 2023 Organization Team
Zena Ariola,  Stephanie Balzer, and Stephanie Weirich


[image: oplss.png]

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] ICFP 2023: Last Call for Papers

['ICFP P. v. MLton-u. <mlt...@ml...>]

             PACMPL Volume 7, Issue ICFP 2023
                           Call for Papers

           Accepted papers to be invited for presentation at
The 28th ACM SIGPLAN International Conference on Functional Programming
                            Seattle, USA
                     http://icfp23.sigplan.org/

### Important dates

(All dates are in 2023 at 11.59pm anywhere on earth.)

Submission deadline:   1 March 2023 (Wednesday)
                       (https://icfp23.hotcrp.com)
Author response:       1 May (Monday)--4 May (Thursday)
Round 1 notification:  18 May (Thursday)
Round 2 notification:  29 June (Thursday)
Camera-ready deadline: 20 July (Thursday)
Conference:            4 September (Monday)--9 September (Saturday)

### About PACMPL

Proceedings of the ACM on Programming Languages (PACMPL
<https://pacmpl.acm.org/>) is a Gold Open Access journal publishing
research on all aspects of programming languages, from design to
implementation and from mathematical formalisms to empirical
studies. Each issue of the journal is devoted to a particular subject
area within programming languages and will be announced through
publicised Calls for Papers, like this one.

### Scope

[PACMPL](https://pacmpl.acm.org/) issue ICFP 2023 seeks original
papers on the art and science of functional programming. Submissions
are invited on all topics from principles to practice, from
foundations to features, and from abstraction to application. The
scope includes all languages that encourage functional programming,
including both purely applicative and imperative languages, as well as
languages with objects, concurrency, or parallelism. Topics of
interest include (but are not limited to):

  * Language Design: concurrency, parallelism, and distribution;
    modularity; components and composition; metaprogramming; macros;
    pattern matching; type systems; type inference; dependent types;
    effect types; gradual types; refinement types; session types;
    interoperability; domain-specific languages; imperative
    programming; object-oriented programming; logic programming;
    probabilistic programming; reactive programming; generic
    programming; bidirectional programming.

  * Implementation: abstract machines; virtual machines;
    interpretation; compilation; compile-time and run-time
    optimisation; garbage collection and memory management; runtime
    systems; multi-threading; exploiting parallel hardware; interfaces
    to foreign functions, services, components, or low-level machine
    resources.

  * Software-Development Techniques: algorithms and data structures;
    design patterns; specification; verification; validation; proof
    assistants; debugging; testing; tracing; profiling; build systems;
    program synthesis.

  * Foundations: formal semantics; lambda calculus; program
    equivalence; rewriting; type theory; logic; category theory;
    computational effects; continuations; control; state; names and
    binding; program verification.

  * Analysis and Transformation: control flow; data flow; abstract
    interpretation; partial evaluation; program calculation.

  * Applications: symbolic computing; formal-methods tools; artificial
    intelligence; systems programming; distributed systems and web
    programming; hardware design; databases; scientific and numerical
    computing; graphical user interfaces; graphics and multimedia; GPU
    programming; scripting; system administration; security.

  * Education: teaching introductory programming; mathematical proof;
    algebra.

Submissions will be evaluated according to their relevance,
correctness, significance, originality, and clarity. Each submission
should explain its contributions in both general and technical terms,
clearly identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work. The technical
content should be accessible to a broad audience.

PACMPL issue ICFP 2023 also welcomes submissions in two separate
categories — Functional Pearls and Experience Reports — that must be
marked as such when submitted and that need not report original
research results. Detailed guidelines on both categories are given at
the end of this call.

Submissions from underrepresented groups are encouraged. Authors who
require financial support to attend the conference can apply for PAC
funding (http://www.sigplan.org/PAC/).

The General Chair and PC Chair may not submit papers. PC members
(other than the PC Chair) may submit papers. However, SIGPLAN
guidelines dictate that they be held to a higher standard: a PC paper
can be accepted if after the discussion it has at least one
strongly-supportive review and no detractors. Each PC member may be
listed as a coauthor on a maximum of three submissions.

Please contact the Programme Chair if you have questions or are
concerned about the appropriateness of a topic.

### Preparation of submissions

*Deadline*: The deadline for submissions is **Wednesday, March 1,
2023**, Anywhere on Earth
(<https://www.timeanddate.com/time/zones/aoe>). This deadline will be
strictly enforced.

*Formatting*: Submissions must be in PDF format, printable in black
and white on US Letter sized paper and interpretable by common PDF
tools. All submissions must adhere to the "ACM Small" template that is
available (in both LaTeX and Word formats) from
<https://www.acm.org/publications/authors/submissions>.

There is a limit of **25 pages for a full paper or Functional Pearl**
and **12 pages for an Experience Report**; in either case, the
bibliography and an optional clearly marked appendix will not be
counted against these limits. Submissions that exceed the page limits
or, for other reasons, do not meet the requirements for formatting,
will be summarily rejected.

See also PACMPL's Information and Guidelines for Authors at
<https://pacmpl.acm.org/authors.cfm>.

*Submission*: Submissions will be accepted at
 <https://icfp23.hotcrp.com/>

Improved versions of a paper may be submitted at any point before the
submission deadline using the same web interface.

*Author Response Period*: Authors will have a 72-hour period, starting
at 12pm UTC on *Monday, May 1, 2023*, to read reviews and respond to
them.

*Appendix and Supplementary Material*: Authors have the option to
include a clearly marked appendix and/or to attach supplementary
material to a submission, on the understanding that reviewers may
choose not to look at such an appendix or supplementary
material. Supplementary material may be uploaded as a separate PDF
document or tarball. Any supplementary material **must** be uploaded
**at submission time**, not by providing a URL in the paper that
points to an external repository.

Authors are free to upload both anonymised and non-anonymised
supplementary material. Anonymised supplementary material will be
visible to reviewers immediately; non-anonymised supplementary
material (which must be submitted separately) will be revealed to
reviewers only after they have submitted their review of the paper and
learned the identity of the author(s).

*Authorship Policies*: All submissions are expected to comply with the
ACM Policies for Authorship that are detailed at
<https://www.acm.org/publications/authors/information-for-authors>.

*Republication Policies*: Each submission must adhere to SIGPLAN's
republication policy, as explained on the web at
<http://www.sigplan.org/Resources/Policies/Republication>.

*ORCID*: ORCID provides a persistent digital identifier (an ORCID iD)
that you own and control, and that distinguishes you from every other
researcher: https://orcid.org/. ACM now require an ORCID iD for every
author of a paper, not just the corresponding author. So, the author
who is filling out the permission form should make sure they have the
ORCID iDs for all of their coauthors before filling out the form. Any
authors who do not yet have an ORCID iD can go to
https://orcid.org/register to have one assigned.

### Review Process

This section outlines the two-stage process with lightweight
double-blind reviewing that will be used to select papers for PACMPL
issue ICFP 2023.

**New this year**: ICFP 2023 will have an Associate Chair who will help
the PC Chair monitor reviews, solicit external expert reviews for
submissions when there is not enough expertise on the committee, and
facilitate reviewer discussions.

*PACMPL issue ICFP 2023 will employ a two-stage review process.* The
first stage in the review process will assess submitted papers using
the criteria stated above and will allow for feedback and input on
initial reviews through the author response period mentioned
previously. As a result of the review process, a set of papers will be
conditionally accepted and all other papers will be rejected. Authors
will be notified of these decisions on **May 18, 2023**.

Authors of conditionally accepted papers will be provided with
committee reviews along with a set of mandatory revisions. By June 15,
2023, the authors may provide a second submission. The second and
final reviewing phase assesses whether the mandatory revisions have
been adequately addressed by the authors and thereby determines the
final accept/reject status of the paper. The intent and expectation is
that the mandatory revisions can feasibly be addressed within three
weeks.

The second submission should clearly identify how the mandatory
revisions were addressed. To that end, the second submission must be
accompanied by a cover letter mapping each mandatory revision request
to specific parts of the paper. The cover letter will facilitate a
quick second review, allowing for confirmation of final acceptance
within two weeks. Conversely, the absence of a cover letter will be
grounds for the paper's rejection.

*PACMPL issue ICFP 2023 will employ a lightweight double-blind
 reviewing process.*

To facilitate this, submitted papers must adhere to two rules:

  1. **author names and institutions must be omitted**, and

  2. **references to authors' own related work should be in the third
     person** (e.g., not "We build on our previous work ..." but
     rather "We build on the work of ...").

The purpose of this process is to help the reviewers come to an
initial judgement about the paper without bias, not to make it
impossible for them to discover the authors if they were to
try. Nothing should be done in the name of anonymity that weakens the
submission or makes the job of reviewing the paper more difficult
(e.g., important background references should not be omitted or
anonymised). In addition, authors should feel free to disseminate
their ideas or draft versions of their papers as they normally
would. For instance, authors may post drafts of their papers on the
web or give talks on their research ideas.

### Information for Authors of Accepted Papers

  * As a condition of acceptance, final versions of all papers must
    adhere to the ACM Small format. The page limit for the final
    versions of papers will be increased by two pages to help authors
    respond to reviewer comments and mandatory revisions: **27 pages
    plus bibliography for a regular paper or Functional Pearl, 14
    pages plus bibliography for an Experience Report**.

  * Authors of accepted submissions will be required to agree to one
    of the three ACM licensing options, one of which is Creative
    Commons CC-BY publication; this is the option recommended by the
    PACMPL editorial board. A reasoned argument in favour of this
    option can be found in the article [Why
    CC-BY?](https://oaspa.org/why-cc-by/) published by OASPA, the Open
    Access Scholarly Publishers Association. The other options are
    copyright transfer to ACM or retaining copyright but granting ACM
    exclusive publication rights.

  * PACMPL is a Gold Open Access journal, and authors are encouraged
    to publish their work under a CC-BY license. Gold Open Access
    guarantees permanent free online access to the definitive version
    in the ACM Digital Library, and the recommended CC-BY option also
    allows anyone to copy and distribute the work with attribution.
    Gold Open Access has been made possible by generous funding
    through ACM SIGPLAN, which will cover all open access costs in the
    event authors cannot. Authors who can cover the costs may do so by
    paying an Article Processing Charge (APC). PACMPL, SIGPLAN, and
    ACM Headquarters are committed to exploring routes to making Gold
    Open Access publication both affordable and sustainable.

  * ACM Author-Izer is a unique service that enables ACM authors to
    generate and post links on either their home page or institutional
    repository for visitors to download the definitive version of
    their articles from the ACM Digital Library at no
    charge. Downloads through Author-Izer links are captured in
    official ACM statistics, improving the accuracy of usage and
    impact measurements. Consistently linking to the definitive
    version of an ACM article should reduce user confusion over
    article versioning. After an article has been published and
    assigned to the appropriate ACM Author Profile pages, authors
    should visit
    <http://www.acm.org/publications/acm-author-izer-service> to learn
    how to create links for free downloads from the ACM DL.

  * The official publication date is the date the papers are made
    available in the ACM Digital Library. This date may be up to *two
    weeks prior* to the first day of the conference. The official
    publication date affects the deadline for any patent filings
    related to published work.

  * Authors of each accepted submission are invited to attend and be
    available for the presentation of that paper at the
    conference. The schedule for presentations will be determined and
    shared with authors after the full program has been selected.

### Artifact Evaluation

Authors of papers that are conditionally accepted in the first phase
of the review process will be encouraged (but not required) to submit
supporting materials for Artifact Evaluation. These items will then be
reviewed by an Artifact Evaluation Committee, separate from the paper
Review Committee, whose task is to assess how the artifacts support
the work described in the associated paper. Papers that go through the
Artifact Evaluation process successfully will receive a seal of
approval printed on the papers themselves. Authors of accepted papers
will be encouraged to make the supporting materials publicly available
upon publication of the papers, for example, by including them as
"source materials" in the ACM Digital Library. An additional seal will
mark papers whose artifacts are made available, as outlined in the ACM
guidelines for artifact badging.

Participation in Artifact Evaluation is voluntary and will not
influence the final decision regarding paper acceptance.

### Special categories of papers

In addition to research papers, PACMPL issue ICFP solicits two kinds
of papers that do not require original research contributions:
Functional Pearls, which are full papers, and Experience Reports,
which are limited to half the length of a full paper. Authors
submitting such papers should consider the following guidelines.

#### Functional Pearls

A Functional Pearl is an elegant essay about something related to
functional programming. Examples include, but are not limited to:

  * a new and thought-provoking way of looking at an old idea

  * an instructive example of program calculation or proof

  * a nifty presentation of an old or new data structure

  * an interesting application of functional programming techniques

  * a novel use or exposition of functional programming in the
    classroom

While pearls often demonstrate an idea through the development of a
short program, there is no requirement or expectation that they do
so. Thus, they encompass the notions of theoretical and educational
pearls.

Functional Pearls are valued as highly and judged as rigorously as
ordinary papers, but using somewhat different criteria. In particular,
a pearl is not required to report original research, but, it should be
concise, instructive, and entertaining. A pearl is likely to be
rejected if its readers get bored, if the material gets too
complicated, if too much-specialised knowledge is needed, or if the
writing is inelegant. The key to writing a good pearl is polishing.

A submission that is intended to be treated as a pearl must be marked
as such on the submission web page and should contain the words
"Functional Pearl" somewhere in its title or subtitle. These steps
will alert reviewers to use the appropriate evaluation
criteria. Pearls will be combined with ordinary papers, however, for
the purpose of computing the conference's acceptance rate.

#### Experience Reports

The purpose of an Experience Report is to describe the experience of
using functional programming in practice, whether in industrial
application, tool development, programming education, or any other
area.

Possible topics for an Experience Report include, but are not limited to:

  * insights gained from real-world projects using functional
    programming

  * comparison of functional programming with conventional programming
    in the context of an industrial project or a university curriculum

  * project-management, business, or legal issues encountered when
    using functional programming in a real-world project

  * curricular issues encountered when using functional programming in
    education

  * real-world constraints that created special challenges for an
    implementation of a functional language or for functional
    programming in general

An Experience Report is distinguished from a normal PACMPL issue ICFP
paper by its title, by its length, and by the criteria used to
evaluate it.

  * Both in the papers and in any citations, the title of each
    accepted Experience Report must end with the words "(Experience
    Report)" in parentheses. The acceptance rate for Experience
    Reports will be computed and reported separately from the rate for
    ordinary papers.

  * Experience Report submissions can be at most 12 pages long,
    excluding bibliography.

  * Each accepted Experience Report will be presented at the
    conference, but depending on the number of Experience Reports and
    regular papers accepted, authors of Experience Reports may be
    asked to give shorter talks.

  * Because the purpose of Experience Reports is to enable our
    community to understand the application of functional programming,
    an acceptable Experience Report need not add to the body of
    knowledge of the functional-programming community by presenting
    novel results or conclusions. It is sufficient if the Report
    describes an illuminating experience with functional programming,
    or provide evidence for a clear thesis about the use of functional
    programming. The experience or thesis must be relevant to ICFP,
    but it need not be novel.

The review committee will accept or reject Experience Reports based on
whether they judge the paper to illuminate some aspect of the use of
functional programming. Anecdotal evidence will be acceptable provided
it is well-argued and the author explains what efforts were made to
gather as much evidence as possible. Typically, papers that show how
functional programming was used are more convincing than papers that
say only that functional programming was used. It can be
especially effective to present comparisons of the situations before
and after the experience described in the paper, but other kinds of
evidence would also make sense, depending on context. Experience drawn
from a single person's experience may be sufficient, but more weight
will be given to evidence drawn from the experience of groups of
people.

An Experience Report should be short and to the point. For an
industrial project, it should make a claim about how well functional
programming worked and why; for a pedagogy paper, it might make a
claim about the suitability of a particular teaching style or
educational exercise. Either way, it should produce evidence to
substantiate the claim. If functional programming worked in this case
in the same ways it has worked for others, the paper need only
summarise the results — the main part of the paper should discuss how
well it worked and in what context. Most readers will not want to know
all the details of the experience and its implementation, but the
paper should characterise it and its context well enough so that
readers can judge to what degree this experience is relevant to their
own circumstances. The paper should take care to highlight any unusual
aspects; specifics about the experience are more valuable than
generalities about functional programming.

If the paper not only describes experience but also presents new
technical results, or if the experience refutes cherished beliefs of
the functional-programming community, it may be better to submit it as
a full paper, which will be judged by the usual criteria of novelty,
originality, and relevance. The Program Chair will be happy to advise
on any concerns about which category to submit to.

### ICFP Organisers

General Chair:
  Nikhil Swamy (Microsoft Research, USA)
Programme Chair:
  Sam Lindley (The University of Edinburgh, Scotland)
Publicity Chair:
  Ilya Sergey (National University of Singapore, Singapore)

Accessibility Co-Chairs:
  Vadim Zaliva (University of Cambridge, UK)
  and Calvin Beck (University of Pennsylvania, USA)
Artifact Evaluation Chair:
  Jannis Limpberg (Vrije Universiteit Amsterdam, Netherlands)
Diversity Chair:
  Daan Leijen (Microsoft Research, USA)
Industrial Relations Co-Chairs:
  Atze Dijkstra (Standard Chartered Bank, England)
  and Mathieu Bosepflug (Tweag I/O, France)
Programming Contest Co-Organisers:
  Alperen Keles (University of Maryland, USA) and
  Aymeric Fromherz (Inria, France)
Student Research Competition Chair:
  Daniel Hillerström (The University of Edinburgh, Scotland)
Video Chair:
  Apoorv Ingle (Iowa, USA)
Workshops Co-Chairs:
  Arther Azevedo de Amorim (Boston University, USA)
  and Yannick Forster (Inria, France)

### PACMPL Volume 7, Issue ICFP 2023

Associate Editor: Sam Lindley (The University of Edinburgh, Scotland)

Review Committee:

  Aggelos Biboudis, Oracle, Switzerland
  Alan Jeffrey, Roblox, USA
  Amos Robinson, Unaffiliated, Australia
  Andreea Costea, National University of Singapore, Singapore
  Andrew Hirsch, University of Buffalo, USA
  Andy Gill, Cerebrus Systems, USA
  Armando Solar-Lezama, MIT, USA
  Arnaud Spiwack, Tweag, France
  Benjamin C. Pierce, University of Pennsylvania, USA
  Beta Ziliani, FAMAF, UNC and Manas.Tech, Argentina
  Chung-Kil Hur, Seoul National University, South Korea
  Delia Kesner, Université de Paris, France
  Dylan McDermott, Reykjavik University, Iceland
  Éric Tanter, University of Chile, Chile
  Gabriel Radanne, Inria, France
  Gerwin Klein, Proofcraft & UNSW Sydney, Australia
  Hannah Gommerstadt, Vasser College, USA
  James Chapman, Input Output, Scotland
  James McKinna, Heriot-Watt, Scotland
  Jan Midtgaard, Tarides, Denmark
  Jeremy Gibbons, University of Oxford, England
  Jonathan Brachthäuser, University of Tübingen, Germany
  Jonathan Sterling, Aarhus University, Denmark
  José Pedro Magalhães, Standard Chartered Bank, England
  Josh Berdine, Meta UK, England
  Kathrin Stark, Heriot-Watt, Scotland
  Laura Bocchi, Kent, England
  Lennart Augustsson, Epic Games, Sweden
  Liang-Ting Chen, Academia Sinica, Taiwan, Taiwan
  Lionel Parreaux, HKUST, Hong Kong
  Marcos Viera, Universidad de la República, Uruguay
  Matthew Flatt, University of Utah, USA
  Michael D. Adams, National University of Singapore, Singapore
  Michael Greenberg, Stevens Institute of Technology, USA
  Niki Vazou, IMDEA, Spain
  Oliver Bračevac, Purdue University, USA
  Patrik Jansson, CSE, Chalmers and UGOT, Sweden, Sweden
  Paul Downen, UMass Lowell, USA
  Peter Thiemann, University of Freiburg, Germany
  Sam Tobin-Hochstadt, Indiana University, USA
  Satnam Singh, Groq, USA
  Sean Moss, Oxford, England
  Sebastian Erdweg, JGU Mainz, Germany
  Shin-ya Katsumata, National Institute of Informatics, Japan
  Simon Gay, University of Glasgow, Scotland
  Sonia Marin, University of Birmingham, England
  Stephen Dolan, Jane Street, England
  Susmit Sarkar, University of St Andrews, Scotland
  Tahina Ramananandro, Microsoft, USA
  Takeshi Tsukada, Chiba University, Japan
  Talia Ringer, University of Illinois at Urbana-Champaign, USA
  Yukiyoshi Kameyama, University of Tsukuba, Japan
  Zhenjiang Hu, Peking University, China

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Influencing garbage collector for read-large-data then process style of program?

[Matthew F. <mat...@gm...>]

Peter,

I'm afraid that I don't believe that there is any easy fix for your
situation.  Unfortunately, all of the runtime/garbage-collector "knobs" can
only be set by `@MLton ... --` runtime options and cannot be set
dynamically by SML code.

You might be able to get by with `@MLton live-ratio 1.25` or similar; that
will set the reserve 1.25 times the live memory size, rather than 8 times.
But, depending on how you load your large data, this may slow down that
loading, because at the beginning of the program, you will fill the heap
with the loaded data, expand it just a little bit, and then immediately
fill with more loaded data.

The ideal solution would be to set the `live-ratio` to `1.25` after loading
your large data.  Or introduce a more complicated sizing policy that allows
one to "ignore" an object or size from the live data when computing the
additional space.  But, those would all require changes to the existing
runtime system.  It would be nice to have some kind of `val
MLton.GC.setControl: string * string -> bool` and `val MLton.GC.getControl:
string -> string option` for dynamically setting runtime options
(deliberately using `string`, rather than some enumerated type of runtime
controls, for extensibility).

Best,
-Matthew

On Mon, Feb 6, 2023 at 3:14 PM Peter Lammich <pla...@gm...> wrote:

> Hi List,
>
> I have a program that reads a large chunk of data (a few GB), and then
> processes this data (without changing it).
>
> The memory footprint of this program seems excessive, in particular for
> machines with a lot of RAM available. Given a specific run, I can
> usually curb the used heap (@MLton fixed-heap) without negatively
> influencing the runtime, but I'm looking for a general solution, that
> does not involve guessing a good maxheap value from the input parameters
> before starting the program.
>
> I understand that the garbage collector, as long as the machine has some
> memory available, reserves 8 times the live memory size of the
> application. In my case, this is 8 times the size of the big chunk of
> loaded (read-only) data + 8 times the few kB of other objects needed
> during processing. Obviously not a very good choice.
>
> Question: what can I do to convince the garbage collector to allocate
> memory more reasonably, e.g., to not try to allocate a multiple of the
> big data chunk size once it has finished loading? I'm happy to add some
> code to my program, e.g., to signal that the data has finished loading.
>
> Thanks for any help in advance,
>
>    Peter Lammich
>
>
>
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlt...@ml....
>
>
>
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user
>

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] Influencing garbage collector for read-large-data then process style of program?

[Peter L. <pla...@gm...>]

Hi List,

I have a program that reads a large chunk of data (a few GB), and then 
processes this data (without changing it).

The memory footprint of this program seems excessive, in particular for 
machines with a lot of RAM available. Given a specific run, I can 
usually curb the used heap (@MLton fixed-heap) without negatively 
influencing the runtime, but I'm looking for a general solution, that 
does not involve guessing a good maxheap value from the input parameters 
before starting the program.

I understand that the garbage collector, as long as the machine has some 
memory available, reserves 8 times the live memory size of the 
application. In my case, this is 8 times the size of the big chunk of 
loaded (read-only) data + 8 times the few kB of other objects needed 
during processing. Obviously not a very good choice.

Question: what can I do to convince the garbage collector to allocate 
memory more reasonably, e.g., to not try to allocate a multiple of the 
big data chunk size once it has finished loading? I'm happy to add some 
code to my program, e.g., to signal that the data has finished loading.

Thanks for any help in advance,

   Peter Lammich




-- 
To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....