Asking for advice on category for a paper for ICFP

older
[ANN] opc-xml-da-client, a client...

Anton Kholomiov

1 Feb 2022 1 Feb '22

10:07 a.m.

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

Attachments:

attachment.html (text/html — 910 bytes)

Show replies by date

Richard Eisenberg

1 Feb 1 Feb

10:56 a.m.

New subject: Asking for advice on category for a paper for ICFP

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 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.

Anton Kholomiov

1:01 p.m.

New subject: Asking for advice on category for a paper for ICFP

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 :

...

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 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.

Oliver Charles

1:10 p.m.

New subject: Asking for advice on category for a paper for ICFP

At the very least, please do release it! I would be very interested to see what you've got :) Ollie On Tue, 1 Feb 2022, at 6:01 PM, 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 :

...
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 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.

amindfv＠mailbox.org

1:35 p.m.

New subject: Asking for advice on category for a paper for ICFP

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 :

...
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 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.

Ivan Perez

2:20 p.m.

New subject: Asking for advice on category for a paper for ICFP

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@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

...
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 :

...
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

...
...
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

...
...
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

On Tue, Feb 01, 2022 at 09:01:39PM +0300, Anton Kholomiov wrote: thought-provoking. A the 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@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.

Anton Kholomiov

2 Feb 2 Feb

2:28 a.m.

New subject: Asking for advice on category for a paper for ICFP

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 :

...

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@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

...
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 :

...
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

...
...
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

...
...
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

On Tue, Feb 01, 2022 at 09:01:39PM +0300, Anton Kholomiov wrote: thought-provoking. A the 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@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.

1203

Age (days ago)

1204

Last active (days ago)

List overview

Download

6 comments

5 participants

participants (5)

amindfv＠mailbox.org
Anton Kholomiov
Ivan Perez
Oliver Charles
Richard Eisenberg