2023-07-12

[Caml-list] [TFP 2024 Call for Papers] 25th International Symposium on Trends in Functional Programming

# 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
Posted by at No comments:

2023-06-08

[Caml-list] APLAS 2023: Final Call for Papers

======================================================================
CALL FOR PAPERS

21st Asian Symposium on Programming Languages and Systems (APLAS 2023)
Taipei, Taiwan, Sun 26 – Wed 29 November 2023

https://conf.researchr.org/home/aplas-2023
======================================================================


IMPORTANT DATES
-------------------------------------
Submission deadline: Thu 15 Jun 2023 AoE
Author response: Mon 31 Jul 12:00 - Wed 2 Aug 12:00 2023 AoE
Author notification: Mon 14 Aug 2023 AoE
Final paper deadline: Wed 6 Sep 2023 AoE
Conference: Sun 26 – Wed 29 Nov 2023


SCOPE
-------------------------------------
We solicit submissions in the form of regular research papers
describing original scientific research results, including system
development and case studies. Among others, solicited topics include:

- ** programming paradigms and styles ** :
functional programming; object-oriented programming; probabilistic
programming; logic
programming; constraint programming; extensible programming
languages; programming languages for systems code; novel programming
paradigms;

- ** methods and tools to specify and reason about programs and
languages ** :

programming techniques; meta-programming; domain-specific
languages; proof assistants; type systems; dependent types; program
logics, static and dynamic program analysis; language-based
security; model checking; testing;

- ** programming language foundations ** :

formal semantics; type theory; logical foundations; category
theory; automata; effects; monads and comonads; recursion and
corecursion; continuations and effect handlers; program
verification; memory models; abstract interpretation;

- ** methods and tools for implementation ** :

compilers; program transformations; rewriting systems;
partial evaluation; virtual machines; refactoring; intermediate
languages; run-time environments; garbage collection and memory
management; tracing; profiling; build systems; program synthesis;

- ** concurrency and distribution ** :

process algebras; concurrency theory; session types; parallel
programming; service-oriented computing; distributed and mobile
computing; actor-based languages; verification and testing of
concurrent and distributed systems;

- ** applications and emerging topics ** :

programming languages and PL methods in education, security,
privacy, database systems, computational biology, signal
processing, graphics, human-computer interaction, computer-aided
design, artificial intelligence and machine learning; case
studies in program analysis and verification.


GENERAL INFORMATION
-------------------------------------
Submissions should not exceed 17 pages, excluding bibliography in the
Springer LNCS format. LaTeX template is available at:

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

The accepted papers will be allowed to use one extra page for the
content to accommodate feedback from the reviews in the final paper
versions.

Papers should be submitted via HotCRP:

https://aplas2023.hotcrp.com/

The review process of APLAS 2023 is double-anonymous, with a rebuttal
phase. In your submission, please, omit your names and institutions;
refer to your prior work in the third person, just as you refer to
prior work by others; do not include acknowledgments that might
identify you.

Additional material intended for reviewers but not for publication in
the final version - for example, details of proofs - may be placed in
a clearly marked appendix that is not included in the page limit.
Reviewers are at liberty to ignore appendices and papers must be
understandable without them.

Submitted papers must be unpublished and not submitted for publication
elsewhere. Papers must be written in English. The proceedings will be
published as a volume in Springer's LNCS series. Accepted papers must
be presented at the conference.


POSTERS and STUDENT RESEARCH COMPETITION
----------------------------------------

APLAS 2023 includes a Posters session and a Student Research
Competition. For more details, please see the website.

https://conf.researchr.org/track/aplas-2023/posters-and-src


DISTINGUISHED PAPERS AWARDS
-------------------------------------

Around 10% of the accepted papers of APLAS 2023 will be designated as
Distinguished Papers, which highlights papers that the Program
Committee recommends due to their excellent quality. The awards will
be announced on this website, and printed certificates will be issued
to the authors in the conference.


ORGANIZERS
-------------------------------------

General Chair:

Shin-Cheng Mu, Academia Sinica, Taiwan

Program Chair:

Chung-Kil Hur, Seoul National University, Korea

Publicity Chair:

Ryosuke Sato, University of Tokyo, Japan

Program Committee:

Soham Chakraborty, TU Delft, Netherlands
Yu-Fang Chen, Academia Sinica, Taiwan
Ronghui Gu, Columbia University, USA
Ichiro Hasuo, National Institute of Informatics, Japan
Ralf Jung, ETH Zurich, Switzerland
Ohad Kammar, University of Edinburgh, UK
Jeehoon Kang, KAIST, Korea
Jieung Kim, Inha University, Korea
Robbert Krebbers, Radboud University Nijmegen, Netherlands
Ori Lahav, Tel Aviv University, Israel
Doug Lea, State University of New York at Oswego, USA
Woosuk Lee, Hanyang University, Korea
Hongjin Liang, Nanjing University, China
Nuno P. Lopes, University of Lisbon, Portugal
Chandrakana Nandi, Certora and UW, USA
Liam O'Connor, The University of Edinburgh, UK
Bruno C. d. S. Oliveira, The University of Hong Kong, Hong Kong
Jihyeok Park, Korea University, Korea
Clément Pit-Claudel, EPFL, Switzerland
Matthieu Sozeau, Inria, France
Kohei Suenaga, Kyoto University, Japan
Tarmo Uustalu, Reykjavik University, Iceland
John Wickerson, Imperial College London, UK
Danfeng Zhang, Penn State University, USA
Posted by at No comments:

