- Haskell-Cafe - Haskell.org

[HIW'20] Second Call for Talks
by Ben Gamari 25 Jun '20

25 Jun '20

Hello everyone, Haskell Implementors Workshop is calling for talk proposals. Co-located with ICFP, HiW is an ideal place to describe a Haskell library, a Haskell extension, compiler, works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. The deadline for submissions is July 2nd 2020. Call for Talks ============== The 12th Haskell Implementors’ Workshop is to be held alongside ICFP 2020 this year. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience ------------------------- It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2020. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: - Compilation techniques - Language features and extensions - Type system implementation - Concurrency and parallelism: language design and implementation - Performance, optimization and benchmarking - Virtual machines and run-time systems - Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw20.hotcrp.com/ until July 2nd (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- - Andrey Mokhov (Newcastle University) - Ben Gamari (Well-Typed LLP) - Christian Baaij (QBayLogic) - George Karachalias (Tweag I/O) - Klara Marntirosian (KU Leuven) - Matthew Pickering (Univeristy of Bristol) - Ryan G.L. Scott (Indiana University Bloomington) Best wishes, ~ Ben

1 1

[ANN] Enpuzzled - iOS/Android Haskell game
by Miriam 19 Jun '20

19 Jun '20

Hi everyone! After years of work, thousands of commits, and over 100 uploads to iTunes and Android, we are very happy to finally announce Enpuzzled, a Haskell game for iOS and Android. Enpuzzled is a brain teaser that anyone can enjoy quietly, so there is no timer and no rush: it's just you against the board. The game is suitable for all audiences and requires no permissions to run, as part of our recent movement 'Safe2Play'. iTunes: https://apps.apple.com/us/app/enpuzzled/id1460083994 Google Play: https://play.google.com/store/apps/details?id=uk.co.keera.games.enpuzzled Web page: https://enpuzzled.haskell.games Official announcement: https://keera.co.uk/2020/06/18/enpuzzled-released-for-android-and-ios/ Issue tracker: https://github.com/keera-studios/enpuzzled Support/questions: support(a)keera.co.uk Safe2Play: https://keera.co.uk/2020/06/17/safe2play-caring-for-privacy-in-an-interconn… This is our second self-published mobile Haskell game, and one more small step in a long way towards making Haskell a real possibility for game programming. You can find some technical details in the official announcement. We would like to publicly thank all beta testers, who patiently tried version after version, and all the people who supported the development in different ways. If you'd like to support the development of more Haskell games, please consider buying Enpuzzled and/or spreading the word. We currently have three more games at different stages of development. You can follow the development on our website and on social networks, where we will also post calls for early testers. Have fun, and happy Haskelling! Miriam, Keera Studios

1 0

Call for Tutorial Proposals: ICFP 2020
by Sam Tobin-Hochstadt 17 Jun '20

17 Jun '20

CALL FOR TUTORIAL, PANEL, AND DISCUSSION PROPOSALS ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 23 - 28, 2020 Virtual https://icfp20.sigplan.org/ The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 23-28, 2020. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". This year, following the success of the #ShutDownPL event, we are also inviting proposals for panels and discussions on topics of broader interest to the PL community. Tutorials, panels, and discussions may occur before or after ICFP, co-located with the associated workshops, on August 23 or August 27-28. ---------------------------------------------------------------------- Submission details Deadline for submission: July 17th, 2020 Notification of acceptance: July 22nd, 2020 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2020 workshop co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020(a)googlegroups.com by July 17th, 2020. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by July 22nd, 2020. The proposal form is available at: http://www.icfpconference.org/icfp2020-files/icfp20-panel-form.txt http://www.icfpconference.org/icfp2020-files/icfp20-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2020 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Leonidas Lampropoulos (University of Maryland) General Chair: Stephanie Weirich (University of Pennsylvania) Program Chair: Adam Chlipala (MIT) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020(a)googlegroups.com

1 0

FFI ccall struct return by value on the stack?
by ☂Josh Chia (謝任中) 16 Jun '20

16 Jun '20

Suppose I have the following C code: typedef struct Foo { char* p1; /* Some data on the heap. */ size_t s1; /* Size of data. */ char* p2; /* More data on the heap. */ size_t s2; } Foo; /* Allocates and writes two pieces of data on the heap and returns them in a Foo. */ Foo makeFoo(size_t x); Based on my limited understanding of Haskell FFI according to the Haskell 2010 Language Report ( https://www.haskell.org/onlinereport/haskell2010/haskellch8.html) it is not possible to have a ccall for makeFoo() because Foo is not a marshallable foreign result type. Is my understanding correct? However, I believe I can have a ccall if I change makeFoo() to either of the following: Foo* makeFoo(size_t x); void makeFoo(Foo* out, size_t x); The first involves the C code allocating a Foo and returning a pointer to it (so now there's one more pointer for the C code to deallocate later in another function). The second involves the C code writing a Foo value to a piece of memory allocated in Haskell (possibly using Foreign.Marshall.Alloc.alloca). Both signatures work because Foo* is marshallable but are clumsier to use than the original signature. Is there just no way to return a struct by value on the stack? Is there a cleaner way than the above two? Josh

5 4

transcoding - Haskell?!
by Gregory Guthrie 14 Jun '20

14 Jun '20

I think it would choke on Haskell code! Haskell has so many language extensions and pragmas, and people use many local extensions with monads to basically create DIY DSL's - that the code becomes very dense and context specific. Facebook's TransCoder AI Converts Code From One Programming Language Into Another VentureBeat Kyle Wiggers June 9, 2020 Facebook says its TransCoder can convert code from one high-level programming language into another. The system, which Facebook researchers describe as "a neural transcompiler," uses an unsupervised learning approach to translate between languages like C++, Java, and Python. The researchers trained TransCoder on a public GitHub corpus featuring more than 2.8 million open source repositories. To evaluate its capabilities, the researchers extracted 852 parallel functions in C++, Java, and Python from the online GeeksforGeeks platform and developed a new computational accuracy metric that tests whether hypothesis functions generate the same outputs as a reference when given the same inputs. Wrote the researchers, "TransCoder can easily be generalized to any programming language, does not require any expert knowledge, and outperforms commercial solutions by a large margin." Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

5 10

Norvig AI book translations...
by Gregory Guthrie 14 Jun '20

14 Jun '20

I've often thought that a book and approach like the MIT AI book by Norvig ("Artificial Intelligence: A Modern Approach" - http://aima.cs.berkeley.edu/) Would be a great way to showcase Haskell and its expressive clarity. It was thus interesting to find this article " Python for Lisp Programmers" (https://norvig.com/python-lisp.html) and https://github.com/aimacode, were the book has been translated into many other languages - but not Haskell (yet?). Haskell is such a great way to teach many programming concepts and applications in a very clean manner, and some of the books used to demonstrate and showcase other languages would be quite nice to have more common course books with Haskell! In a more playful flavor; "Impractical Python Projects" - again all things that map nicely into some simple Haskell examples. ( https://nostarch.com/impracticalpythonprojects ) "Python is a programming language, but it is also fun to play with. This book recognises that." LYAH & RWH are really great - but some books with more application oriented approaches can be good starters and inroads for introductions to Haskell. Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

3 3

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 202, Issue 14
by Michal J Gajda 13 Jun '20

13 Jun '20

After careful examination of the paper, I inferred that it mostly implemented simple loop translation, and worked only as long as the problem was small and easy to refine by direct translation token by token. It also had problems with preserving semantics of these simple loops. So while I am certain that Facebook AI tries to address important problems, the solution seems very far from practical application to large code bases and even attempts to translate the same language from one library to another. -- Best regards Michal On Sat, Jun 13, 2020 at 2:03 PM <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > Today's Topics: > > 1. transcoding - Haskell?! (Gregory Guthrie) > 2. Re: transcoding - Haskell?! (Branimir Maksimovic) > 3. Re: transcoding - Haskell?! (MigMit) > 4. Re: transcoding - Haskell?! (Branimir Maksimovic) > 5. Re: transcoding - Haskell?! (Henning Thielemann) > > > > ---------- Forwarded message ---------- > From: Gregory Guthrie <guthrie(a)miu.edu> > To: "haskell-cafe(a)haskell.org" <haskell-cafe(a)haskell.org> > Cc: > Bcc: > Date: Fri, 12 Jun 2020 17:33:47 +0000 > Subject: [Haskell-cafe] transcoding - Haskell?! > > I think it would choke on Haskell code! > > Haskell has so many language extensions and pragmas, and people use many > local extensions with monads to basically create DIY DSL’s – that the code > becomes very dense and context specific. > > > > *Facebook's TransCoder AI Converts Code From One Programming Language Into > Another* > *VentureBeat* > > * Kyle Wiggers June 9, 2020* > > Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > > > > > > > > Dr. Gregory Guthrie > > Maharishi International University > > ---------------------------------------------------------------- > > > > > > ---------- Forwarded message ---------- > From: Branimir Maksimovic <branimir.maksimovic(a)gmail.com> > To: haskell-cafe(a)haskell.org > Cc: > Bcc: > Date: Fri, 12 Jun 2020 19:44:01 +0200 > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > > It would choke on assembler as well. Digital computer hard AI is > impossible, because there is no > > algorithm for making algorithms. Mathematicaly impossible... > > Greets, Branimir. > > > On 6/12/20 7:33 PM, Gregory Guthrie wrote: > > I think it would choke on Haskell code! > > Haskell has so many language extensions and pragmas, and people use many > local extensions with monads to basically create DIY DSL’s – that the code > becomes very dense and context specific. > > > > *Facebook's TransCoder AI Converts Code From One Programming Language Into > Another* > *VentureBeat* > > * Kyle Wiggers June 9, 2020* > > Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > > > > > > > > Dr. Gregory Guthrie > > Maharishi International University > > ---------------------------------------------------------------- > > > > _______________________________________________ > 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. > > > > > ---------- Forwarded message ---------- > From: MigMit <migmit(a)gmail.com> > To: Branimir Maksimovic <branimir.maksimovic(a)gmail.com> > Cc: haskell-cafe <haskell-cafe(a)haskell.org> > Bcc: > Date: Fri, 12 Jun 2020 20:14:18 +0200 > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > I wonder if this would be true: > https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impress… > > > On 12 Jun 2020, at 19:44, Branimir Maksimovic < > branimir.maksimovic(a)gmail.com> wrote: > > > > It would choke on assembler as well. Digital computer hard AI is > impossible, because there is no > > > > algorithm for making algorithms. Mathematicaly impossible... > > > > Greets, Branimir. > > > > > > > > On 6/12/20 7:33 PM, Gregory Guthrie wrote: > >> I think it would choke on Haskell code! > >> Haskell has so many language extensions and pragmas, and people use > many local extensions with monads to basically create DIY DSL’s – that the > code becomes very dense and context specific. > >> > >> Facebook's TransCoder AI Converts Code From One Programming Language > Into Another > >> VentureBeat > >> Kyle Wiggers > >> June 9, 2020 > >> > >> Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > >> > >> > >> > >> > >> Dr. Gregory Guthrie > >> Maharishi International University > >> ---------------------------------------------------------------- > >> > >> > >> > >> _______________________________________________ > >> 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. > > > > > > ---------- Forwarded message ---------- > From: Branimir Maksimovic <branimir.maksimovic(a)gmail.com> > To: MigMit <migmit(a)gmail.com> > Cc: haskell-cafe <haskell-cafe(a)haskell.org> > Bcc: > Date: Fri, 12 Jun 2020 20:25:58 +0200 > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > As long as there is math behind that it could work. There is no > algorithm for creative thinking. Same way that if you put it on rng 1000 > monkeys will sooner or later create Shakespeare :P > > Greets, Branimir. > > On 6/12/20 8:14 PM, MigMit wrote: > > I wonder if this would be true: > https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impress… > > > >> On 12 Jun 2020, at 19:44, Branimir Maksimovic < > branimir.maksimovic(a)gmail.com> wrote: > >> > >> It would choke on assembler as well. Digital computer hard AI is > impossible, because there is no > >> > >> algorithm for making algorithms. Mathematicaly impossible... > >> > >> Greets, Branimir. > >> > >> > >> > >> On 6/12/20 7:33 PM, Gregory Guthrie wrote: > >>> I think it would choke on Haskell code! > >>> Haskell has so many language extensions and pragmas, and people use > many local extensions with monads to basically create DIY DSL’s – that the > code becomes very dense and context specific. > >>> > >>> Facebook's TransCoder AI Converts Code From One Programming Language > Into Another > >>> VentureBeat > >>> Kyle Wiggers > >>> June 9, 2020 > >>> > >>> Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > >>> > >>> > >>> > >>> > >>> Dr. Gregory Guthrie > >>> Maharishi International University > >>> ---------------------------------------------------------------- > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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. > > > > > ---------- Forwarded message ---------- > From: Henning Thielemann <lemming(a)henning-thielemann.de> > To: Gregory Guthrie <guthrie(a)miu.edu> > Cc: haskell-cafe(a)haskell.org > Bcc: > Date: Fri, 12 Jun 2020 21:51:30 +0200 (CEST) > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > > On Fri, 12 Jun 2020, Gregory Guthrie wrote: > > > I think it would choke on Haskell code! > > > > Haskell has so many language extensions and pragmas, and people use many > > local extensions with monads to basically create DIY DSL’s – that the > > code becomes very dense and context specific. > > It could have its use to convert legacy code in legacy languages to shiny > new Haskell code. :-)_______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Pozdrawiam Michał

1 0

Re: [Haskell-cafe] Future of lucid
by chris done 12 Jun '20

12 Jun '20

Hi Gabriel, I enabled the issue tracker earlier today for those reasons. Unfortunately, GitHub doesn't distinguish between "mailing list where chat can occur" and "tasks the devs plan to put time and energy into", it's all dumped into one pot. I consider this a shortcoming of GitHub. It actually distorts the meaning of "to maintain" from "keeping the software correct and working" to "responding to and acknowledging any and all commentary by anyone at any time for any duration, teaching fellow developers about how to use Git, GitHub, among other mentorship tasks" the temporary or prolonged neglect of which is deemed to be not putting on a good show, or in your own words, "not maintaining it". The more I reflect on it, the more I see why many project maintainers burn out on GitHub. I will continue using lucid and patching it to move with the times as GHC's type system moves along and HTML 5 elements/attributes are added, and merge pull requests related to these stated goals, for the foreseeable future, but I plan to do no more than that. If that's not good enough for Dhall, then there are plenty of other options.[1] Cheers, Chris [1]: https://www.reddit.com/r/haskell/comments/h05uwn/experience_report_choosing… On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > Would it be possible to leave the issue tracker on but just disable your own email notifications for the repository if you do not plan to maintain it? The two main reasons I suggest this are: > > * We would like a way to be able to petition Oleg for changes (or whoever is the maintainer at the time) > * We would like to know if other people share the same problem we do (or vice versa, educate other users of problems we are having and potential workarounds) > >> On Jun 10, 2020, at 6:23 AM, chris done <haskell-cafe(a)chrisdone.com> wrote: >> >> Hi Simon, >> >> I am still maintaining and actively using the package. Architecture-wise, nothing substantial has changed in the 6 years since its release. Just small additions. This package pretty much maintains itself. PRs come and go. >> >> In fact, any kind of overhauls or user-facing design changes at this stage would cause disruption and I would encourage that to be achieved in a separate package with a new name. In review, I'm very happy with Lucid's design and plan to maintain it long-term into the future for as long as HTML is relevant. >> >> However, I am providing no Q&A or "tech support". Having an issue tracker would say otherwise. >> >> Oleg is also a maintainer. >> >> Cheers, >> >> Chris >> >> On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: >>> Hi! >>> >>> I recently noticed that the issue tracker for the lucid package at >>> >>> https://github.com/chrisdone/lucid >>> >>> has been disabled. Does this have any implications for the future >>> maintenance of the package? Is anyone still committed to maintaining >>> the package? >>> >>> (I've CC'd Oleg who made the most recent commit to the repo.) >>> >>> The context for my question is that we'd like to use lucid for the >>> documentation generator that is being developed as a part of >>> this year's GSoC. >>> >>> Thanks! >>> Simon

5 7

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Anthony Clayden 12 Jun '20

12 Jun '20

(Golly, this went meta rather quickly.) >> Am 08.06.20 um 16:07 schrieb amindfv at gmail.com <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>: >>* Haskell's reputation as a welcoming community is on shakier ground *>>* than it was a few years ago, and phrases like "despite your endless *>>* ranting" work against the collegial atmosphere we're proud of.* *Thank you Tom for reminding us these messages are visible to public/posterity.* *I woke up this thread because I was worried what posterity would make of last year's discussion -- which seemed to accept the 'thought-dialogue' uncritically; certainly no indication it was intended merely as a bit of humour. (I remain unconvinced that it was.) * > Ben Franksen wrote: > To put this in perspective, here are a few citations from what I have > called "endless ranting": Let's start near the beginning of the ewd.pdf, please (capitalisation and shrieks in the original) "Haskeller: WHOA! Hold it! You are misappropriating our religion!" It was Ben who described some of my language as "ranting". How would you describe Haskeller's? I'm sure we're all aware of Why Functional Programming Matters, without going so far as making a religion of it nor thinking other paradigms don't matter. The imperative paradigm is not "antiquated" (contra what Haskeller says): Turing machines and Lambda calculus hit the world in publications in the same year. And despite Ben's finely-tuned sense of humour, you seem not so finely-tuned to the Use-mention distinction en.wikipedia.org/wiki/Use-mention_distinction. I was pointing to (i.e. mentioning) the language in that pdf as not being representative of the Haskell community I know; I was not myself using such emotionally-loaded language. I'm happy to defend my observations as matters of factual error or misrepresentation; I've presented that evidence up-thread, but briefly: >>* ... misapplying ... in a rather badly-informed way.* *Fact: EWD1300 is considering mathematical notation, not programming languages. As regards using semicolon for function composition, at no point does EWD1300 consider the clash with semicolon in ALGOL-derived languages.* *Fact: Haskeller's responses top of page 2 re operator sections are incorrect, see Haskell Report.* *Fact: Haskeller's answer re `length $ []` is wrong: try it in GHC.* >>* ... it doesn't seem to know Haskellers very well; nor Dijkstra's *>>* well-known support for Haskell in education.* *Fact: See above re over-emotional opening remarks; that "Jumping", "Beaming", "Irritated", "Exasperated", "Warily" emotionality is not how Haskellers behave in my experience.* *Fact re Haskell in Education: Dijkstra's 'To the Members of the Budget Council', in his UTexas archive.* >* ... can't even spell his first name right... * *Fact: docos on that the-magus site give "Edsgar"; it's not difficult to spell someone's name right.* >* ... it's a couple of dudes shooting the breeze.* *Fact: Ben said in an earlier message, of the authors of the pdf "obviously exaggerated ... artist's freedom ... rhetoric a bit over the top ...". In comparison 'shooting the breeze' from me seems quite mild; not "ranting".* >* ...To put it bluntly: the authors are blundering.* >* ... a bogus problem; direct consequence of the authors not *>* understanding EWD1300. * *That's the conclusion I reached after analysing their mistakes. I stand by it; see the facts I pointed out in that earlier message.* > Do you regard this as "welcoming" language? If not, where was your > concerned reply when they hit the list? (Presumably that's a q to Tom.) > IMO the occasional ranting doesn't hurt anybody as long as it is > addressed not to people but to technical shortcomings. However, the > above citations are clearly ad-hominem attacks. I disagree they're attacks; I'm pointing out technical shortcomings and mis-representations. If it's ad-anybody, the people are the faux-Haskeller and faux-EWD. > Or is your point that I directly addressed the author of the above > lines, rather than attacking some third party? I had already emailed the-magus making these same points. And of course the site doesn't accept (publicly-visible) comments. I doubt I'll get a reply, since the site seems to have died several years ago. Then where do I address the authors? I thought it appropriate I reawaken the thread here from last year. AntC

2 1

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Olaf Klinke 11 Jun '20

11 Jun '20

Now I can't tell whether you're teasing to keep this thread alive. If it is humour, it is lost on me. > Report section 6.4.1 Numeric Literals. "An integer literal represents > the application of the function `fromInteger` to the appropriate > value > of type `Integer`." > > OK. How do we write in Haskell that "appropriate value"? > To me that part of the report is obviously about compile-time code generation. The sentence itself is not recursive, it is "literal" versus "value". The two concepts live in different domains. Why do you think its meaning may be recursive? I imagine that when the compiler sees the literal 7, it de-sugars to (fromInteger (mkInteger ...)) where the inner expression is code from GHC.Integer that does not invoke fromInteger again. When the entire expression is to be of type Integer, then the fromInteger dictionary lookup replaces that by id. So the entire expression can be optimized to be whatever core expression generates the Integer seven, most likely S# 7#. Olaf

1 0