June 2020 - Haskell-Cafe

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 13 Jun '20

13 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 11 Jun '20

11 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 11 Jun '20

11 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 10 Jun '20

10 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

Future of lucid
by Simon Jakobi 10 Jun '20

10 Jun '20

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 Dhall documentation generator that is being developed as a part of this year's GSoC. Thanks! Simon

2 4

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

10 Jun '20

> Richard O'Keefe wrote: > ... More seriously, in "f x", there is an explicit > operator already. It's "f". The space is needed for lexical > reasons only. If you say no, functions are not operators -- > though in Haskell infix operators are functions -- but > application is the operator, so you should write "f @ x <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>" (usual > FP notation) or "f.x" (Dijkstra), then although it isn't > technically true, I've always felt that there is an infinite > regress lurking in the background: > if x + y means (+) x y > which really stands for (+)@x @ <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> y > then shouldn't that in turn stand for (@)((@)(+)x)y > and what should _that_ stand for? Heh, heh there's another corner where Haskell semantics appears to give an infinite regress; and we have to suppose there's some internal magic that can't be expressed in the surface language: 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"? We could write `7 :: Integer` but that's shorthand for `(fromInteger #7#) :: Integer`, in which I've used `#7#` to denote the "appropriate value" doo-hickey. There's no way in Haskell to write a literal that's type `Integer`, except by invoking `fromInteger`. `(fromInteger (7 :: Integer)) :: Integer` ? Both the explicit and implicit `fromInteger` in there are no-ops. AntC

1 0