2023-06-02

[Caml-list] TyDe 2023 - Second Call for Papers and Deadline Extension

TL;DR: The submission deadline for TyDe 2023 has been extended
to Thursday June 8.

--------------------------------------------------------------------------------
 CALL FOR PAPERS

 8th Workshop on Type-Driven Development (TyDe 2023)
 Co-Located with ICFP 2023 (Seattle, Washington, USA)

 https://icfp23.sigplan.org/home/tyde-2023
--------------------------------------------------------------------------------

# Goals of the Workshop

The Workshop on Type-Driven Development (TyDe) aims to show how
static type information may be used effectively in the development
of computer programs. Co-located with ICFP, this workshop brings
together leading researchers and practitioners who are using or
exploring types as a means of program development.

We welcome all contributions, both theoretical and practical, on a
range of topics including:

- dependently typed programming;
- generic programming;
- design and implementation of programming languages, exploiting
  types in novel ways;
- exploiting typed data, data dependent data, or type providers;
- static and dynamic analyses of typed programs;
- tools, IDEs, or testing tools exploiting type information;
- pearls, being elegant, instructive examples of types used in the
  derivation, calculation, or construction of programs.

# Proceedings and Copyright

We will have formal proceedings, published by the ACM. Accepted
papers will be included in the ACM Digital Library. Authors must
grant ACM publication rights upon acceptance, but may retain
copyright if they wish. Authors are encouraged to publish auxiliary
material with their paper (source code, test data, and so forth).
The proceedings will be freely available for download from the ACM
Digital Library from one week before the start of the conference
until two weeks after the conference.

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.

# Submission Details

Submissions should fall into one of two categories:

- regular research papers (12 pages);
- extended abstracts (3 pages).

The bibliography will not be counted against the page limits for
either category.

Regular research papers are expected to present novel and interesting
research results, and will be included in the formal proceedings.
Extended abstracts should report work in progress that the authors
would like to present at the workshop. Extended abstracts will be
distributed to workshop attendees but will not be published in the
formal proceedings.

We welcome submissions from PC members (with the exception of the two
co-chairs), but these submissions will be held to a higher standard.

Submission is handled through HotCRP:

  https://tyde23.hotcrp.com

All submissions should be in portable document format (PDF) and
formatted using the ACM SIGPLAN style guidelines:

  https://www.sigplan.org/Resources/Author/

Note that submissions should use the new 'acmart' format and the
two-column 'sigplan' subformat (not to be confused with the
one-column 'acmsmall' subformat).

Extended abstracts must be submitted with the label 'Extended
Abstract' clearly in the title.

# Participant Support

Student attendees with accepted papers can apply for a SIGPLAN PAC
grant to help cover participation-related expenses. PAC also offers
other support, such as for child-care expenses during the meeting or
for accommodations for members with physical disabilities. For
details on the PAC program, see its web page:

  https://www.sigplan.org/PAC/

# Important Dates

- Submission Deadline: Thursday June 8, 2023 (extended)
- Author Notification: Thursday June 29, 2023
- Camera-Ready Deadline: Thursday July 13, 2023
- Workshop: Monday September 4, 2023

# Workshop Organization

Organizing Committee:
- Youyou Cong (Tokyo Institute of Technology, Japan)
- Pierre-Evariste Dagand (IRIF / CNRS, France)

Program Committee:
- Reynald Affeldt (AIST, Japan)
- Sandra Alves (DCC-FCUP, Portugual)
- Stephen Chang (UMass Boston, United States)
- Magnus Madsen (Aarhus University, Denmark)
- Victor Cacciari Miraldo (Channable, Netherlands)
- Jonathan Protzenko (Microsoft Research, United States)
- Marianna Rapoport (Amazon Web Services, Canada)
- Christine Rizkallah (University of Melbourne, Australia)
- Filip Sieczkowski (Heriot-Watt University, United Kingdom)
- Aaron Stump (The University of Iowa, United States)
- Peter Thiemann (University of Freiburg, Germany)
- Ningning Xie (Google Brain / University of Toronto, Canada)
Posted by at No comments:

[Caml-list] [Deadline Extension] ML'23: Higher-order, Typed, Inferred, Strict: ACM SIGPLAN ML Family Workshop

# Deadline extended till June 8 (Thu), AOE
# Talk proposals (1-3 PDF pages) are solicited.
# Remote participation and presentation are possible.
# 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.
# Please consider submission!

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 8, 2023 [EXTENDED] **
* Notification of acceptance: ** Thursday July 6, 2023 **
* Workshop: ** Friday September 8, 2023 **

Submission website: https://ml2023.hotcrp.com/

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 Rennes, France
Matija Pretnar University of Ljubljana, Slovenia
Andreas Rossberg Germany
Gabriel Scherer Inria Saclay, France
Posted by at No comments:

2023-05-30

