[Haskell-cafe] Asking for advice on category for a paper for ICFP

Tue Feb 1 19:20:30 UTC 2022

Depending on what it is, it may be a good fit. Feel free to send details
(publicly, privately).

I have presented several papers on novel implementations and
extensions/uses of FRP, at the Haskell Symposium and ICFP, some built
around very simple concepts.

>From https://github.com/ivanperez-keera/dunai/#reading

   - Hλ Sym: Functional Reactive Programming, Refactored
   <https://dl.acm.org/authorize?N34896> (official ACM page
   <http://dl.acm.org/citation.cfm?id=2976010>) (mirror
   <http://www.cs.nott.ac.uk/~psxip1/>)

   -

   ICFP Pearl: Fault Tolerant Functional Reactive Programming
   <https://dl.acm.org/citation.cfm?id=3236791>
   -

   Hλ Sym: Rhine: FRP with type-level clocks
   <https://dl.acm.org/citation.cfm?id=3242757>
   -

   Hλ Sym: Back to the Future: time travel inIn case it helps: FRP
   <http://dl.acm.org/citation.cfm?id=3122957> (mirror
   <http://www.cs.nott.ac.uk/~psxip1/>)
   -

   ICFP: Testing and Debugging Functional Reactive Programming
   <http://dl.acm.org/citation.cfm?id=3110246>

Sometimes, what you lack in theoretical contribution you can make up with
use cases or real-world use.

There's also REBLS, co-located with OOPSLA.

I'd love to see it your solution. Many I find in the FRP zoo can be reduced
to an MSF with a specific monad or extended in some way. There was a paper
at REBLS 2019 (?) on async FRP that could be expressed as an MSF on the
continuation monad.

That possibility, if it applies, should be encouraging not discouraging.
The FRP land is overpopulated. If you can build your solution as an
extension to or specialization of an existing one, it makes using and
comparing them much easier. As a frequent reviewer in FP/FM conferences,
I'd be more likely to accept a solution expressed that way.

Ivan

On Tue, 1 Feb 2022 at 19:38, amindfv--- via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Hi Anton,
>
> Based on your description, this sounds like it could possibly be a good
> fit for FARM (https://icfp20.sigplan.org/series/farm,
> https://functional-art.org), which is co-located with ICFP. I've seen a
> few novel FRP systems presented there (and a few years back presented one
> myself).
>
> Tom
>
>
> On Tue, Feb 01, 2022 at 09:01:39PM +0300, Anton Kholomiov wrote:
> > Thanks for the answer Richard!
> > For now I have some guide points and questions to think about.
> >
> > I did bindings to gloss and brick to elaborate the ideas, and it seems to
> > be fun to use.
> > Even if it will get rejected I'll just release it for others.
> >
> > вт, 1 февр. 2022 г. в 18:56, Richard Eisenberg <lists at richarde.dev>:
> >
> > > This is a good question, and there's no easy answer. My first
> impression
> > > is that a new implementation of an existing idea probably would not
> qualify
> > > as a big enough contribution to be accepted at ICFP -- but I don't
> know FRP
> > > well enough to really know (and I certainly don't know how impactful
> your
> > > new approach is). It's plausible that a new implementation of an
> existing
> > > idea would be accepted, but it would have to be pretty
> thought-provoking. A
> > > good rule-of-thumb is: if a reader had no particular interest in using
> your
> > > implementation or writing their own FRP implementation, is there
> something
> > > for them to learn? That is, does your approach generalize to non-FRP
> tasks?
> > > Does it use a feature of Haskell or of a lazy programming language or
> of a
> > > functional programming language in a new, surprising way? Does your
> > > approach to analyzing why your implementation is better than others
> offer
> > > insight? If the answers to these (or similar) questions is "yes", then
> > > perhaps a research paper would work.
> > >
> > > On the other hand, a key attribute of a functional pearl is its
> elegance
> > > and beauty. Does your approach take a knot of complication in other FRP
> > > implementations and make it go away by construction? Is your approach
> > > guaranteed faster by some aspect of its design? Would a reader (who
> doesn't
> > > know about FRP implementations) read what you've written and smile at
> the
> > > ingenuity of it all? Positive answers to these types of question
> suggest
> > > that a functional pearl is best.
> > >
> > > Sadly, there are many neat ideas that fit neither of these molds --
> > > implementation-oriented work often doesn't. And, if you don't fit the
> mold
> > > of the category you're writing for, your paper may well get rejected,
> even
> > > if it's a good contribution. I don't have a solution here; I think
> this is
> > > a weakness of the current publication model.
> > >
> > > I hope this advice is helpful!
> > > Richard
> > >
> > > > On Feb 1, 2022, at 10:07 AM, Anton Kholomiov <
> anton.kholomiov at gmail.com>
> > > wrote:
> > > >
> > > > Hi!
> > > >
> > > > I'm trying to write a paper for ICFP, This is my first paper of this
> > > kind.
> > > > Can you please help me to choose the right category for it?
> > > >
> > > > The paper is about a novel technique of implementation of FRP.
> > > > I've studied the Haskell FRP zoo and I can confirm that it's novel.
> > > > In my opinion it's very elegant and simple, but of course I'm biased
> :)
> > > >
> > > > So far so good. Can you please help me to choose the right category
> for
> > > it?
> > > > Is it a normal research paper or is it a functional pearl?
> > > >
> > > > So the FRP is an old technique, but I propose a novel variant of
> > > implementation
> > > > which I hope is easy to study even in normal class rooms and does not
> > > contain
> > > > unsafePerform tricks.
> > > >
> > > > Cheers,
> > > > Anton
> > > > _______________________________________________
> > > > Haskell-Cafe mailing list
> > > > To (un)subscribe, modify options or view archives go to:
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > > Only members subscribed via the mailman list are allowed to post.
> > >
> > >
>
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220201/8995315f/attachment.html>