- Haskell-Cafe - Haskell.org

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

Library maintainers: Include your library in CodeWorld web-based Haskell environment
by Chris Smith 09 Jun '20

09 Jun '20

Hello, I'm the maintainer of CodeWorld. In addition to the K-12 education uses, CodeWorld provides a web-based programming environment at http://code.world/haskell to write short snippets of Haskell and share it easily with others. I am trying to ensure that as many interesting Haskell libraries as possible are available on the platform. If you are interested in ensuring that a library is included, whether you're the maintainer or just am interested user, please take a look at the package list at https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/co… Packages that fit here are: 1. No I/O, except for stdin/out/err. Since CodeWorld runs code in a web browser, there is no filesystem, for example. 2. Do not rely on native libraries, or have dependencies that do. This all depends on the library building with GHCJS. 3. Do not require use of Template Haskell by clients. It's okay if your package needs template Haskell to build, but people using your library via CodeWorld cannot yet use TH themselves. If you have a library you'd like to see included that's not in that list, please let me know, either with just an email or with a pull request at the GitHub link above. Thanks, Chris

3 6

Generating PDF from HTML with Pandoc
by Geraldus 09 Jun '20

09 Jun '20

Hi dear Cafe! I'm trying to achieve trivial task to generate PDF from HTML template using Pandoc. So far I've tried `wkhtmltopdf` and `pdflatex` creators, both with no luck. I want to put few words about `pdflatex` and `xelatex` creators first, for someone who will struggle with same task in future, it's quite hard to find code examples on the web. Initially I wasn't able to render document with `pdflatex` creator. I would like to mention that `pdflatex` required a lot of LaTeX stuff to be installed, especially font packages. Also I've spent several hours to make rendering happen because I haven't specified template in `WriterOptions`. `pdflatex` do not capable to handle Cyrillic Unicode characters, and finally I figured out I have to use `xelatex` creator. Also I've found and used default template: > pandoc <- readHtml def (toStrict $ renderHtml html) > tpl' <- getDefaultTemplate "latex" > makePDF "xelatex" [] writeLaTeX (def {writerTemplate = Just tpl'}) pandoc But in this case I got white space instead of Cyrillic chars in resulting PDF and a bunch of warnings about missing chars in default font in console. I assume the font itself is specified in template. I've looked into default template and it's huge. I guess I can prepare more simple template for my own needs but it will take a lot of time to get familiar with LaTeX document syntax. I've tried `wkhtmltopdf`, which seems to be lightweight and easy solution. It seemed to work well except encoding issues: resulting PDF contains Cyrillic which rendered incorrectly. I've tried to pass `["encoding utf-8"]` as arguments in `makePDF` call, but this results in runtime error: > --margin-bottom specified in incorrect location Googling around this issue led me to glue that when I pass encoding argument to `wkhtmltopdf` it breaks expected arguments order in command which Pandoc generates. This is likely could be easily fixed, but Pandoc have a lot of opened issues on Github and also it requires some digging into `wkhtmltopdf` command line arguments syntax. I've looked into Pandoc sources and it seems possible to provide simple patch, but I need a guidance. According to `wkhtmltopdf` it distinguish global args, page args, cover args, table of contents args. `encoding` argument is page level argument, but Pandoc put extra args specified in `makePDF` after default page arguments (`pdfargs` in following code sample): > let args = mathArgs ++ concatMap toArgs > [("page-size", getField "papersize" meta') > ,("title", getField "title" meta') > ,("margin-bottom", Just $ fromMaybe "1.2in" > (getField "margin-bottom" meta')) > ,("margin-top", Just $ fromMaybe "1.25in" > (getField "margin-top" meta')) > ,("margin-right", Just $ fromMaybe "1.25in" > (getField "margin-right" meta')) > ,("margin-left", Just $ fromMaybe "1.25in" > (getField "margin-left" meta')) > ,("footer-html", getField "footer-html" meta') > ,("header-html", getField "header-html" meta') > ] ++ pdfargs Likely this breaks everything. The quickest and dirtiest workaround I see is to check each argument, and if it is a page level argument put it for each page object. Another solution may be to specify encoding for Pandoc document some other way, but I can't guess how to do that yet. Maybe someone have already faced similar task and knows easier way to render HTML to PDF with Haskell. I will very grateful for any help, advice or other glues how to achieve my goal. Arthur.

4 4

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

09 Jun '20

> Richard O'Keefe wrote: > This is one of the notational issues where I venture to disagree > with the Master. It's on a par with arguing that a number like > 1234 would be easier to read as 1`2`3`4 where the semantics of > x`y is x*10+y. Thanks Richard, and more to the point/dot: If dot means function application then `3.14` must be `3` applied to `14`. Or perhaps the Master expects Floats to be written European-style with commas? Good luck with that in Haskell. Let's also use Euro-style space as thousands separator! Or perhaps Dijkstra as more mathematician doesn't dirty his hands with Floats. Meta: all the above is tongue-in-cheek. AntC

1 0

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

08 Jun '20

>> On 6/5/20 7:05 AM, Anthony Clayden wrote: ... >>* Also it doesn't seem to know Haskellers very well; nor Dijkstra's *>>* well-known support for Haskell in education. *>> >>* There's other bits and pieces of 'Publications' on that the-magus site; *>>* including spoofs of Dijkstra which can't even spell his first name *>>* right. I rather suspect the ewd.pdf is a spoof that didn't turn out very *>>* funny. So altogether it's a couple of dudes shooting the breeze. * > These all seem pretty irrelevant to the point being made, which I think > has merit. (See my prev post about its lack of merit.) No Haskeller I've ever come across would accuse Dijkstra of "stick[ing] to the antiquated imperative paradigm". Dijkstra advocated teaching Haskell as an antidote to imperativism. EWD1300 is advocating for his own 'notational conventions', chiefly for writing math and formalising proofs. I don't see anything very specific to programming languages; certainly nothing specific to any paradigm. The pdf (words imputed to 'Haskeller') doesn't understand 'first-class': The term dates back to Strachey 1967; it's to do with semantics of names; what in a FP context we'd call 'referential transparency'. It has nothing to do with syntax. Column 2 of page 1 is bogus. Even if 'Haskeller' didn't know that CompSci archaeology, they'd certainly know the ($) operator. Whether or not it's the most important operator, there _is_ an operator and it is first-class. 'Haskeller' gets several answers wrong at the top of p2; finally gets to $ and gets that wrong too: EWD's question re `length $ [] = 0` is not a way to define `length`. Any Haskell beginner could stick that into an actual Haskell compiler and see why. Towards the bottom of p2 EWD admits "I do not know your Haskell very well ...". I'd say this faux-Haskeller knows Haskell less well than faux-EWD. Just before that admission is another piece of bogus notation for operator sections of `x * y`. None of that appears in EWD1300. > This is all just a language design curiosity to me, though, > and I'm not looking to start a new religious war until some of the > present ones are resolved. Well, don't look for pointers to language design from the couple of jokers portrayed in that pdf. I find it actually insulting to the good sense the real Dijkstra always showed; and insulting to Haskellers -- what's with all this gratuitous imputing of emotion? What's with just getting Haskell wrong? It's easy to check those claims; it's easy to get the (alleged) 'thought' peer-reviewed from the Haskell community. AntC

6 7