[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

OCaml Weekly News

Previous Week Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of May 23 to 30, 2023.

ML’23: ACM SIGPLAN ML Family Workshop — Call for presentations

Archive: https://discuss.ocaml.org/t/ml23-acm-sigplan-ml-family-workshop-call-for-presentations/12224/1

Guillaume Munch-Maccagnoni announced

We are happy to invite submissions to the ML Family Workshop 2023:

Higher-order, Typed, Inferred, Strict: ACM SIGPLAN ML Family Workshop

Co-located with ICFP

Date: September 8, 2023 (Friday)

Location: Seattle, WA, USA (day after main ICFP)

Call for presentations

ML (originally, "Meta Language") is a family of programming languages that includes dialects known as Standard ML, OCaml, and F#, among others. The development of these languages has inspired a large amount of computer science research, both practical and theoretical.

The 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 be an 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.

See the full call for presentations for submission instructions.

  • 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 Rennes, France
  • Matija Pretnar, University of Ljubljana, Slovenia
  • Andreas Rossberg, Germany
  • Gabriel Scherer, Inria Saclay, France

OCaml Workshop 2023 – presentation deadline on June 1st, online attendance option

Archive: https://discuss.ocaml.org/t/ocaml-workshop-2023-presentation-deadline-on-june-1st-online-attendance-option/12226/1

gasche announced

The OCaml Workshop is happening every year, co-located with the ICFP conference (the main academic conference on functional programming). This year the meeting will happen in Seattle on Saturday September 9th. It should be hybrid: it will be possible to attend and even give talks remotely.

To get a sense of the OCaml Workshop style, topics and content, ocaml.org has a page about previous editions, with the list of talks and links to the descriptions and talk recordings when available: OCaml Workshops.

The deadline for submitting a talk proposal is June 1st, coming soon. Please consider submitting a proposal to present your OCaml work at the workshop!

A major change compared to previous editions of the workshop is that online attendance should be free. (The cost is decided by the ICFP organizers, and it is still possible that this would change before the workshop.) Everyone is of course welcome to attend remotely, anywhere on earth. We are very excited that this could be the most accessible OCaml workshop, reaching the broadest possible audience.

A Roadmap for the OCaml Platform - Seeking Your Feedback

Archive: https://discuss.ocaml.org/t/a-roadmap-for-the-ocaml-platform-seeking-your-feedback/12238/1

Thibaut Mattio announced, spawning a big thread

Three years ago, @avsm and the OCaml Platform team presented a roadmap for the OCaml Platform. The vision we had of the Platform in 2020 was one of a seamless editor integration, where users could open their editors and instantly be productive with OCaml.

While there’s still a long road ahead to achieve this vision, we’ve made a lot of progress. The tooling landscape and developer experience with OCaml have changed quite a lot in the past 3 years and we’ve made significant progress on all the tools of the Platform:

In the meantime, things have also changed for the broader OCaml ecosystem. OCaml 5 was released with support for shared memory parallelism and effect handlers; and we saw a new version of OCaml.org going live with a centralised package documentation, a job board, an interactive playground, and more.

Following the three priorities we adopted in 2022, we now want to intensify our efforts on prototyping new workflows for OCaml development. It is time to reflect back on everything we’ve done and lay down a roadmap for the next three years.

In the past few months, we’ve been working on establishing a vision for the future of the OCaml Platform. We reviewed as much community feedback as possible, organised discussions with the maintainers of the Platform tools, met with industrial users of OCaml to understand their needs and pain points, and we collectively thought of what the ideal developer experience with OCaml ought to be.

We want the OCaml Platform to be driven by the community. So today, I’m excited to share the first parts of the roadmap to start collecting feedback and iterating on them.

You can see the work-in-progress roadmap on GitHub. The repository currently contains two documents:

  • Design Principles: The principles that will guide the desired OCaml developer experience.
  • Users: The different user personas within the OCaml ecosystem serve as a guide for the roadmap, ensuring that it addresses the unique requirements of each archetype.

Feel free to read through them and share your thoughts, in particular:

  • Do you agree with the Principles of the Platform?
  • Do you see yourself represented in the Users?

Once we’ve iterated on the feedback and are ready to adopt these high-level guidelines, we’ll refine the developer workflows we aim to build in the coming years. Similarly to the first sections, we’ll post them on Discuss to discuss them with the community and ultimately adopt a first version of the Platform roadmap.

I’m looking forward to everyone’s feedback and building this roadmap together!

new release: tiny_httpd 0.13

Archive: https://discuss.ocaml.org/t/ann-new-release-tiny-httpd-0-13/12268/1

Simon Cruanes announced

I’m happy to announce that tiny_httpd got a new [release]( https://github.com/c-cube/tiny_httpd/releases/tag/v0.13 ).

Tiny_httpd is a small and reasonably simple HTTP 1.1 server that relies on threads (or a thread pool) rather than async/cooperative multitasking. It’s perhaps a bit reactionary[^1] but it can be quite useful to add an embedded web UI/web server to existing code (think adding a httpd to ocamlopt or Coq or BAP or…). However, tiny_httpd does come with a basic type-safe router, HTML combinators, SSE endpoints, a packing tool for assets, streaming interface (with chunking) to read/write long bodies in constant memory, and an optional deflate middleware based on camlzip.

[^1]: 👴📢💪️☁️

Old CWN

If you happen to miss a CWN, you can send me a message and I’ll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe online.

Posted by at No comments:

2023-05-12

[Caml-list] APLAS 2023: Second Call for Papers

UPDATE: Distinguished Papers Awards!

======================================================================
CALL FOR PAPERS

21st Asian Symposium on Programming Languages and Systems (APLAS 2023)
Taipei, Taiwan, Sun 26 – Wed 29 November 2023

https://conf.researchr.org/home/aplas-2023
======================================================================


IMPORTANT DATES
-------------------------------------
Submission deadline: Thu 15 Jun 2023 AoE
Author response: Mon 31 Jul 12:00 - Wed 2 Aug 12:00 2023 AoE
Author notification: Mon 14 Aug 2023 AoE
Final paper deadline: Wed 6 Sep 2023 AoE
Conference: Sun 26 – Wed 29 Nov 2023


SCOPE
-------------------------------------
We solicit submissions in the form of regular research papers
describing original scientific research results, including system
development and case studies. Among others, solicited topics include:

- ** programming paradigms and styles ** :
functional programming; object-oriented programming; probabilistic
programming; logic
programming; constraint programming; extensible programming
languages; programming languages for systems code; novel programming
paradigms;

- ** methods and tools to specify and reason about programs and
languages ** :

programming techniques; meta-programming; domain-specific
languages; proof assistants; type systems; dependent types; program
logics, static and dynamic program analysis; language-based
security; model checking; testing;

- ** programming language foundations ** :

formal semantics; type theory; logical foundations; category
theory; automata; effects; monads and comonads; recursion and
corecursion; continuations and effect handlers; program
verification; memory models; abstract interpretation;

- ** methods and tools for implementation ** :

compilers; program transformations; rewriting systems;
partial evaluation; virtual machines; refactoring; intermediate
languages; run-time environments; garbage collection and memory
management; tracing; profiling; build systems; program synthesis;

- ** concurrency and distribution ** :

process algebras; concurrency theory; session types; parallel
programming; service-oriented computing; distributed and mobile
computing; actor-based languages; verification and testing of
concurrent and distributed systems;

- ** applications and emerging topics ** :

programming languages and PL methods in education, security,
privacy, database systems, computational biology, signal
processing, graphics, human-computer interaction, computer-aided
design, artificial intelligence and machine learning; case
studies in program analysis and verification.


GENERAL INFORMATION
-------------------------------------
Submissions should not exceed 17 pages, excluding bibliography in the
Springer LNCS format. LaTeX template is available at:

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

The accepted papers will be allowed to use one extra page for the
content to accommodate feedback from the reviews in the final paper
versions.

Papers should be submitted via HotCRP:

https://aplas2023.hotcrp.com/

The review process of APLAS 2023 is double-anonymous, with a rebuttal
phase. In your submission, please, omit your names and institutions;
refer to your prior work in the third person, just as you refer to
prior work by others; do not include acknowledgments that might
identify you.

Additional material intended for reviewers but not for publication in
the final version - for example, details of proofs - may be placed in
a clearly marked appendix that is not included in the page limit.
Reviewers are at liberty to ignore appendices and papers must be
understandable without them.

Submitted papers must be unpublished and not submitted for publication
elsewhere. Papers must be written in English. The proceedings will be
published as a volume in Springer's LNCS series. Accepted papers must
be presented at the conference.


POSTERS and STUDENT RESEARCH COMPETITION
----------------------------------------

APLAS 2023 includes a Posters session and a Student Research
Competition. For more details, please see the website.

https://conf.researchr.org/track/aplas-2023/posters-and-src


DISTINGUISHED PAPERS AWARDS
-------------------------------------

Around 10% of the accepted papers of APLAS 2023 will be designated as
Distinguished Papers, which highlights papers that the Program
Committee recommends due to their excellent quality. The awards will
be announced on this website, and printed certificates will be issued
to the authors in the conference.


ORGANIZERS
-------------------------------------

General Chair:

Shin-Cheng Mu, Academia Sinica, Taiwan

Program Chair:

Chung-Kil Hur, Seoul National University, Korea

Publicity Chair:

Ryosuke Sato, University of Tokyo, Japan

Program Committee:

Soham Chakraborty, TU Delft, Netherlands
Yu-Fang Chen, Academia Sinica, Taiwan
Ronghui Gu, Columbia University, USA
Ichiro Hasuo, National Institute of Informatics, Japan
Ralf Jung, ETH Zurich, Switzerland
Ohad Kammar, University of Edinburgh, UK
Jeehoon Kang, KAIST, Korea
Jieung Kim, Inha University, Korea
Robbert Krebbers, Radboud University Nijmegen, Netherlands
Ori Lahav, Tel Aviv University, Israel
Doug Lea, State University of New York at Oswego, USA
Woosuk Lee, Hanyang University, Korea
Hongjin Liang, Nanjing University, China
Nuno P. Lopes, University of Lisbon, Portugal
Chandrakana Nandi, Certora and UW, USA
Liam O'Connor, The University of Edinburgh, UK
Bruno C. d. S. Oliveira, The University of Hong Kong, Hong Kong
Jihyeok Park, Korea University, Korea
Clément Pit-Claudel, EPFL, Switzerland
Matthieu Sozeau, Inria, France
Kohei Suenaga, Kyoto University, Japan
Tarmo Uustalu, Reykjavik University, Iceland
John Wickerson, Imperial College London, UK
Danfeng Zhang, Penn State University, USA
Posted by at No comments:

2023-05-09

[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

OCaml Weekly News

Previous Week Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of May 02 to 09, 2023.

Overview of libraries for showing OCaml values

Archive: https://discuss.ocaml.org/t/overview-of-libraries-for-showing-ocaml-values/12076/1

Anton Bachin said

In light of the recent thread on, among other things, showing OCaml values, and because of Dream’s long-standing need for this to exist in OCaml, I’ve done, as suggested, a comparison of the available libraries. They seem to fall into three categories.

  1. Libraries that walk the runtime representation of values and dump it.

    These provide a 'a -> string functions that can immediately print any value, and are the easiest to use. They are what I need in Dream – something that a normal person can use for debugging without any boilerplate. The accuracy of these libraries is limited because the type information preserved in the runtime is very bare.

    These are:

    1. reason-native’s Console.log.
    2. Dum
    3. Inspect

    There is also Memgraph, but this appears to only output DOT graphs, so I didn’t look into it in detail.

    Since I am interested in these for my purposes, I wrote a tester that compares their outputs, and uploaded it into a gist. See the outputs for Console.log, Dum, Inspect. They are all variants of each other. Each has its own quirks and bugs, but they all look roughly like this: 

          > Console.log "abc"      "abc"      > Console.log 42      42      > Console.log {a = "abc"; b = 42}      {"abc"; 42}

    Interestingly (but predictably), for extensible variants like exn, these dumpers are able to print the string representation of variant constructors even with OCaml’s current runtime.

  2. Libraries, such as ppx_deriving, that have a PPX generate, or the user manually provide, information about types – that is, provide helper values that describe types, and then ask the user to provide that information to walk values and dump them.

    These are unsuitable for my goals. All of these require the user to pass in the type information to the printing function at each call site, because in the absence of modular implicits or type classes, the compiler cannot automatically associate the type information with the values. They provide, roughly, ('a -> string) -> 'a -> string functions. The user has to provide the 'a -> string for each 'a each time they would like to print an 'a.

    If 'a is a "container" type, the required function is a higher-order function that needs additional function(s) for the element types. This is not ergonomic, as each call site where one would like to show a value needs boilerplate. Even if the 'a -> string is precomposed, it requires the user to remember what it is called, pick the right one, and is not resistant to various refactorings such as wrapping in option. But such libraries are accurate, because the type information provided in the boilerplate can be precise.

    These are:

    1. ppx_deriving’s [@@deriving show].
    2. refl, a ppx_deriving-like.
    3. lrt, another ppx_deriving-like.
    4. tpf, again a ppx_deriving-like.
    5. typerep, probably a ppx_deriving-like with ppx_typerep_conv.
    6. repr, which appears to have the user build the type representation manually from combinators and then also pass it where need it.
    7. data-encoding, also fully manual.
    8. cmon, fully manual.
    9. dyn in Dune. Appears to also be fully manual.

    I didn’t try these out in detail because they are all unsuitable as Console.log-alikes for inspecting OCaml values without excessive boilerplate. As can be seen from their documentation, they all require boilerplate in the form of functions/witnesses/calling the right function, depending on the type, at the place where you’d like to show a value. The last four also require the user to manually build up the type representation using combinators. 

        M.show_myfpclass FP_normal       (* ppx_deriving: know the function. *)        Refl.show [%refl: (string * int) list] [] ["a", 1; "b", 2];;                                       (* refl: describe the type. *)      Print.show ~t:nat_t (S (S (S Z)))                                       (* lrt: provide the type info. *)      (* The docs for tpf are too obscure, but it's the same kind of library. *)        Fmt.str "%a\n" (pp t) { foo = None; bar = [ "foo" ] }                                       (* repr: build & provide the type info. *)

    etc. These kinds of approaches are probably also present in other libraries that do e.g. JSON encoding.

  3. Libraries that use a PPX at the call site to provide what looks like an 'a -> string function as in (1), but try to infer the type of the value being shown and derive its printer as in (2).

    These don’t seem to handle separate compilation well, as could be expected, and generally appear fragile.

    These are:

    1. Genprint
    2. OCaml@p

In my opinion, for the needs I see, the best approach would be runtime printing as in (1) with runtime type information that is accessible through pointers or indices stored in OCaml blocks. I wonder if this is what the LexiFi fork does. @nojb?

For those interested, we did the main part of the comparison on stream.

Nicolas Ojeda Bar replied

I wonder if this is what the LexiFi fork does. @nojb?

Not exactly.

We don’t attach type information to values directly, as we don’t want to modify the runtime model of OCaml (also, this would only work with heap-allocated values, which would all become larger).

What we do instead is that when a function has a labeled, non-optional argument of type 'a ttype (here 'a ttype is the “type of types” with constructors corresponding to each kind of type in OCaml) and the argument is not passed explicitly, then the compiler synthetizes it at each callsite.

Concretely, if we define a function of the form 

let show ~(t: 'a ttype) (x: 'a) : string =    match t with    | Int -> string_of_int x    | String -> x    | ...

And we call it with show 42, the compiler inserts ~t:Int as first argument. For efficiency, type witnesses (the values of type 'a ttype) are actually computed at compilation-time whenever possible.

Makes sense?

Later on, Nicolas Ojeda Bar said

I see there is a lot of enthusiasm for adding some form of type reflection to OCaml; that’s great! It is true that at LexiFi we have a tried-and-tested system in use for a long time. Let me try to give some perspective about it and answer some of the questions that came up:

  • The LexiFi patch actually consists of two parts: 1) the representation of types as an OCaml datatype; 2) a patch to the typechecker/middle end to have the compiler automatically generate type witnesses (as sketched above).
  • It is important to note that 1) is to an extent independent of 2); it comes down to giving a suitable definition of the “type of types”. I understand from past discussion that proposals in this direction would be welcome by the OCaml dev team. Accordingly, one should concentrate for the most part in 1) to make progress.
  • For historical reasons the LexiFi version of 1) (ie the type representation, see here and here) has a number of quirks. Furthermore, it makes design choices that may not be the best ones in general. For example, it only represents closed types: no type constructors or type variables can be represented, and so in particular neither can exotic types such as GADTs, first-class modules, extensible types, polymorphic variants, etc.
  • The main challenge in devising a suitable representation of types is deciding how to handle abstract types (see the paper and the slides I linked to in the other thread). At LexiFi abstract types are represented via “global names” (ie we identify an abstract type M.t by its name "M.t"). This works reasonably well in practice, but is not a good solution in general (the notion of “name” for an abstract type is not well-defined). I suspect the answer may be something of a research problem…
  • LexiFi did discuss upstreaming a version of its fork long time ago (~2011), but I suspect it wasn’t done mainly because of the theoretical shortcomings of the current implementation (eg handling of abstract types).
  • Accordingly, the LexiFi fork is not open-source: we don’t have the manpower to support it as an open-source project, we don’t want to release a version of this technology which has known limitations that make it easy to shot yourself in the foot if you don’t know what you are doing, and finally there are some commercial considerations to take into account (but my impression is that if this technology was polished enough that it could be accepted upstream, LexiFi would be happy to do so).
  • Personally, from a distance, https://github.com/thierry-martinez/refl looks rather interesting, but its type representation is quite complex and is not clear it can be made suitable for “practical” use.

