[Haskell-cafe] Asking for advice on category for a paper for ICFP
Oliver Charles
ollie at ocharles.org.uk
Tue Feb 1 18:10:55 UTC 2022
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 <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220201/2ad2dfc3/attachment.html>
More information about the Haskell-Cafe
mailing list