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

Anton Kholomiov anton.kholomiov at gmail.com
Wed Feb 2 07:28:30 UTC 2022


Thanks alot for comments and encouragement!

@Ivan I will study your papers, thanks for the links, it can be a good
example as you also have mentioned the categories in which papers were
published

@Ollie yeah, I plan to release after I submit the paper and get feedback
from the reviewers, I guess it's going to be in the March

@Tom Good to know I can consider that, I've also did a talk on the farm in
2019 on my musical library

вт, 1 февр. 2022 г. в 22:21, Ivan Perez <ivanperezdominguez at gmail.com>:

> 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/20220202/db746287/attachment.html>


More information about the Haskell-Cafe mailing list