I hope this answers some of the questions!

kcas and kcas_data 0.3.0: Software Transactional Memory

Archive: https://discuss.ocaml.org/t/ann-kcas-and-kcas-data-0-3-0-software-transactional-memory/12085/1

Vesa Karvonen announced

I’m happy to announce that, as of version 0.3.0, kcas can be considered to be a software transactional memory (STM) implementation based on lock-free multi-word compare-and-set (MCAS).

The main feature added in 0.3.0 is the ability to block — in a scheduler friendly manner — awaiting for changes to shared memory locations.

Let’s explore this by writing a short example with the help of MDX. (Yes, I’m actually testing this announcement.)

First we’ll require and open the kcas_data library: 

# #require "kcas_data"  # open Kcas_data

kcas_data gives us a number of domain safe and composable data structures and communication and synchronization primitives, such as a Queue and a Promise, for concurrent programming.

Let’s then create a message queue: 

# let greeter_queue = Queue.create ()  val greeter_queue : '_weak1 Kcas_data.Queue.t = <abstr>

And spawn a “greeter” domain that responds to messages with a greeting: 

# let greeter_domain = Domain.spawn @@ fun () ->      let rec loop () =        match Queue.take_blocking greeter_queue with        | `Close -> ()        | `Greet (target, resolver) ->          Promise.resolve resolver (Printf.sprintf "Hello, %s!" target);          loop ()      in      loop ()  val greeter_domain : unit Domain.t = <abstr>

