-------------------------------
C A L L F O R P A P E R S
-------------------------------
====== TFP 2019 ======
20th Symposium on Trends in Functional Programming
12-14 June, 2019
Vancouver, BC, CA
https://www.tfp2019.org/index.html
== Important Dates ==
Submission Deadline for pre-symposium formal review Thursday, March
28, 2019
Sumbission Deadline for Draft Papers Thursday, May 9, 2019
Notification for pre-symposium submissions Thursday, May 2, 2019
Notification for Draft Papers Tuesday, May 14, 1029
TFPIE Tuesday, June 11,
2019
Symposium Wednesday, June 12, 2019 – Friday, June 14, 2019
Notification of Student Paper Feedback Friday June 21, 2019
Submission Deadline for revised Draft Papers (post-symposium formal review)
Thursday, August
1, 2019
Notification for post-symposium submissions Thursday, October
24, 2019
Camera Ready Deadline (both pre- and post-symposium) Friday, November
29, 2019
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 (see
below at scope).
Please be aware that TFP uses two distinct rounds of submissions (see
below at submission
details).
TFP 2019 will be the main event of a pair of functional programming
events. TFP 2019
will be accompanied by the International Workshop on Trends in
Functional Programming
in Education (TFPIE), which will take place on June 11.
== 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 2019 program chairs, William J. Bowman and Ron Garcia.
== Best Paper Awards ==
To reward excellent contributions, TFP awards a prize for the best paper
accepted for
the formal proceedings.
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 listed as first authors, and a student would present the paper. A
prize for the
best student paper is awarded each year.
In both cases, it is the PC of TFP that awards the prize. In case the
best paper happens
to be a student paper, that paper will then receive both prizes.
== Instructions to Author ==
Papers must be submitted at:
https://easychair.org/conferences/?conf=tfp2019
Authors of papers have the choice of having their contributions formally
reviewed either
before or after the Symposium.
== Pre-symposium formal review ==
Papers to be formally reviewed before the symposium should be submitted
before an early
deadline and receive their reviews and notification of acceptance for
both presentation
and publication before the symposium. A paper that has been rejected in
this process may
still be accepted for presentation at the symposium, but will not be
considered for the
post-symposium formal review.
== Post-symposium formal review ==
Papers submitted for post-symposium 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 received at
the symposium. A
post-symposium refereeing process will then select a subset of these
articles for formal
publication.
== Paper categories ==
There are two types of submission, each of which can be submitted either
for pre-symposium
or post-symposium review:
Extended abstracts. Extended abstracts are 4 to 10 pages in length.
Full papers. Full papers are up to 20 pages in length.
Each submission also belongs to a category:
research
position
project
evaluation
overview paper
Each submission should clearly indicate to which category it belongs.
Additionally, a draft paper submission—of either type (extended abstract
or full paper) and
any category—can be considered a student paper. A student paper is one
for which primary
authors are research students and the majority of the work described was
carried out by the
students. The submission should indicate that it is a student paper.
Student papers will receive additional feedback from the PC shortly
after the symposium has
taken place and before the post-symposium submission deadline. Feedback
is only provided for
accepted student papers, i.e., papers submitted for presentation and
post-symposium formal
review that are accepted for presentation. If a student paper is
rejected for presentation,
then it receives no further feedback and cannot be submitted for
post-symposium review.
== Format ==
Papers must be written in English, and written using the LNCS style. For
more information
about formatting please consult the Springer LNCS web site
(http://www.springer.com/lncs).
== Program Committee ==
Program Co-chairs
William J. Bowman University of British Columbia
Ronald Garcia University of British Columbia
Matteo Cimini University of Massachusetts Lowell
Ryan Culpepper Czech Technical Institute
Joshua Dunfield Queen's University
Sam Lindley University of Edinburgh
Assia Mahboubi INRIA Nantes
Christine Rizkallah University of New South Wales
Satnam Singh
Marco T. Morazán Seton Hall University
John Hughes Chalmers University and Quviq
Nicolas Wu University of Bristol
Tom Schrijvers KU Leuven
Scott Smith Johns Hopkins University
Stephanie Balzer Carnegie Mellon University
Viktória Zsók Eötvös Loránd University
-------------------------------
C A L L F O R P A P E R S
-------------------------------
====== TFP 2019 ======
20th Symposium on Trends in Functional Programming
12-14 June, 2019
Vancouver, BC, CA
https://www.tfp2019.org/index.html
== Important Dates ==
Submission Deadline Thursday, March 28, 2019
Paper Notification Thursday, May 2, 2019
TFPIE Tuesday, June 11, 2019
Symposium Wednesday, June 12, 2019 – Friday, June
14, 2019
Student Paper Feedback Friday June 21, 2019
Submission for Formal Review Thursday, August 1, 2019
Notification of Acceptance Thursday, October 24, 2019
Camera Ready Friday, November 29, 2019
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 (see
below at scope).
Please be aware that TFP uses two distinct rounds of submissions (see
below at submission details).
TFP 2019 will be the main event of a pair of functional programming
events. TFP 2019 will be accompanied by the International Workshop on
Trends in Functional Programming in Education (TFPIE), which will take
place on June 11.
== 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 2019 program chairs, William J. Bowman and Ron
Garcia.
== Best Paper Awards ==
To reward excellent contributions, TFP awards a prize for the best paper
accepted for the formal proceedings.
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 listed as first authors, and a student would
present
the paper. A prize for the best student paper is awarded each year.
In both cases, it is the PC of TFP that awards the prize. In case the best
paper happens to be a student paper, that paper will then receive both
prizes.
== Instructions to Author ==
Papers must be submitted at:
https://easychair.org/conferences/?conf=tfp2019
Authors of papers have the choice of having their contributions formally
reviewed either before or after the Symposium.
== Pre-symposium formal review ==
Papers to be formally reviewed before the symposium should be submitted
before an early deadline and receive their reviews and notification of
acceptance for both presentation and publication before the symposium. A
paper that has been rejected in this process may still be accepted for
presentation at the symposium, but will not be considered 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 web site.
== Program Committee ==
Program Co-chairs
William J. Bowman University of British Columbia
Ronald Garcia University of British Columbia
Matteo Cimini University of Massachusetts Lowell
Ryan Culpepper Czech Technical Institute
Joshua Dunfield Queen's University
Sam Lindley University of Edinburgh
Assia Mahboubi INRI Nantes
Christine Rizkallah University of New South Wales
Satnam Singh
Marco T. Morazán Seton Hall University
John Hughes Chalmers University and Quviq
Nicolas Wu University of Bristol
Tom Schrijvers KU Leuven
Scott Smith Johns Hopkins University
Stephanie Balzer Carnegie Mellon University
Viktória Zsók Eötvös Loránd University
Voting is now closed on the Tangerine Edition ballot and the accompanying
Orange Edition straw poll. My thanks to the 29 Schemers who weighed in on
what will be part of the Tangerine Edition, as well as the 17 Schemers who
provided feedback on what should and should not appear on the Orange
Edition ballot. Note that proposals passed by a majority of the votes
cast: "no vote" did not count one way or another.
The raw votes are available as Google spreadsheets at <
http://tinyurl.com/tangerine-results> and <
http://tinyurl.com/orange-straw-results). The Chair edited Vincent Manis's
vote from "no vote" to "SRFI 152" at his own request.
The following nine SRFIs passed with resounding majorities:
SRFI 115 (combinator-based regular expressions)
SRFI 141 (comprehensive integer division operators)
SRFI 143 (fixnum operators)
SRFI 144 (flonum operators, R6RS plus <math.h>)
SRFI 146 (persistent tree and hash mappings)
SRFI 151 (comprehensive bitwise operations on integers)
SRFI 158 (backward-compatible additions to SRFI 127 on generators)
SRFI 159 (combinator formatting)
SRFI 160 (comprehensive homogeneous vector library, including
inexact-complex vectors)
The sample implementation of SRFI 160 is not yet written: however, the API
has mostly stabilized, excluding u1vectors (bitvectors) from consideration
and adding a (srfi 160 base) library that provides SRFI 4 support for all
SRFI 4 vector types plus the complex types.
The R6RS library (rnrs bytevectors) was adopted into Tangerine, also by a
large majority. Implementors should note that "must" when applied to a
procedure or macro argument means only "it is an error unless"; actually
signaling an error is not required. In addition, there are corrections at <
http://www.r6rs.org/r6rs-errata.html>, including substantive changes to the
`utf16->string` and `utf32->string` procedures. A portable R7RS-small
implementation of this library written by Will Clinger can be found at
snow-fort.org and in the contrib/cowan subdirectory of the SRFI 4
repository.
Required support for the full numeric tower, including bignums up to an
implementation-defined limit, ratios (exact non-integers), inexact numbers,
and complex (non-real) numbers both exact and inexact, is also part of
Tangerine. There are no such requirements in R7RS-small. Note that while
most numeric types were uncontroversial, exact complex numbers passed by
just one vote. (See <
http://mentalfloss.com/article/59873/10-elections-decided-one-vote-or-less>
for other elections decided by a single vote.)
Finally, the vote on the string library was problematic. Out of 26 votes
cast, a one-vote majority of 14 voted for SRFI 152, a simple index-based
string library. However, rather than accepting the Will of the People in
this particular case, your Chair has decided to disregard this vote and
postpone the choice of a string library to the Green Edition. Anyone who
wishes to appeal against this decision should post to <
scheme-reports-wg2(a)googlegroups.com>, and if anyone does, a vote will be
taken on that list whether to sustain the Chair's decision (no string
library yet) or override it (SRFI 152 becomes the string library).
Why am I doing this? There were 6 votes for the original SRFI 13, of which
SRFI 152 is a subset. There were 3 votes for the cursor-based SRFI 130,
which its author has offered to rewrite (as a new SRFI) to remove some
substantive objections to it. SRFI 140, which splits Scheme strings into
mutable and immutable subtypes, also received 3 write-in votes: I had
excluded it from the ballot because it cannot be portably implemented on
top of R7RS-small, and non-portable SRFIs are collected in the Green
Edition. For that reason, string libraries will be revoted then. (In the
Red Edition, no proposal obtained a majority.)
As is traditional, the Chair is giving the new libraries their official
names. The names corresponding to the SRFIs in the order listed above
are: (scheme regex), (scheme division), (scheme fixnum), (scheme flonum),
(scheme mapping) and (scheme mapping hash), (scheme bitwise), (scheme
generator), (scheme format), and (scheme vector @), where @ is a
metasyntactic variable for any of {base, u8, s8, u16, s16, u32, s32, u64,
s64, f32, f64, c64, c128}. The (rnrs bytevectors) library will be known
within R7RS-large as (scheme bytevector): note the change from plural to
singular to conform with other R7RS library names.
The (scheme mapping hash) library has fewer operations than the (scheme
mapping) library, but is usable with unordered data types provided a good
hash function can be written for them.
This decision supersedes within R7RS-large the Red Edition's definition of
(scheme generator) as SRFI 158. This should affect nobody except people
who have used one of the 19 new identifiers for some other purpose, in
which case import exclusion is at their service.
Of the nine libraries asked about on the Orange Edition straw poll, all
were well-supported (with volunteers to implement some of them) except the
prime number library at <
https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/PrimesGauche.md>.
There was also a one-vote majority against the TalliesCowan (descriptive
statistics) library, but as there is a volunteer to implement it, I'll
leave it on the docket for now.
--
John Cowan http://vrici.lojban.org/~cowan cowan(a)ccil.org
weirdo: When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.
Hi all,
I am happy to announce the release of Gerbil v0.15, to go with Gambit
v4.9.2.
The highlight of this release is full support for R7RS Red edition and
many new libraries, improvements and bug fixes.
In addition:
- For MacOS users: Gerbil is in homebrew now!
- We have launched the gerbil package directory.
- The Gerbil Treadmill is a new emacs mode by edw.
As usual, for sources and downloads:
https://github.com/vyzo/gerbilhttps://github.com/vyzo/gerbil/releases
Full release changelog:
https://github.com/vyzo/gerbil/blob/master/CHANGELOG.md
For questions and support, come say hi on #gerbil-scheme in irc.freenode.net
.
Happy Hacking!
-- vyzo
On Fri, Jan 18, 2019 at 3:20 PM Ivan Raikov <ivan.g.raikov(a)gmail.com> wrote:
> Isn't the difference with R6RS that R7RS-large draws extensively on
> SRFIs which are indeed attempts to codify existing practices?
>
SRFIs don't always codify existing practice, including the SRFIs drawn on
in past, present, and future R7RS-large ballots. The original intention of
the
Steering Committee, I think, had nothing to do with SRFIs; I simply decided
when writing the charter (which the committee approved) to leverage both
existing and to-be-written SRFIs in order to be able to create R7RS-large
piecemeal, which has always seemed to me the only practical approach.
That said, SRFIs often do refer to existing implementations, or
implementations
of languages other than Scheme.
>
> On Thu, Jan 17, 2019 at 5:15 PM Per Bothner <per(a)bothner.com> wrote:
> >
> > On 1/16/19 6:27 AM, John Cowan wrote:
> > > So what is happening is that people are voting for more rather than
> less, as with the Red Edition. This encourages me that I'm going in a
> sensible direction with the large language.
> >
> > For the record, I'm extremely leery of the more-is-better approach.
> > We seem to be adding a large number of very large APIs, which seems
> > to be contrary to the Scheme ideal of small well-chosen primitives
> > that work synergistic well together. People were unhappy with R6RS
> > because of its size and that so much of it was invention rather than
> > codifying existing practice. R7RS-large is the same - but much more so.
> > --
> > --Per Bothner
> > per(a)bothner.com http://per.bothner.com/
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scheme-reports-wg2+unsubscribe(a)googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
On Thu, Jan 17, 2019 at 8:15 PM Per Bothner <per(a)bothner.com> wrote:
For the record, I'm extremely leery of the more-is-better approach.
> We seem to be adding a large number of very large APIs, which seems
> to be contrary to the Scheme ideal of small well-chosen primitives
> that work synergistic well together.
I don't believe that that idea ever applied to the Scheme library, otherwise
the list primitives would have been pair?, car, cdr, cons, null?, set-car!,
and
set-cdr!, and possibly not even the last two.
Allow me to quote the first paragraph of Olin Shivers's rationale for SRFI
1, itself
a "very large API" of 149 procedures, especially when compared to the
7 minimal procedures above and the 50 R6RS procedures, yet SRFI 1 is
very popular and 24 of the 32 Schemes for which I have SRFI data
implement it.
The set of basic list and pair operations provided by R4RS/R5RS Scheme is
> far from satisfactory. Because this set is so small and basic, most
> implementations provide additional utilities, such as a list-filtering
> function, or a "left fold" operator, and so forth. But, of course, this
> introduces incompatibilities -- different Scheme implementations provide
> different sets of procedures.
The SRFI 43 rationale (by Taylor Campbell) begins similarly:
R5RS provides very few list-processing procedures, for which reason SRFI 1
> (list-lib) exists. However, R5RS provides even fewer vector operations —
> while it provides mapping, appending, et cetera operations for lists, it
> specifies only nine vector manipulation operations —: [list omitted] .
> Many Scheme implementations provide several vector operations beyond the
> miniscule set that R5RS defines (the typical vector-append, vector-map, et
> cetera), but often these procedures have different names, take arguments in
> different orders, don't take the same number of arguments, or have some
> other flaw that makes them unportable. For this reason, this SRFI is
> proposed.
Finally, here's Olin again in SRFI 33, bitwise operations:
If you believe in "small is beautiful," then what is your motivation
for including anything beyond BITWISE-NAND?
Quant. suff.
--
John Cowan http://vrici.lojban.org/~cowan cowan(a)ccil.org
You are a child of the universe no less than the trees and all other acyclic
graphs; you have a right to be here. --DeXiderata by Sean McGrath
Well, there are two weeks to go on the Tangerine Edition ballot (cutoff is
12 noon UTC on Saturday, February 2). So far, 18 people have voted,
including me. For the Red Edition we had 30 voters, so I hope some of you
who haven't voted yet will take an interest and give us your views.
Remember that you don't have to vote on all issues: choosing "No vote" is
equivalent to abstaining, which does not affect the outcome, as votes are
decided by a majority of the votes cast.
As in the Red Edition, the choice of string library (issue #1) has been the
most controversial. There was no majority vote cast in the Red Edition, so
the issue is being reballoted. Currently, the index-based SRFI 152, which
is meant to be a simple basic string library, holds a majority position,
but only by a single vote. There is a strong minority for the original
SRFI 13, which is a superset (with a few deviations) of 152. SRFI 130,
which is cursor-based, has only a single vote. Three write-in votes were
cast for SRFI 140, which I excluded from Tangerine because it provides
adjustable-length strings. These, like all other features that can't be
implemented (at least minimally) on top of R7RS-small, have been postponed
to the Green Edition. I voted for SRFI 152.
Issue #4, supplementing the Red Edition's SRFI 127 generators with their
dual, accumulators, is substantially beating the alternatives of status quo
and no library. Issue #6 is about bitwise operations on integers, and the
comprehensive SRFI 151 is dominating the R6RS alternative. The same thing
is happening with fixnums (issue #7) and flonums (issue #8), where SRFIs
143 and 144, both supersets of R6RS, are getting more support than the R6RS
alternatives. SRFI 160 is a superset of SRFI 4 that provides homogeneous
vectors (issue #10), and it too is winning, though by a lesser margin.
Surprising to me is that for the combinator-based formatting library (issue
#11), the combinator-based SRFI 159 is in a majority position over SRFI 48,
the traditional template-based (as in Common Lisp) alternative.
Essentially all the remaining issues are yes/no/abstain, and yes is
dominant all down the line, though a little less so for ratios (issue #13)
and exact complex numbers (issue #16). I voted with the majority for all
of these except exact complex numbers.
So what is happening is that people are voting for more rather than less,
as with the Red Edition. This encourages me that I'm going in a sensible
direction with the large language.
--
John Cowan http://vrici.lojban.org/~cowan cowan(a)ccil.org
It was dreary and wearisome. Cold clammy winter still held sway in this
forsaken country. The only green was the scum of livid weed on the dark
greasy surfaces of the sullen waters. Dead grasses and rotting reeds loomed
up in the mists like ragged shadows of long-forgotten summers.
--LOTR, "The Passage of the Marshes"
I have sent a request to the SRFI Editor to remove all references to
u1vectors (bitvectors) from SRFI 160, which is a part of the Tangerine
Edition ballot. This is being done not because they are not useful, but
because they are different enough in both specification and implementation
from the other homogeneous vectors to deserve to be put into a future SRFI
of their own, which will be balloted in a later edition.
If anyone wishes to change their vote as a result of this change (I hope
not), simply go to http://tinyurl.com/tangerine-ballot and submit a second
form. You can set all other questions to "No vote" and I will merge your
two ballots. In all cases except "No vote", the later ballot will take
precedence.