Let’s also create a helper function, greet, to interact with the greeter: 

# let greet target =      let promise, resolver = Promise.create () in      Queue.add (`Greet (target, resolver)) greeter_queue;      Promise.await promise  val greet : string -> string = <fun>

Now we can call the greeter, which is running in another domain, as if it was a regular function. So, here is to you: 

# greet "fellow concurrent programmer"  - : string = "Hello, fellow concurrent programmer!"

And everyone else: 

# greet "the rest of the world"  - : string = "Hello, the rest of the world!"

Let’s not forget to clean up: 

# Queue.add `Close greeter_queue  - : unit = ()  # Domain.join greeter_domain  - : unit = ()

The blocking mechanism in kcas does not only work with plain domains and systhreads. It can also work across schedulers such as Eio and Domainslib, which both recently merged support for it and should soon have the necessary support out-of-the-box.

Finally, one might ask what is the cost of all this?

It turns out that after some careful optimizations, kcas performs pretty much as well as it used to. As a random data point, at the time of writing this, the Queue provided by the latest version of kcas_data can actually be faster than the Michael-Scott queue implementation from the latest version of lockfree: 

  Kcas_data.Queue : mean = 0.005985, sd = 0.000001 tp=50121937.812194  Lockfree.MSQueue: mean = 0.013976, sd = 0.000001 tp=21465000.358236

Don’t be fooled, however. It is clear that the composability of kcas adds overhead — probably something generally between 1x to 4x in time and space — compared to non-composable lock-free data structures using plain ~Atomic~s and it has already been demonstrated that a much faster version of the Michael-Scott queue could be implemented.

Nevertheless, the take home message is that STM could very well be fast enough for your application. The extra nanoseconds are probably not going to be the main bottlenecks in most concurrent programs.

Sid Kshatriya asked and Vesa Karvonen replied

Thanks for the readable example! Also very interesting to read blocking transactions portion especially of https://github.com/ocaml-multicore/kcas/#blocking-transactions !

Can you explain how this is integrated with Eio briefly – I know you have added a link but the discussion there is quite detailed…

It is pretty simple.

DLA (domain-local-await) basically stores, in the DLS, a domain (or systhread) specific function that implements the blocking mechanism. Inside a scheduler like Eio (and Domainslib and pretty much any imaginable scheduler) there is a loop (running in each domain managed by the scheduler) that takes ready fibers from a queue or some other collection and runs them on the domain. Just before entering that loop, Eio installs an Eio specific implementation of the blocking mechanism for DLA. That Eio specific implementation of blocking uses the algebraic effects (and cancellation protocol) that Eio normally uses for blocking. The support for Domainslib works the same way — before domainslib enters the loop running ready Domainslib tasks, a Domainslib specific blocking implementation is installed for DLA.

A single program can have multiple different domains running different schedulers. A library like kcas, that just wants to be able to block, can then obtain the blocking implementation from DLA without directly depending on the scheduler.

Most people should not need to know anything about DLA. It should be considered an internal implementation detail and, in the future, we might use some other standard blocking mechanism. An advantage of DLA is that it can be made to work today without changes to the runtime or Stdlib. DLA is also relatively non-intrusive. It doesn’t require making extensive changes to a scheduler and installing the support is essentially free — it just takes a few words of memory per domain. DLA should also be future proof such that once a standard blocking approach emerges, it should be possible to change the default DLA implementation to use the standard blocking mechanism.

OCaml.org Newsletter: March 2023

Archive: https://discuss.ocaml.org/t/ocaml-org-newsletter-march-2023/12090/1

Thibaut Mattio announced

Welcome to the inaugural edition of the OCaml.org newsletter!

Following the example of the now-retired Multicore monthlies, and the Compiler newsletter, we’ll be running a monthly newsletter on the progress we’re making on the development of OCaml.org.

This newsletter has been compiled by @sabine and @tmattio and offers a recap’ of the work we’ve been doing on OCaml.org in March.

We highlight the work we’ve been doing in three distinct areas:

  • Package Documentation: Following user feedback, in the past months, we’ve been focusing on improving the package documentation area. It started earlier this year with the team running a survey and user interviews, and we’re nearing the end of the improvements.
  • Learn Area: As a next milestone after improving the package documentation, we started work on the learn area with the aim to improve the learning experience of new OCaml users and offer new documentation resources to both beginners and experienced developers.
  • General Maintenance: We also worked on general maintenance and improvements, and we’ll highlight some of them.

Many thanks to all of the community members who contributed by participating in surveys, giving feedback on Discuss, and opening issues and Pull Requests! Your contributions and feedback enable us to make progress on making OCaml.org the best resource to learn OCaml and discover OCaml packages!

Package Documentation

When we started to work on the package documentation navigation, we reached out to the community on the OCaml Discuss forums with a survey on the Package and Learn areas on OCaml.org. The goal behind this was to enable our new team member, a UX/UI designer, to quickly get up to speed and make impactful contributions to OCaml.org. Thanks to the active participation of the community, this turned out to be a highly effective method to identify the most impactful issues to work on.

This month, we completed personas representing different types of users which includes mid-level developer, student, team lead, senior developer, academic instructor/researcher.

We designed the UI and user flows for two possible design options of the package section (which includes the package overview page, package documentation, the package search results, as well as an upcoming page that lists all versions of a package). You can access the designs on Figma.

We’ve been making good progress on a (low-fidelity) implementation of the designs we have in Figma, and we still have a few UI elements to rework to align the site to the designs.

Relevant PRs/Issues:

  1. We now display README/CHANGELOG/LICENSE on the package overview layout, instead of within the documentation layout. This better reflects their status as “files that accompany the package”.
  2. The source code download button and source hash display was reworked to have a better UX.
  3. The package overview page was rearranged. This improves the styling and placement of dependencies, tags, description, publication date.
  4. The authors/maintainers display was improved to (1) render an automatically-generated avatar if we don’t have one for the given user, and (2) hide excessive amounts of authors/maintainers behind a “show more” button.
  5. To make it easier to scan for relevant dependencies, we separate the dependencies into “development dependencies” and regular dependencies
  6. After moving the package overview sidebar to the left, the package overview page and the package documentation page were unified to use the same layout
  7. We now render a table of contents on the package overview pages

Learn Area

We started the discovery phase in which we are taking inventory of the current content and structure of the OCaml.org Learn area. We reviewed the user interview videos from the Q1 survey on the Learn and Package areas to extract user needs and pain points. We also started preparing a survey that specifically targets new OCaml users (both programming beginners and experienced developers). At the time we publish this newsletter, we’ve already completed the survey and we’ll be sharing the results in the next issue of this newsletter.

Improving the Learn Area will be our biggest focus in the coming months, so expect more updates on this in the following newsletters.

General Maintenance

Creating a tutorial on sequences

Archive: https://discuss.ocaml.org/t/creating-a-tutorial-on-sequences/12091/1

Cuihtlauac Alvarado announced

Following up on ocaml.org tutorial updates, I’ve created one on sequences:

Again, feedback is highly welcome

You started to learn OCaml less than 12 months ago? Please help us with our user survey on the OCaml.org Learning Area

Archive: https://discuss.ocaml.org/t/you-started-to-learn-ocaml-less-than-12-months-ago-please-help-us-with-our-user-survey-on-the-ocaml-org-learning-area/11945/2

Sabine Schmaltz announced

Here's the promised update on what kind of feedback we got out of the survey.

We distributed the survey (1) here on the OCaml Discuss, and (2) on the OCaml Discord server. The survey was also shared via (3) LinkedIn, (4) Twitter, and possibly more channels. We asked newcomers to OCaml to participate.

57 people responded to the survey and we had to close the survey early so that we have the capacity to properly analyze and categorize all feedback.

Invites have been sent out by Claire to the participants who volunteered to be interviewed.

We have found last time that the interviews helped us understand the status quo and the potential improvements from the community’s varied perspectives much better than we did only from the survey. I feel this has been a critical factor to enable us to change things for the better.

So thank you for taking the time to help us! :camel:

Editor’s note: this post is very long, please follow the link above to read it.

Explorations on Package Management in Dune

Archive: https://discuss.ocaml.org/t/explorations-on-package-management-in-dune/12101/1

Thibaut Mattio announced

The OCaml Platform team is excited to announce that we have started explorations to add support for package management in Dune.

This joint work led by the Dune, opam and opam-monorepo teams, started a few months ago with discussions on how to address what is one of the most important pain points reported by the community. This is the continuation of the focus we had in 2022 on prototyping new developer workflows and we’ll explore new workflows this integration enables throughout 2023. In particular, we’ve been developing similar workflows with opam-monorepo and we’re building on our experience of the past 3 years to explore how to implement these workflows in Dune.

As we want to involve the community as much as possible and start gathering feedback early, we wrote an RFC on GitHub that lays down a high-level overview of the different features.

The project is in the prototyping stage, so the goal of the RFC is to invite feedback and discussion from the community, rather than serve as a definitive spec of package management in Dune. We will be opening separate RFCs for the different parts as we continue our explorations.

If you want to follow our work, you can look at issues and Pull Requests tagged as `package-management` in Dune. You can also have a look at the dev meeting minutes for Dune and opam.

It’s the beginning of quite a bit project, with many people involved, so I want to take a moment to acknowledge the contributions of everyone. The initiative is spearheaded by Tarides and the Dune, opam and opam-monorepo development teams are leading the project. We are also grateful for the generous funding provided by Jane Street, whose support is instrumental to continuously improve the OCaml Platform.

Happy coding!

Functional web applications running in the browser

Archive: https://discuss.ocaml.org/t/ann-functional-web-applications-running-in-the-browser/11984/6

Continuing this thread, Helmut announced

Sounds compelling :slight_smile:

If you have the time, it'd be great if you could implement the 7 GUIs tasks to serve as example code to your lib.

https://eugenkiss.github.io/7guis/

I find this benchmark quite good: small enough in scope not to be a time sink, but complex enough to make one understand the limitations or advantages of a language or library

I have implemented some of the examples:

The last two examples of the benchmark are still missing. You can find the sources at: https://github.com/hbr/fmlib/tree/browser/src/examples/browser

Ahrefs is now built with Melange

Archive: https://discuss.ocaml.org/t/ahrefs-is-now-built-with-melange/12107/1

Javier Chávarri announced

Since last September, the Melange, Dune, and Ahrefs development teams have been working to enhance the integration between Dune and Melange. As a company that uses a lot of OCaml in the backend, Ahrefs saw an opportunity to bring its frontend stack closer to OCaml by using Melange while still integrating with the JavaScript ecosystem of UI libraries. Thus, the company decided to invest and actively participate to make this integration happen.

I am happy to announce we achieved a significant milestone in this integration process: we transitioned all Ahrefs frontend projects to use Melange. We have explained this transition in detail in a blog post:

https://tech.ahrefs.com/ahrefs-is-now-built-with-melange-b14f5ec56df4

Regarding the current state of Melange, it’s worth noting that our focus thus far has been on designing and implementing the Dune-Melange integration and applying it within Ahrefs. The goal has been to demonstrate that the toolchain can scale and be used in mid-large codebases, and the result has been successful so far. The process has been beneficial not only for Melange but also for Dune itself, as we were able to identify and address some performance issues, including a significant performance fix that made some build commands nearly 10 times faster in our case.

While we’ve made significant progress with the Dune-Melange integration, we recognize that there is still work to be done to improve the documentation and developer experience. Currently, Melange lacks a dedicated documentation site, and the latest functionality isn’t yet available in published versions of Dune and Melange on the opam repository.

We’re actively working to address this, but in the meantime, we invite those who are adventurous to explore the melange-opam-template and review the newly added melange.emit stanza documentation found in the latest version of Dune’s documentation. If you have any questions, encounter any issues, or otherwise want to participate in any way, we invite you to join the #melange channel in the Reason Discord.

Thank you for taking the time to read about our progress with the Dune-Melange integration. We hope you share our excitement about this project!

Other OCaml News

From the ocaml.org blog

Here are links from many OCaml blogs aggregated at the ocaml.org blog.

Old CWN

If you happen to miss a CWN, you can send me a message and I’ll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe online.

Posted by at No comments:
Subscribe to: Posts (Atom)