From vanessa.mchale at iohk.io Mon Apr 1 15:25:36 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Mon, 1 Apr 2019 10:25:36 -0500 Subject: [Haskell-cafe] Generating tagfiles for Vim Message-ID: Hi all, I had been using hasktags for tag generation previously, however, I recently discovered that using GHCi with cabal new-repl λ:> :ctags creates a tags file that actually works with preprocessors (e.g. c2hs or alex or happy). Is there any way to run this semi-automatically? echo ':ctags' | cabal new-repl seems to work in the shell, but I'd like a vim integration if possible (also, it's slow). Cheers, Vanessa McHale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From nathanmerkley at gmail.com Mon Apr 1 15:56:20 2019 From: nathanmerkley at gmail.com (Nathan Merkley) Date: Mon, 1 Apr 2019 09:56:20 -0600 Subject: [Haskell-cafe] Generating tagfiles for Vim In-Reply-To: References: Message-ID: While there is probably a better way, my limited knowledge of vimscript had me write this and it works well enough function! UpdateHaskellTags() if filereadable("tags") execute "silent !grep -v '" . bufname("%") . "' ./tags > __newtags" execute "silent !rm tags" execute "silent !mv __newtags tags" execute "silent !fast-tags " . bufname("%") endif endfunction autocmd BufWritePost *.hs :call UpdateHaskellTags() autocmd BufWritePost *.hsc :call UpdateHaskellTags() This uses fast-tags to regenerate tags for the current file on every save, but will only work if you are operating from the root of your project (or wherever you keep your tags). I use ctrlp for navigation so that's never been a problem for me Nathan Merkley On Mon, Apr 1, 2019 at 9:26 AM Vanessa McHale wrote: > Hi all, > > I had been using hasktags for tag generation previously, however, I > recently discovered that using GHCi with > > cabal new-repl > λ:> :ctags > > creates a tags file that actually works with preprocessors (e.g. c2hs or > alex or happy). > > Is there any way to run this semi-automatically? > > echo ':ctags' | cabal new-repl > > seems to work in the shell, but I'd like a vim integration if possible > (also, it's slow). > > Cheers, > Vanessa McHale > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From foxbenjaminfox at gmail.com Mon Apr 1 18:00:23 2019 From: foxbenjaminfox at gmail.com (Benjamin Fox) Date: Mon, 1 Apr 2019 20:00:23 +0200 Subject: [Haskell-cafe] Generating tagfiles for Vim In-Reply-To: References: Message-ID: Here is a very useful bash script to have lying around: #!/usr/bin/env bash shopt -s nullglob while true; do if [[ "$PWD" == "$HOME" || "$PWD" == / || -f "$PWD/package.yaml" || -f "$PWD/stack.yaml" || -n "$(echo -n ./*.cabal)" ]]; then exec "$@" else cd .. fi done Name this something like "run-in-project-root", and then you can prefix any command you run with "run-in-project-root" in order for it to run in the project's root, as defined by the existence of a package.yaml or stack.yaml or *.cabal file. (Of course you can customize the exact condition to your tastes.) So running "run-in-project-root fast-tags filename" is exactly like running "fast-tags filename" except that fast-tags will execute in the project root. (And the same for all the other shell commands that you run.) Of course, this works both when running fast-tags (or any other command) directly in the shell, and when running a bash snippet in vim with :!, so long as the "run-in-project-root" script is in a directory that's in your $PATH. On Mon, Apr 1, 2019 at 5:56 PM Nathan Merkley wrote: > While there is probably a better way, my limited knowledge of vimscript > had me write this and it works well enough > > > function! UpdateHaskellTags() > if filereadable("tags") > execute "silent !grep -v '" . bufname("%") . "' ./tags > __newtags" > execute "silent !rm tags" > execute "silent !mv __newtags tags" > execute "silent !fast-tags " . bufname("%") > endif > endfunction > > autocmd BufWritePost *.hs :call UpdateHaskellTags() > autocmd BufWritePost *.hsc :call UpdateHaskellTags() > > > This uses fast-tags to regenerate tags for the current file on every save, > but will only work if you are operating from the root of your project (or > wherever you keep your tags). I use ctrlp for navigation so that's never > been a problem for me > > Nathan Merkley > > On Mon, Apr 1, 2019 at 9:26 AM Vanessa McHale > wrote: > >> Hi all, >> >> I had been using hasktags for tag generation previously, however, I >> recently discovered that using GHCi with >> >> cabal new-repl >> λ:> :ctags >> >> creates a tags file that actually works with preprocessors (e.g. c2hs or >> alex or happy). >> >> Is there any way to run this semi-automatically? >> >> echo ':ctags' | cabal new-repl >> >> seems to work in the shell, but I'd like a vim integration if possible >> (also, it's slow). >> >> Cheers, >> Vanessa McHale >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa.mchale at iohk.io Mon Apr 1 18:09:37 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Mon, 1 Apr 2019 13:09:37 -0500 Subject: [Haskell-cafe] Generating tagfiles for Vim In-Reply-To: References: Message-ID: <0ac501f6-9956-e09a-9320-097bf005fee0@iohk.io> Unfortunately, fast-tags doesn't work with happy/alex/c2hs preprocessors :( Cheers On 4/1/19 10:56 AM, Nathan Merkley wrote: > While there is probably a better way, my limited knowledge of > vimscript had me write this and it works well enough > > > function! UpdateHaskellTags() >     if filereadable("tags") >         execute "silent !grep -v '" . bufname("%") . "' ./tags > > __newtags" >         execute "silent !rm tags" >         execute "silent !mv __newtags tags" >         execute "silent !fast-tags " . bufname("%") >     endif > endfunction > > autocmd BufWritePost *.hs :call UpdateHaskellTags() > autocmd BufWritePost *.hsc :call UpdateHaskellTags() > > > This uses fast-tags to regenerate tags for the current file on every > save, but will only work if you are operating from the root of your > project (or wherever you keep your tags). I use ctrlp for navigation > so that's never been a problem for me > > Nathan Merkley > > On Mon, Apr 1, 2019 at 9:26 AM Vanessa McHale > wrote: > > Hi all, > > I had been using hasktags for tag generation previously, however, I > recently discovered that using GHCi with > > cabal new-repl > λ:> :ctags > > creates a tags file that actually works with preprocessors (e.g. > c2hs or > alex or happy). > > Is there any way to run this semi-automatically? > > echo ':ctags' | cabal new-repl > > seems to work in the shell, but I'd like a vim integration if possible > (also, it's slow). > > Cheers, > Vanessa McHale > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From nathanmerkley at gmail.com Mon Apr 1 18:19:47 2019 From: nathanmerkley at gmail.com (Nathan Merkley) Date: Mon, 1 Apr 2019 12:19:47 -0600 Subject: [Haskell-cafe] Generating tagfiles for Vim In-Reply-To: <0ac501f6-9956-e09a-9320-097bf005fee0@iohk.io> References: <0ac501f6-9956-e09a-9320-097bf005fee0@iohk.io> Message-ID: Benjamin, Thanks for that, that should come in very handy Vanessa, While I haven't tried it, you should be able to replace fast-tags with any tool of your choice, as the script is just running a sequence of shell commands. The one caveat is that the script I sent generates tags on a per-file basis, so if generating them from the repl doesn't merge the tags file, you will have to change it to instead generate tags for the entire project directory Nathan Merkley On Mon, Apr 1, 2019, 12:10 PM Vanessa McHale wrote: > Unfortunately, fast-tags doesn't work with happy/alex/c2hs preprocessors :( > > Cheers > On 4/1/19 10:56 AM, Nathan Merkley wrote: > > While there is probably a better way, my limited knowledge of vimscript > had me write this and it works well enough > > > function! UpdateHaskellTags() > if filereadable("tags") > execute "silent !grep -v '" . bufname("%") . "' ./tags > __newtags" > execute "silent !rm tags" > execute "silent !mv __newtags tags" > execute "silent !fast-tags " . bufname("%") > endif > endfunction > > autocmd BufWritePost *.hs :call UpdateHaskellTags() > autocmd BufWritePost *.hsc :call UpdateHaskellTags() > > > This uses fast-tags to regenerate tags for the current file on every save, > but will only work if you are operating from the root of your project (or > wherever you keep your tags). I use ctrlp for navigation so that's never > been a problem for me > > Nathan Merkley > > On Mon, Apr 1, 2019 at 9:26 AM Vanessa McHale > wrote: > >> Hi all, >> >> I had been using hasktags for tag generation previously, however, I >> recently discovered that using GHCi with >> >> cabal new-repl >> λ:> :ctags >> >> creates a tags file that actually works with preprocessors (e.g. c2hs or >> alex or happy). >> >> Is there any way to run this semi-automatically? >> >> echo ':ctags' | cabal new-repl >> >> seems to work in the shell, but I'd like a vim integration if possible >> (also, it's slow). >> >> Cheers, >> Vanessa McHale >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Tue Apr 2 05:06:14 2019 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 1 Apr 2019 22:06:14 -0700 Subject: [Haskell-cafe] Generating tagfiles for Vim In-Reply-To: References: Message-ID: On Mon, Apr 1, 2019 at 8:56 AM Nathan Merkley wrote: > > While there is probably a better way, my limited knowledge of vimscript had me write this and it works well enough > > function! UpdateHaskellTags() > if filereadable("tags") > execute "silent !grep -v '" . bufname("%") . "' ./tags > __newtags" > execute "silent !rm tags" > execute "silent !mv __newtags tags" > execute "silent !fast-tags " . bufname("%") > endif > endfunction > > autocmd BufWritePost *.hs :call UpdateHaskellTags() > autocmd BufWritePost *.hsc :call UpdateHaskellTags() If I'm reading it right, this goes to a lot of work to defeat (or reimplement?) the default incremental tagging. Why not just 'execute fast-tags %'? I use a script like "if [[ -r tags ]]; then fast-tags -R; else fast-tags $1; fi" for that first generate, and put 'rm tags' in the merge posthook. From qdunkan at gmail.com Tue Apr 2 05:14:48 2019 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 1 Apr 2019 22:14:48 -0700 Subject: [Haskell-cafe] Generating tagfiles for Vim In-Reply-To: <0ac501f6-9956-e09a-9320-097bf005fee0@iohk.io> References: <0ac501f6-9956-e09a-9320-097bf005fee0@iohk.io> Message-ID: On Mon, Apr 1, 2019 at 11:09 AM Vanessa McHale wrote: > > Unfortunately, fast-tags doesn't work with happy/alex/c2hs preprocessors :( Oh I guess it doesn't. Support wouldn't be hard to add though, I think it just needs to understand LINE pragmas. Then you'd have to do some editor hackery to get it to run on the generated output when you edit the source file, e.g. if expand('%') =~ *.chs; then "fast-tags build/chs/" + expand('%'); else ... Substitute build/chs/ for wherever your build puts the generated .hs files of course. Add a feature request if you think you'd use such a feature. Also note that fast-tags directly supports cabal files, I do a `fast-tags --cabal **/*.cabal` on a hackage snapshot to get tags for all of hackage and ghc, and then make that be the secondary tags file, so I can jump to any definition, internal or external. From DekuDekuplex at Yahoo.com Tue Apr 2 06:11:03 2019 From: DekuDekuplex at Yahoo.com (Benjamin L. Russell) Date: Tue, 02 Apr 2019 15:11:03 +0900 Subject: [Haskell-cafe] ANN: Haskell Beginners Google+ Community: "Haskell: The Haskell-Beginners Community" Message-ID: Since the Google+ social network service is scheduled to be "sunset" (i.e., put out of service) on April 2, 2019, I have created a new Haskell beginners PASHpost community, "Haskell: The Haskell-Beginners Community" (see https://pashpost.com/group/haskell-the-haskell-beginners-community), and migrated a substantial portion of the original posts thereto (sans posts with missing links or irrelevant content). Feel free to join and contribute! -- Benjamin L. Russell From b at chreekat.net Tue Apr 2 06:54:39 2019 From: b at chreekat.net (Bryan Richter) Date: Tue, 2 Apr 2019 09:54:39 +0300 Subject: [Haskell-cafe] [ANN] Haskell.Org Discourse Instance In-Reply-To: <20190222132711.GA10545@kakigori> References: <20190222132711.GA10545@kakigori> Message-ID: [I drafted this when the announcement was made. Activity on Discourse has been growing slowly, so I thought I'd go ahead and post it now.] I think this is great. I've been part of a few of the mentioned communities that transitioned to Discourse, and a few others as well. The most positive change has been the increase in community participation. As someone initially more comfortable with Mailman mailing lists, I empathize with people who have strong email workflows. Moving to Discourse isn't painless. (There is a "mailing list mode", which helps some, but not entirely.) A web UI has some downsides compared to text, for those so inclined. But there are upsides as well. Threads are more isolated from each other, and are effectively dynamically-created mini-mailing lists. You can edit your posts, removing typos or clarifying points.[1] Worrying about top posting becomes obsolete. (I recognize the irony here, but I am on mobile, so....) But like I said, the biggest upside is improved community participation. As an anecdote, I know people who cared deeply about a particular project, but never felt comfortable enough with the mailing list interface to chime in. Forums, for whatever combination of reasons, are more approachable. (I even feel this myself, which is perhaps why the anecdote resonates with me.) Plus, Discourse provides richer means of communication through reactions, and it is better equipped to facilitate moderation and disputes.[2] I'm not sure what prompted me to write this fawning email, except that I wrote a very similar one when Nix started their trial, and now they've switched away from their mailing list completely and everything seems to be going quite well. I encourage people to give Discourse a go! P.s. Discourse would never replace all means of communication, but it could potentially replace all discussion-based mailing lists. [1]: The ability to edit posts can also be abused, but in practice this rarely happens. [2]: Moderation can also be abused, but its absence is more frequently the problem! On Fri, 22 Feb 2019, 15.27 Jasper Van der Jeugt, wrote: > Hello all, > > We would like to announce a new discourse-based forum for the Haskell > community, at: > > https://discourse.haskell.org/ > > This is inspired by the Rust, Nix and Elm discourse instances, where > these forums have had a strong positive effect on the community. We will > run this as a "beta" for 6 months and then evaluate its usefulness. It > is meant as an extra alternative to Haskell-cafe, reddit and Haskell > IRC, but it does not replace any of those. > > Discourse is completely open source and easily accessible using an email > client. We would like to thank the Haskell.Org admin team for > provisioning a server and Matthew Pickering for suggesting this and > doing the hard work setting up the instance. > > Warm regards, > Jasper Van der Jeugt > on behalf of the Haskell.Org Committee > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Wed Apr 3 09:48:04 2019 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Wed, 3 Apr 2019 09:48:04 +0000 Subject: [Haskell-cafe] MPC 2019 final call for papers - submissions due 3rd May Message-ID: <5A6933BE-352F-464B-AE5C-3DAD89A3BB7B@exmail.nottingham.ac.uk> ====================================================================== *** FINAL CALL FOR PAPERS -- MPC 2019 *** 13th International Conference on Mathematics of Program Construction 7-9 October 2019, Porto, Portugal Co-located with Formal Methods 2019 https://tinyurl.com/MPC-Porto ====================================================================== TIMELINE: Abstract submission 26th April 2019 Paper submission 3rd May 2019 Author notification 14th June 2019 Camera ready copy 12th July 2019 Conference 7-9 October 2019 KEYNOTE SPEAKERS: Assia Mahboubi INRIA, France Annabelle McIver Macquarie University, Australia BACKGROUND: The International Conference on Mathematics of Program Construction (MPC) aims to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs. MPC 2019 will be held in Porto, Portugal from 7-9 October 2019, and is co-located with the International Symposium on Formal Methods, FM 2019. Previous conferences were held in Königswinter, Germany (2015); Madrid, Spain (2012); Québec City, Canada (2010); Marseille, France (2008); Kuressaare, Estonia (2006); Stirling, UK (2004); Dagstuhl, Germany (2002); Ponte de Lima, Portugal (2000); Marstrand, Sweden (1998); Kloster Irsee, Germany (1995); Oxford, UK (1992); Twente, The Netherlands (1989). SCOPE: MPC seeks original papers on mathematical methods and tools put to use in program construction. Topics of interest range from algorithmics to support for program construction in programming languages and systems. Typical areas include type systems, program analysis and transformation, programming language semantics, security, and program logics. The notion of a 'program' is interpreted broadly, ranging from algorithms to hardware. Theoretical contributions are welcome, provided that their relevance to program construction is clear. Reports on applications are welcome, provided that their mathematical basis is evident. We also encourage the submission of 'programming pearls' that present elegant and instructive examples of the mathematics of program construction. SUBMISSION: Submission is in two stages. Abstracts (plain text, maximum 250 words) must be submitted by 26th April 2019. Full papers (pdf, formatted using the llncs.sty style file for LaTex) must be submitted by 3rd May 2019. There is no prescribed page limit, but authors should strive for brevity. Both abstracts and papers will be submitted using EasyChair. Papers must present previously unpublished work, and not be submitted concurrently to any other publication venue. Submissions will be evaluated by the program committee according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. Accepted papers must be presented in person at the conference by one of the authors. The proceedings of MPC 2019 will be published in the Lecture Notes in Computer Science (LNCS) series, as with all previous instances of the conference. Authors of accepted papers will be expected to transfer copyright to Springer for this purpose. After the conference, authors of the best papers from MPC 2019 and MPC 2015 will be invited to submit revised versions to a special issue of Science of Computer Programming (SCP). For any queries about submission please contact the program chair, Graham Hutton . PROGRAM COMMITTEE: Patrick Bahr IT University of Copenhagen, Denmark Richard Bird University of Oxford, UK Corina Cîrstea University of Southampton, UK Brijesh Dongol University of Surrey, UK João F. Ferreira University of Lisbon, Portugal Jennifer Hackett University of Nottingham, UK William Harrison University of Missouri, USA Ralf Hinze University of Kaiserslautern, Germany Zhenjiang Hu National Institute of Informatics, Japan Graham Hutton (chair) University of Nottingham, UK Cezar Ionescu University of Oxford, UK Mauro Jaskelioff National University of Rosario, Argentina Ranjit Jhala University of California, USA Gabriele Keller Utrecht University, The Netherlands Ekaterina Komendantskaya Heriot-Watt University, UK Chris Martens North Carolina State University, USA Bernhard Möller University of Augsburg, Germany Shin-Cheng Mu Academia Sinica, Taiwan Mary Sheeran Chalmers University of Technology, Sweden Alexandra Silva University College London, UK Georg Struth University of Sheffield, UK CONFERENE VENUE: The conference will be held at the Alfândega Porto Congress Centre, a 150 year old former custom's house located in the historic centre of Porto on the bank of the river Douro. The venue was renovated by a Pritzer prize winning architect and has received many awards. LOCAL ORGANISERS: José Nuno Oliveira University of Minho, Portugal For any queries about local issues please contact the local organiser, José Nuno Oliveira . ====================================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From cdsmith at gmail.com Wed Apr 3 20:19:15 2019 From: cdsmith at gmail.com (Chris Smith) Date: Wed, 3 Apr 2019 16:19:15 -0400 Subject: [Haskell-cafe] Feedback on plan for checking code requirements in a GHC plugin In-Reply-To: References: Message-ID: I'm reviving this old thread, because I am talking to a student who is interested in working on this as a project for Google Summer of Code. I'm happy to be a mentor, but this student could use another mentor who could help with GHC internals for building a GHC plugin. The project would be to implement a domain-specific language for giving assignment or exercise requirements for Haskell programs, and a GHC plugin that allows the code to be run in a mode that validates those requirements. The plugin would inject code into the resulting program for running in validation mode to do the checks. Sometimes, the rules are about the source code -- e.g., "every top-level definition must be accompanied by a type signature", or "no lines longer than 80 characters", or "the program must use a list comprehension" -- in which case the plugin would look at the source code or AST at build time, check assertions about what's there, and inject trivial code to report the result when the program is run. Other times, rules could be about runtime properties or behavior, in which case the injected code would actually run tests to validate the behavior. If anyone is interested in mentoring a student working on this project, please contact me and I'll pass along the info. (I cannot post the student's details publicly, because Summer of Code proposals aren't supposed to be public at this stage, but I can forward responses directly to the student involved.) Thanks, Chris On Wed, Nov 21, 2018 at 12:04 PM Matthew Pickering < matthewtpickering at gmail.com> wrote: > Nothing to add other than this sounds just like the sort of thing that > will be easy to implement as a source plugin. > > You might find my plugins resource page useful: > http://mpickering.github.io/plugins.html > > In particular, this post about how to construct expressions: > http://mpickering.github.io/posts/2018-06-11-source-plugins.html > > Cheers, > > Matt > On Tue, Nov 20, 2018 at 6:47 PM Chris Smith wrote: > > > > Hey everyone, > > > > I'm converging on a design for a new feature of CodeWorld, the > Haskell-based educational programming environment that I teach with. I'm > wondering if anyone has done something like this before. > > > > The goal is that when I give an assignment in a class (e.g., "modify > this starting code to generalize the repeated pattern using a function"), I > want the user to see a checklist of assignment requirements when they run > the code. A prototype implementation is here: > https://code.world/haskell#PpwpTF1wv3qIvwhohCfvSrQ > > > > There are all sorts of possible requirements, such as: "No lines longer > than 80 characters", or "there must be a function called foo", or "all > top-level definitions must have type signatures", or "your code must define > at least 10 top-level variables, and use at least 3 where clauses", or > "your definition of var should be equivalent to this one" (see Joachim > Breitner's inspection testing work), or even "the function f must satisfy > this QuickCheck property". It's been suggested that the requirements > language also include the ability to match patterns in the AST, which I > think is a good idea. > > > > The current prototype uses a pre-compile step that parses the code using > haskell-src-exts, and doesn't implement dynamic requirements > (runtime-evaluated) at all. My ultimate plan, though, is to send these > requirements to GHC via a plugin, then have it evaluate the static ones at > compile time, and generate code to check the dynamic ones. Finally, the > plugin would add new code to the beginning of main that will invoke a > configurable function with the results of the requirement check > (hard-coding the static ones, and evaluating dynamic ones on the fly). (In > the CodeWorld environment, this function would display the checklist in the > web UI, for example.) > > > > Has anyone done anything like this before? Any wisdom to share, or > ideas to contribute? > > > > Thanks, > > Chris > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at ara.io Thu Apr 4 11:50:04 2019 From: me at ara.io (Ara Adkins) Date: Thu, 4 Apr 2019 12:50:04 +0100 Subject: [Haskell-cafe] Hackage Down Message-ID: Is anybody else unable to access Hackage? I'm seeing a 502 bad gateway. _ara From jeroen at chordify.net Thu Apr 4 11:56:41 2019 From: jeroen at chordify.net (Jeroen Bransen) Date: Thu, 4 Apr 2019 13:56:41 +0200 Subject: [Haskell-cafe] Hackage Down In-Reply-To: References: Message-ID: <1d524722-87f4-7d0d-d973-b55da50e1dc3@chordify.net> Yes, there is a problem, see https://status.haskell.org/ > Is anybody else unable to access Hackage? I'm seeing a 502 bad gateway. > > _ara > _______________________________________________ > 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. From me at ara.io Thu Apr 4 11:58:03 2019 From: me at ara.io (Ara Adkins) Date: Thu, 4 Apr 2019 12:58:03 +0100 Subject: [Haskell-cafe] Hackage Down In-Reply-To: <1d524722-87f4-7d0d-d973-b55da50e1dc3@chordify.net> References: <1d524722-87f4-7d0d-d973-b55da50e1dc3@chordify.net> Message-ID: Thanks! Entirely forgot there was a status page. On Thu, 4 Apr 2019 at 12:57, Jeroen Bransen wrote: > > Yes, there is a problem, see https://status.haskell.org/ > > > Is anybody else unable to access Hackage? I'm seeing a 502 bad gateway. > > > > _ara > > _______________________________________________ > > 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. From fis at etc-network.de Fri Apr 5 10:16:10 2019 From: fis at etc-network.de (Matthias Fischmann) Date: Fri, 5 Apr 2019 12:16:10 +0200 Subject: [Haskell-cafe] Call for Contributions: Summer BOB 2019 [Aug 21, Berlin, deadline May 17] Message-ID: <20190405101610.3iwndgn6uakkjynx@localhost.localdomain> [Online version of this email: https://bobkonf.de/2019-summer/cfc.html] Summer BOB Conference 2019 "What happens when we use what's best for a change?" http://bobkonf.de/2019-summer/cfc.html Berlin, August 21 co-located with ICFP 2019 Call for Contributions Deadline: May 17, 2019 You are engaged in software development or software architecture, and have an interesting story to tell about an advanced tools, technique, language or technology that you're using? Or a gnarly problems that these tools fail to address but should? Summer BOB is a one-time-only event, in the spirit of the spectacular Winter BOB. The International Conference on Functional Programming is coming to town, and Summer BOB will be right in the middle of it, on the last day of ICFP proper, prior to all the workshops. Summer BOB will feature two tracks: one from practitioners, and one from researchers, and foster communication and cross-pollination between these communities. If you share our vision and want to contribute, submit a proposal for a talk! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - … everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. We're especially interested in experience reports. Other topics are also relevant, e.g.: - demos and how-tos - reports on problems that cutting-edge languages and tools should address but don't - overviews of a given field Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) - Don't be confused: The system calls a submission event. Submit here ----------- https://bobcfc.active-group.de/bob2019-summer/cfp Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Shepherding The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: May 17, 2019 - Notification: May 31, 2019 - Program: June 14, 2019 Program Committee ----------------- - Matthias Fischmann, zerobuzz UG - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg More information here: http://bobkonf.de/2019-summer/programmkomitee.html From michelhaber1994 at gmail.com Fri Apr 5 15:19:00 2019 From: michelhaber1994 at gmail.com (Michel Haber) Date: Fri, 5 Apr 2019 17:19:00 +0200 Subject: [Haskell-cafe] GHC extensions Message-ID: Hello Cafe, So I've been learning a bit about the GHC extensions from https://github.com/i-am-tom/haskell-exercises. But the lessons say nothing about how the extensions work behind the scenes. For example, I've assumed that RankNTypes would require something similar to dynamic dispatch in imperative languages in order to work. But this is just an assumption. So I was wondering where I can get a quick succinct read (or a summary at least) about how these extensions are implemented, as well as their performance cost (or gain!). Also if someone knows other tutorials and lessons for these, and other extensions, please feel free to share them :p Thank you, Michel :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa.mchale at iohk.io Fri Apr 5 16:06:43 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Fri, 5 Apr 2019 11:06:43 -0500 Subject: [Haskell-cafe] GHC extensions In-Reply-To: References: Message-ID: <27a306b7-9820-dc11-c0e0-56bad0247ef7@iohk.io> I would not expect type system extensions to have any effect on the performance of generated code. Cheers, Vanessa McHale On 4/5/19 10:19 AM, Michel Haber wrote: > Hello Cafe, > > So I've been learning a bit about the GHC extensions from > https://github.com/i-am-tom/haskell-exercises. But the lessons say > nothing about how the extensions work behind the scenes. > > For example, I've assumed that RankNTypes would require something > similar to dynamic dispatch in imperative languages in order to work. > But this is just an assumption. > > So I was wondering where I can get a quick succinct read (or a summary > at least) about how these extensions are implemented, as well as their > performance cost (or gain!). > > Also if someone knows other tutorials and lessons for these, and other > extensions, please feel free to share them :p > > Thank you, > Michel :) > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From webyrd at gmail.com Fri Apr 5 20:02:33 2019 From: webyrd at gmail.com (William Byrd) Date: Fri, 5 Apr 2019 15:02:33 -0500 Subject: [Haskell-cafe] Call for Contributions--First miniKanren and Relational Programming Workshop Message-ID: DEADLINE: 15 May 2019, (Any time in the world) WEBSITE: https://icfp19.sigplan.org/home/minikanren-2019 LOCATION: Berlin, Germany (co-located with ICFP) DATE: 22 August 2019 The 2019 First miniKanren and Relational Programming Workshop is calling for submissions. Full papers are due 15 May 2019. Authors will be notified by 15 June 2019. Camera-ready versions are due 30 June 2019. All deadlines are (23:59 UTC-12), "Anywhere on Earth". The miniKanren and Relational Programming Workshop is a new workshop for the miniKanren family of relational (pure constraint logic programming) languages: miniKanren, microKanren, core.logic, OCanren, Guanxi, etc. The workshop solicits papers and talks on the design, implementation, and application of miniKanren-like languages. A major goal of the workshop is to bring together researchers, implementors, and users from the miniKanren community, and to share expertise and techniques for relational programming. Another goal for the workshop is to push the state of the art of relational programming---for example, by developing new techniques for writing interpreters, type inferencers, theorem provers, abstract interpreters, CAD tools, and other interesting programs as relations, which are capable of being "run backwards," performing synthesis, etc. Submission Information Submission Page: https://minikanren19.hotcrp.com/ Paper submissions must use the format acmart and its sub-format acmlarge. They must be in PDF, printable in black and white on US Letter size. Microsoft Word and LaTeX templates for this format are available at: http://www.sigplan.org/Resources/Author/ As this is the first iteration of the workshop, we want to encourage all kinds of submissions. We expect short papers as well as longer papers. As a rough guideline, with the new ACM format a short paper would be 2 to 7 pages and a long paper 8 to 25 pages. Authors are encouraged to publish any code associated to their papers under an open source license, so that reviewers may try the code and verify the claims. Proceedings will be printed as a Technical Report at Harvard University. Publication of a paper at this workshop is not intended to replace conference or journal publication, and does not preclude re-publication of a more complete or finished version of the paper at some later conference or in a journal. Sincerely, William E. Byrd, General Chair Nada Amin, Program Committee Chair Program Committee: Claire Alvis, Sparkfund Tom Gilray, University of Alabama, Birmingham Jason Hemann, Northeastern University Eric Holk, Google Kanae Tsushima, National Institute of Informatics From michelhaber1994 at gmail.com Sun Apr 7 20:40:20 2019 From: michelhaber1994 at gmail.com (Michel Haber) Date: Sun, 7 Apr 2019 22:40:20 +0200 Subject: [Haskell-cafe] GHC extensions In-Reply-To: <27a306b7-9820-dc11-c0e0-56bad0247ef7@iohk.io> References: <27a306b7-9820-dc11-c0e0-56bad0247ef7@iohk.io> Message-ID: Hello, Thanks for your answer Vanessa. So you wouldn't say that, for instance, some of these extensions might provide room for more extensive optimizations, seeing as they provide stronger guarantees (Non empty vectors and such) ? Michel :) On Fri, Apr 5, 2019 at 6:07 PM Vanessa McHale wrote: > I would not expect type system extensions to have any effect on the > performance of generated code. > > Cheers, > Vanessa McHale > On 4/5/19 10:19 AM, Michel Haber wrote: > > Hello Cafe, > > So I've been learning a bit about the GHC extensions from > https://github.com/i-am-tom/haskell-exercises. But the lessons say > nothing about how the extensions work behind the scenes. > > For example, I've assumed that RankNTypes would require something similar > to dynamic dispatch in imperative languages in order to work. But this is > just an assumption. > > So I was wondering where I can get a quick succinct read (or a summary at > least) about how these extensions are implemented, as well as their > performance cost (or gain!). > > Also if someone knows other tutorials and lessons for these, and other > extensions, please feel free to share them :p > > Thank you, > Michel :) > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Mon Apr 8 00:49:03 2019 From: qdunkan at gmail.com (Evan Laforge) Date: Sun, 7 Apr 2019 17:49:03 -0700 Subject: [Haskell-cafe] streaming with logs / metadata Message-ID: I have a pattern that's come up several times, and I'm wondering if there's a name for it, or a better way to do it. It has to do with processing streams, which in the presence of laziness and the absence of effects can be done with just lists. For instance, imagine a parser that produces [Token], then various processing stages that go [Token] -> [x], [x] -> [y], [y] -> [Output]. If I have a transform function that works on a single element 1:1 and is stateless, then I can express it with 'map'. If it needs simple state, then I can switch 'map' for 'mapAccumL', which is just a specialization of the State monad. If it needs to know the next element, I can compose a 'zipNext' (zip xs (drop 1 xs)) on the front. If it returns multiple elements, there's concatMap, and of course mapM for arbitrary monads. Now suppose it needs warnings, or logging, so to preserve streaming I wind up with '[Either e a] -> [Either e b]'. I still want to do all the same stuff, but factor out the Lefts so I don't have to be explicitly passing through all the time. So I start reimplementing the usual list functions: module E where map :: (a -> b) -> [Either e a] -> [Either e b] mapE :: (a -> Either e b) -> [Either e a] -> [Either e b] concatMap :: (a -> [b]) -> [Either e a] -> [Either e b] concatMapE :: (a -> [Either e b]) -> [Either e a] -> [Either e b] mapAccumL :: (state -> a -> (state, Either e b)) -> state -> [Either e a] -> (state, [Either e b]) And of course the monadic / applicative variants: mapM :: Applicative m => (a -> m b) -> [Either e a] -> [Either e b] mapEM :: Monad m => (a -> m (Either e b)) -> [Either e a] -> m [Either e b] ... etc. But to deal with supplying extra state, or looking into the future or filtering I have to reinvent those too: zip :: [a] -> [Either e b] -> [Either e (a, b)] zip{2,3,4,...} :: ... zipNexts :: [Either e a] -> [Either e (a, [a])] filter :: (a -> Bool) -> [Either e a] -> [Either e a] The zips become asymmetrical, but they're in service of a common pattern which I'm not sure how to describe, but is used to get the Lefts out of the way. E.g. if a duration can be derived from a Right value, to annotate Rights with start times: 'E.zip (scanl (+) 0 (map durationOf (Either.rights xs))) xs'. It's a bit unsatisfying because it relies on the transformation preserving 1:1 with its input, or at least new elements are added only at the end and I can ignore them. 'scanl . map' happens to have this property, but it's not obvious or guaranteed. My questions are, is this a known pattern? Is there an implementation on hackage, or at least a good thing to call it? And then, is there a a way to construct these functions systematically, or to compose them from smaller parts? The 1:1 stateless ones like 'map' and 'mapM' work out nicely because they're just 'fmap . fmap' or 'traverse . traverse', and I can implement 'concatMapM' and then implement a lot of other kinds of maps as specializations, though efficiency may suffer. But for the zips and filters and takeWhiles I wind up just rewriting the recursion. They feel ad-hoc and unsatisfying, that if I were more clever I would figure out how to abstract out the Lefts in one spot, once and for all. There is a general way to get all of the '[a] -> [b]' functions into '[Either e a] -> [Either e b]', and that's to partitionsEithers, apply second, then concat, but of course it spoils streaming and is inefficient if there are lots of Lefts. Still, it's the only way I can think of to get those Lefts out of the picture in a modular way. Using a Writer I think is equivalent. There's a similar problem with being able factor out annotations, similar to the way I want to factor out logs / warnings / other metadata above. E.g. if we have '[(annot, a)] -> [(annot, b)]' then we start with a simple fmap.fmap, but any more complicated transforms means you either have to intersperse the "ignore annotation" logic and clutter things up with 'snd's and 'second's everywhere, or come up with a whole new map filter zip toolkit. From frase at frase.id.au Mon Apr 8 04:30:32 2019 From: frase at frase.id.au (Fraser Tweedale) Date: Mon, 8 Apr 2019 14:30:32 +1000 Subject: [Haskell-cafe] Package takeover intent - dyre Message-ID: <20190408043032.GB4718@bacardi.hollandpark.frase.id.au> The dyre[1] package is unmaintained for 5 years. I would like to contribute to it or take over maintainership, but have been unable to contact the maintainer (Cc'd). Pursuant to wiki[2] I am announcing my intention to take over the package. [1] https://hackage.haskell.org/package/dyre [2] https://wiki.haskell.org/Taking_over_a_package Thanks, Fraser From mlang at delysid.org Mon Apr 8 08:50:49 2019 From: mlang at delysid.org (Mario Lang) Date: Mon, 08 Apr 2019 10:50:49 +0200 Subject: [Haskell-cafe] [ANN] Haskell.Org Discourse Instance In-Reply-To: (Bryan Richter's message of "Tue, 2 Apr 2019 09:54:39 +0300") References: <20190222132711.GA10545@kakigori> Message-ID: <87k1g498ye.fsf@fx.blind.guru> Bryan Richter writes: > As someone initially more comfortable with Mailman mailing lists, I > empathize with people who have strong email workflows. Moving to Discourse > isn't painless. (There is a "mailing list mode", which helps some, but not > entirely.) A web UI has some downsides compared to text, for those so > inclined. In particular, web UIs are everything else but accessibility friendly. Every project that moves away from mailing lists and IRC effectively maks it pretty hard for people which rely on accessibility to participate. I am not expecting this to hold anyone back from moving into the shining new era of client-less communication. Just wanted to point out that people like me are going to be left behind. -- CYa, ⡍⠁⠗⠊⠕ From johannes.waldmann at htwk-leipzig.de Mon Apr 8 13:00:54 2019 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Mon, 8 Apr 2019 15:00:54 +0200 Subject: [Haskell-cafe] looking for yesod-auth example with LTS-13 Message-ID: Dear Cafe, I am trying to update some legacy code, and I have trouble getting yesod-auth to work under LTS-13. It worked with LTS-10. I think the error in this demonstration project (not mine) is related to what I am seeing: https://github.com/TobyGoodwin/auth38/issues/1 My actual code (and error message) is here https://gitlab.imn.htwk-leipzig.de/autotool/all0/issues/565 but "auth38" is certainly easier to reproduce. I was unable to apply this idea: https://stackoverflow.com/questions/23188494/yesod-subsites-and-forms/29394453#29394453 (which seems dated - the HandlerT type is gone?) Any ideas? Thanks - J.W. From michaelpj at gmail.com Mon Apr 8 13:11:52 2019 From: michaelpj at gmail.com (Michael Peyton Jones) Date: Mon, 8 Apr 2019 14:11:52 +0100 Subject: [Haskell-cafe] [ANN] Haskell.Org Discourse Instance In-Reply-To: <87k1g498ye.fsf@fx.blind.guru> References: <20190222132711.GA10545@kakigori> <87k1g498ye.fsf@fx.blind.guru> Message-ID: For what it's worth, I find the Discourse mailing-list mode to be perfectly adequate. Give it a shot! It does send you HTML messages, but the body of the message is usually pretty much in cleartext. M On Mon, Apr 8, 2019 at 9:51 AM Mario Lang wrote: > Bryan Richter writes: > > > As someone initially more comfortable with Mailman mailing lists, I > > empathize with people who have strong email workflows. Moving to > Discourse > > isn't painless. (There is a "mailing list mode", which helps some, but > not > > entirely.) A web UI has some downsides compared to text, for those so > > inclined. > > In particular, web UIs are everything else but accessibility friendly. > Every project that moves away from mailing lists and IRC effectively > maks it pretty hard for people which rely on accessibility to > participate. > > I am not expecting this to hold anyone back from moving into the shining > new era of client-less communication. Just wanted to point out that > people like me are going to be left behind. > > -- > CYa, > ⡍⠁⠗⠊⠕ > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Mon Apr 8 14:14:09 2019 From: will.yager at gmail.com (William Yager) Date: Mon, 8 Apr 2019 22:14:09 +0800 Subject: [Haskell-cafe] GHC extensions In-Reply-To: References: Message-ID: On Fri, Apr 5, 2019 at 11:19 PM Michel Haber wrote: > Hello Cafe, > > So I've been learning a bit about the GHC extensions from > https://github.com/i-am-tom/haskell-exercises. But the lessons say > nothing about how the extensions work behind the scenes. > > For example, I've assumed that RankNTypes would require something similar > to dynamic dispatch in imperative languages in order to work. But this is > just an assumption. > Sometimes, when you use a universally quantified type (forall a . ...), the only way to construct it is to use some kind of dynamic dispatch. For example, if you have a GADT data SomeShow where SomeShow :: forall a . Show a => a -> SomeShow In the absence of extremely aggressive inlining (which GHC might be able to do, I'm not sure), the only way to operate on such an object is to pass a vtable full of dynamic function pointers for the "Show" typeclass along with the "a" value. However, if you have a function like foo :: Bar c => (forall a . Bar a => a -> b) -> c -> b foo = id Even though there's a rank-2 type here, I would reasonably expect GHC to be able to construct this function with no additional overhead whatsoever. After all, it's just the identity function. There are a few things to think about that might help reveal why these sorts of abstractions can be free. * A "=>" arrow is just like a "->" arrow except it's the compiler's job to pass in the argument to a "=>" function. If the compiler could optimize a "->" function, it could probably optimize a similar "=>" function. * Existential quantification *restricts* the behavior of a value, rather than expanding it. * The semantics of the program are the same after you erase all the type information. * Existential quantification doesn't stop the inliner from working. > So I was wondering where I can get a quick succinct read (or a summary at > least) about how these extensions are implemented, as well as their > performance cost (or gain!). > > Also if someone knows other tutorials and lessons for these, and other > extensions, please feel free to share them :p > As a heuristic, I would hand-wavily claim that GHC typically tries its hardest to avoid type-level abstractions introducing value-level performance overhead, but it also doesn't try especially hard to use type-level abstractions to inform the optimizer. I think it's unlikely that turning on fancy type-system features will make your code go *faster*, but as long as you're careful it probably also won't go slower. My guess is that this stuff changes so fast that the only practical place to write this stuff down is the GHC source code. Cheers, Will > > Thank you, > Michel :) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Apr 8 18:28:06 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 08 Apr 2019 14:28:06 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.6.5-rc1 is now available Message-ID: <87o95gbbd8.fsf@smart-cactus.org> Hello everyone, The GHC team is proud to announce the first release candidate of 8.6.5. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.6.5-rc1 This release fixes a handful of issues with 8.6.4: - Binary distributions once again ship with Haddock documentation including syntax highlighted source of core libraries (#16445) - A build system issue where use of GCC with `-flto` broke `configure` was fixed (#16440) - An bug affecting Windows platforms wherein XMM register values could be mangled when entering STG has been fixed (#16514) - Several Windows packaging issues resulting from the recent CI rework. (#16408, #16398, #16516) Since this is a relatively small bugfix release we are bypassing the alpha releases and moving right to the release candidate stage. If all goes well the final release will be cut next week. As always, if anything looks amiss do let us know. Happy testing! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From svenpanne at gmail.com Mon Apr 8 18:41:52 2019 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 8 Apr 2019 20:41:52 +0200 Subject: [Haskell-cafe] GHC extensions In-Reply-To: References: Message-ID: Am Mo., 8. Apr. 2019 um 16:14 Uhr schrieb William Yager < will.yager at gmail.com>: > [...] As a heuristic, I would hand-wavily claim that GHC typically tries > its hardest to avoid type-level abstractions introducing value-level > performance overhead, but it also doesn't try especially hard to use > type-level abstractions to inform the optimizer. I think it's unlikely > that turning on fancy type-system features will make your code go *faster*, > but as long as you're careful it probably also won't go slower. [...] > This is basically my view on all the extensions, too. In my POV, the primary goal of all those fancy typing extensions is to make the set of programs which can statically be proven "to not go wrong" larger and has nothing to do with performance per se. There are of course extensions which can be used to improve performance, like the relatively recent stuff which allows you to coerce different things in a safe way, but AFAIK you have to give GHC a helping hand here by stating your intentions. All this typing magic is somehow the opposite of what a JIT does. An optimizing JIT basically says: "Hey, from what I've seen so far by executing your program, I can do the FOOBAR optimization. Of course this is wrong in the general case, but let's nevertheless use FOOBAR until I'm proven wrong by further executing your program. Then I can undo FOOBAR, anyway..." In other words: A traditional optimizing compiler statically proves things, an optimizing JIT dynamically assumes things. What is better for performance very much depends on what you're doing.,,, ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Mon Apr 8 19:04:27 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 8 Apr 2019 21:04:27 +0200 Subject: [Haskell-cafe] streaming with logs / metadata Message-ID: <26436804-FA09-42FA-8E57-C621CCF078F7@aatal-apotheke.de> Dear Evan, Probably you want to have a look whether the mtl package has something for you. Anything beyond the Functor instance for (Either e), though, models exceptions that abort the computation as soon as the first Left arises. You seem to use the type in a different way which may be one reason why you do not find your functions implemented elsewhere. For logging or warnings, most Haskellers use something like a writer monad transformer. The underlying monad, Writer w a = (w,a) for some monoid w, is exceptionally versatile because of the function Functor f => Writer w (f a) -> f (Writer w a) which in combination with traverse lets you move the (Writer w) type in and out of nested types easily. Cheers, Olaf From qdunkan at gmail.com Mon Apr 8 21:38:11 2019 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 8 Apr 2019 14:38:11 -0700 Subject: [Haskell-cafe] streaming with logs / metadata In-Reply-To: <26436804-FA09-42FA-8E57-C621CCF078F7@aatal-apotheke.de> References: <26436804-FA09-42FA-8E57-C621CCF078F7@aatal-apotheke.de> Message-ID: > Anything beyond the Functor instance for (Either e), though, models exceptions that abort the computation as soon as the first Left arises. You seem to use the type in a different way which may be one reason why you do not find your functions implemented elsewhere. For logging or warnings, most Haskellers use something like a writer monad transformer. The underlying monad, > > Writer w a = (w,a) That's the thing I was saying destroys streaming. The problem is that it returns ([log], [a]), instead of [Either log a], so the interleaving has been lost. From strake888 at gmail.com Tue Apr 9 00:31:49 2019 From: strake888 at gmail.com (Matthew Farkas-Dyck) Date: Mon, 8 Apr 2019 16:31:49 -0800 Subject: [Haskell-cafe] [ANNOUNCE] comprehensions-ghc: ApplicativeComprehensions as a GHC plugin Message-ID: https://hackage.haskell.org/package/comprehensions-ghc See description for instructions how to use. A comprehension makes more sense than a `do` expression for `Applicative` types — `ApplicativeDo` relies on a kludge: checking whether the last expression has the form `pure _` or `return _`. Indeed, for an `Applicative` term, it can ultimately (modulo aliases, let-expressions, η-expansion, etc) have no other! So far, however, the plugin merely rewrites each comprehension as a `do` expression. (It ignores comprehensions with features which can't be converted.) My most compelling use case so far has been context-free-parsing records (for examples: with `optparse-applicative` or `regex-applicative`). It lets one write the following: `[Options {..} | foo <- parseFoo, bar <- parseBar]` Cheers, happy hacking ☺ From frase at frase.id.au Tue Apr 9 05:27:03 2019 From: frase at frase.id.au (Fraser Tweedale) Date: Tue, 9 Apr 2019 15:27:03 +1000 Subject: [Haskell-cafe] Package takeover intent - dyre [RESOLVED] In-Reply-To: <20190408043032.GB4718@bacardi.hollandpark.frase.id.au> References: <20190408043032.GB4718@bacardi.hollandpark.frase.id.au> Message-ID: <20190409052702.GF4718@bacardi.hollandpark.frase.id.au> On Mon, Apr 08, 2019 at 02:30:32PM +1000, Fraser Tweedale wrote: > The dyre[1] package is unmaintained for 5 years. I would like to > contribute to it or take over maintainership, but have been unable > to contact the maintainer (Cc'd). Pursuant to wiki[2] I am > announcing my intention to take over the package. > > [1] https://hackage.haskell.org/package/dyre > [2] https://wiki.haskell.org/Taking_over_a_package > > Thanks, > Fraser > The original maintainer made contact and has added me as a maintainer. No Hackage admin action will be required. Thanks, Fraser -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From johannes.waldmann at htwk-leipzig.de Tue Apr 9 08:18:14 2019 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Tue, 9 Apr 2019 10:18:14 +0200 Subject: [Haskell-cafe] looking for yesod-auth example with LTS-13 In-Reply-To: References: Message-ID: > ... getting yesod-auth to work under LTS-13. turns out that I had to replace some "lift" with "liftHandler" in the authorisation code (and some "lift" with "liftIO" elsewhere). I have patched my code now, but not the code in "auth38". - J. From nicholls.mark at vimn.com Tue Apr 9 09:22:42 2019 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Tue, 9 Apr 2019 09:22:42 +0000 Subject: [Haskell-cafe] OO "dot" notation and records... Message-ID: Is there something in Haskell like this? I could do with getting OO like intelisense going...i.e. you have some values, the types are inhered in my environment, and the available functions prompt the programmer. (I'm not a big Haskell user, but I'm trying to "sell" it as an alternative for F# and scala in an industrial context). CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. From alexey.raga at gmail.com Tue Apr 9 10:53:59 2019 From: alexey.raga at gmail.com (Alexey Raga) Date: Tue, 9 Apr 2019 20:53:59 +1000 Subject: [Haskell-cafe] OO "dot" notation and records... In-Reply-To: References: Message-ID: Not really. You have intellisense suggesting you functions in modules (e.g. if you import Data.List as List and then type "List dot" it can suggest you some functions). You can also have almost "OO-style" dot-notation for records via lenses like "myUser ^. address . street" (or myUser ^. field @"address" . field @"street" if you use generic-lens). But I doubt that there is something that suggests you "fields" on "dot", since in Haskell they are not really fields, they are "normal" functions. Haskell doesn't really have records in that context. Best Regards, Alexey Raga On Tue, Apr 9, 2019 at 7:23 PM Nicholls, Mark wrote: > Is there something in Haskell like this? > > I could do with getting OO like intelisense going...i.e. you have some > values, the types are inhered in my environment, and the available > functions prompt the programmer. > > (I'm not a big Haskell user, but I'm trying to "sell" it as an alternative > for F# and scala in an industrial context). > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by > copyright (and other intellectual property rights). If you are not the > intended recipient please e-mail the sender and then delete the email and > any attached files immediately. Any further use or dissemination is > prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and > any attachments are virus free, it is your responsibility to ensure that > this message and any attachments are virus free and do not affect your > systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, > data corruption, non-delivery, wrongful interception and unauthorised > amendment. If you communicate with us by e-mail, you acknowledge and assume > these risks, and you agree to take appropriate measures to minimise these > risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, > Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions > International, Be Viacom, Viacom International Media Networks and VIMN and > Comedy Central are all trading names of MTV Networks Europe. MTV Networks > Europe is a partnership between MTV Networks Europe Inc. and Viacom > Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley > Crescent, London, NW1 8TT. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Tue Apr 9 14:00:11 2019 From: michael at orlitzky.com (Michael Orlitzky) Date: Tue, 9 Apr 2019 10:00:11 -0400 Subject: [Haskell-cafe] Looking for a paper Message-ID: <08980c64-9195-6b48-7f6f-54a58f81bfcb@orlitzky.com> Everyone knows that parentheses suck for function application. But I'm looking for a CS paper that argues that function application should have its own explicit syntax in a functional programming language. I believe, in the paper, that a dot "." was used, but this would be analogous to Haskell's "$" function, except that it would be made part of the language definition. I think it came up on this mailing list (where else would I have seen it?), and if anyone remembers the name or author I'd be grateful. From jaro.reinders at gmail.com Tue Apr 9 14:30:16 2019 From: jaro.reinders at gmail.com (jaro.reinders at gmail.com) Date: Tue, 09 Apr 2019 16:30:16 +0200 Subject: [Haskell-cafe] Looking for a paper In-Reply-To: <08980c64-9195-6b48-7f6f-54a58f81bfcb@orlitzky.com> References: <08980c64-9195-6b48-7f6f-54a58f81bfcb@orlitzky.com> Message-ID: <1607527.353WrVoQAG@jaro-laptop-debian> I remember this from one of Dijkstra's notes, but I don't remember which one. On dinsdag 9 april 2019 16:00:11 CEST Michael Orlitzky wrote: > Everyone knows that parentheses suck for function application. > > But I'm looking for a CS paper that argues that function application > should have its own explicit syntax in a functional programming > language. I believe, in the paper, that a dot "." was used, but this > would be analogous to Haskell's "$" function, except that it would be > made part of the language definition. > > I think it came up on this mailing list (where else would I have seen > it?), and if anyone remembers the name or author I'd be grateful. > > _______________________________________________ > 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. From jaro.reinders at gmail.com Tue Apr 9 14:41:18 2019 From: jaro.reinders at gmail.com (jaro.reinders at gmail.com) Date: Tue, 09 Apr 2019 16:41:18 +0200 Subject: [Haskell-cafe] Looking for a paper In-Reply-To: <08980c64-9195-6b48-7f6f-54a58f81bfcb@orlitzky.com> References: <08980c64-9195-6b48-7f6f-54a58f81bfcb@orlitzky.com> Message-ID: <1990225.3F0q3Sgy9x@jaro-laptop-debian> I found it: https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html On dinsdag 9 april 2019 16:00:11 CEST Michael Orlitzky wrote: > Everyone knows that parentheses suck for function application. > > But I'm looking for a CS paper that argues that function application > should have its own explicit syntax in a functional programming > language. I believe, in the paper, that a dot "." was used, but this > would be analogous to Haskell's "$" function, except that it would be > made part of the language definition. > > I think it came up on this mailing list (where else would I have seen > it?), and if anyone remembers the name or author I'd be grateful. > > _______________________________________________ > 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. From michael at orlitzky.com Tue Apr 9 15:09:09 2019 From: michael at orlitzky.com (Michael Orlitzky) Date: Tue, 9 Apr 2019 11:09:09 -0400 Subject: [Haskell-cafe] Looking for a paper In-Reply-To: <1990225.3F0q3Sgy9x@jaro-laptop-debian> References: <08980c64-9195-6b48-7f6f-54a58f81bfcb@orlitzky.com> <1990225.3F0q3Sgy9x@jaro-laptop-debian> Message-ID: On 4/9/19 10:41 AM, jaro.reinders at gmail.com wrote: > I found it: https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html > Thank you, this is obviously also relevant, but it's not the one I'm remembering. The notation is the same, though, so this explains what I'm looking for (and is also an interesting read). From frank at dedden.net Tue Apr 9 15:23:42 2019 From: frank at dedden.net (Frank Dedden) Date: Tue, 9 Apr 2019 17:23:42 +0200 Subject: [Haskell-cafe] [Announcement] Copilot 3.0, a hard realtime C generator and runtime verification framework Message-ID: <20190409152342.GA23181@shodan.lan> Dear all, We are very pleased to announce the release of Copilot 3.0, a stream-based DSL for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a runtime verification framework, where programs serve as specifications to the system we want to monitor. Additional libraries provide utility functions for temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Over the years, Copilot has been used at the Safety Critical Avionics Systems Branch of NASA Langley Research Center for monitoring test flights of drones. This new release contains a number of additional features that make writing programs easier: * The extended language with support for monitoring and generating structs and arrays in a type-safe manner. * A completely rewritten C99 code generator to support the new features. * Significant improvements on the quality and readability of the output code, which help in traceability and certification of the code. * Internal simplifications for a more future proof codebase. Copilot is available on hackage [1]. For more information, including documentation, examples and links to the source code, please visit the webpage [2]. Kind regards, The Copilot developers: - Frank Dedden (maintainer) - Alwyn Goodloe (maintainer) - Ivan Perez [1] http://hackage.haskell.org/package/copilot [2] https://copilot-language.github.io From olf at aatal-apotheke.de Tue Apr 9 19:53:27 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 9 Apr 2019 21:53:27 +0200 Subject: [Haskell-cafe] streaming with logs / metadata Message-ID: >> Anything beyond the Functor instance for (Either e), though, models exceptions that abort the computation as soon as the first Left arises. You seem to use the type in a different way which may be one reason why you do not find your functions implemented elsewhere. For logging or warnings, most Haskellers use something like a writer monad transformer. The underlying monad, >> >> Writer w a = (w,a) > > That's the thing I was saying destroys streaming. The problem is that > it returns ([log], [a]), instead of [Either log a], so the > interleaving has been lost. > Evan, When you say interleaving, do you think of lists like the following? [Left warning1,Right value 1,Left warning 2,Right value2,...] The above is isomorphic to [(warning1,value1),(warning2,value2),...] I don't think that the writer monad destroys streaming. Below is a somewhat contrived, but ordinary use case. {-- begin example --} import Control.Monad.Writer -- from mtl type Log = [String] -- some Monoid half :: Int -> Writer Log Int half x = case x `quotRem` 2 of (y,0) -> return y (y,1) -> writer (y,["Warning: "++(show x)++" was uneven."]) stream :: [Int] stream = 4:8:5:3:7:2: error "broken stream" (ys,warnings) = runWriter (mapM half stream) {-- end example --} ghci> -- load the example above ghci> ys [2,4,2,1,3,1*** Exception: broken stream ghci> mapM_ putStrLn warnings Warning: 5 was uneven. Warning: 3 was uneven. Warning: 7 was uneven. *** Exception: broken stream You see that there is some output before the error is reached, proving that both ys and warnings could be consumed in a streaming manner. Here it is important that the Log monoid's `mappend` function is not strict in the second argument. It would not, for example, work with Log = Data.Sequence.Seq String With mtl you could easily throw in a State monad component that keeps track of the position in the stream, so that warning messages can hint at the place where the warning originated. Olaf From michael at orlitzky.com Tue Apr 9 20:03:48 2019 From: michael at orlitzky.com (Michael Orlitzky) Date: Tue, 9 Apr 2019 16:03:48 -0400 Subject: [Haskell-cafe] Looking for a paper In-Reply-To: References: <08980c64-9195-6b48-7f6f-54a58f81bfcb@orlitzky.com> <1990225.3F0q3Sgy9x@jaro-laptop-debian> Message-ID: <1a55b423-84ff-5578-cfdb-91fb89224f4c@orlitzky.com> On 4/9/19 11:09 AM, Michael Orlitzky wrote: > On 4/9/19 10:41 AM, jaro.reinders at gmail.com wrote: >> I found it: https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html >> > > Thank you, this is obviously also relevant, but it's not the one I'm > remembering. The notation is the same, though, so this explains what I'm > looking for (and is also an interesting read). After the Dijkstra hint, I was able to track it down: http://www.the-magus.in/Publications/ewd.pdf Thanks! From qdunkan at gmail.com Tue Apr 9 20:55:04 2019 From: qdunkan at gmail.com (Evan Laforge) Date: Tue, 9 Apr 2019 13:55:04 -0700 Subject: [Haskell-cafe] streaming with logs / metadata In-Reply-To: References: Message-ID: On Tue, Apr 9, 2019 at 12:53 PM Olaf Klinke wrote: > When you say interleaving, do you think of lists like the following? > [Left warning1,Right value 1,Left warning 2,Right value2,...] > The above is isomorphic to > [(warning1,value1),(warning2,value2),...] > > I don't think that the writer monad destroys streaming. Below is a somewhat contrived, but ordinary use case. Ah, I see what you mean. I think I'm using a stricter definition of "streaming", what I mean is that I can process without a memory leak, in more-or-less constant memory (i.e. what packages like streams and pipes mean by it). With the Writer example, once I do: > (ys,warnings) = runWriter (mapM half stream) If I print warnings, I'm going to force all of 'ys' into memory. Taking one thing off of 'warnings' will force an unknown amount of 'ys'. Another way to look at it is that I can always go from [Either a b] to ([a], [b]) just by throwing away the interleaving, but then I can't go back since I lost that information. My instinct is that monads are too general for this, because they leave the output type polymorphic. It's more similar to 'streams', but focusing on interleaving "transparent" metadata rather than interleaving effects. And since 'streams' reimplements the whole list panopoly I guess that bodes ill for my attempt to avoid doing that too. In fact it could be a layer on top of 'streams', and maybe should be, to avoid having to do it all over again if I want effects some day... I still can't think of a good name though. From olf at aatal-apotheke.de Wed Apr 10 05:07:34 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 10 Apr 2019 07:07:34 +0200 Subject: [Haskell-cafe] streaming with logs / metadata In-Reply-To: References: Message-ID: <830AE332-2A02-4BFE-BFAB-A56FB2988B67@aatal-apotheke.de> > Am 09.04.2019 um 22:55 schrieb Evan Laforge : > > On Tue, Apr 9, 2019 at 12:53 PM Olaf Klinke wrote: >> When you say interleaving, do you think of lists like the following? >> [Left warning1,Right value 1,Left warning 2,Right value2,...] >> The above is isomorphic to >> [(warning1,value1),(warning2,value2),...] >> >> I don't think that the writer monad destroys streaming. Below is a somewhat contrived, but ordinary use case. > > Ah, I see what you mean. I think I'm using a stricter definition of > "streaming", what I mean is that I can process without a memory leak, > in more-or-less constant memory (i.e. what packages like streams and > pipes mean by it). With the Writer example, once I do: > >> (ys,warnings) = runWriter (mapM half stream) > > If I print warnings, I'm going to force all of 'ys' into memory. > Taking one thing off of 'warnings' will force an unknown amount of > 'ys'. Yes, but each element in the input stream generates at most one warning (in my example), so as long as you e.g. dump the warnings to stderr or a file and don't retain all warnings in memory, the program runs in constant memory. > > Another way to look at it is that I can always go from [Either a b] to > ([a], [b]) just by throwing away the interleaving, but then I can't go > back since I lost that information. You still have not clarified how [Either a b] is a type of values with annotations. To me this is a stream of computations, some of which have produced a value (Right b) and some have failed (Left a). Does the following match your intentions? data StreamElement a b = InfoMessage a | Value b Then you want streaming functions that process the Values in a stream of such StreamElements, passing on the InfoMessages as soon as they arrive? If an InfoMessage is independent of any Value, then this is the right abstraction. If each InfoMessage is really tied to some Value nearby in the stream, then you should go with pairs, i.e. the writer monad. > > My instinct is that monads are too general for this, because they > leave the output type polymorphic. It's more similar to 'streams', > but focusing on interleaving "transparent" metadata rather than > interleaving effects. And since 'streams' reimplements the whole list > panopoly I guess that bodes ill for my attempt to avoid doing that > too. In fact it could be a layer on top of 'streams', and maybe > should be, to avoid having to do it all over again if I want effects > some day... There are other streaming libraries like pipes and conduit, which are very general and powerful. Maybe one of those can do what you want. But I can't help there because I've never had a use case for them and the syntax diverges somewhat from ordinary lambda calculus. Olaf > > I still can't think of a good name though. From michelhaber1994 at gmail.com Wed Apr 10 10:32:43 2019 From: michelhaber1994 at gmail.com (Michel Haber) Date: Wed, 10 Apr 2019 12:32:43 +0200 Subject: [Haskell-cafe] Possible ghc bug Message-ID: Hello Cafe, I was trying to load a module containing this function in ghci: "add x y = wrap $ unwrap x + unwrap y" with the following extensions activated: ConstraintKinds DataKinds DeriveFunctor DuplicateRecordFields FlexibleContexts FlexibleInstances GADTs KindSignatures MultiParamTypeClasses PolyKinds TypeFamilies TypeOperators AllowAmbiguousTypes And it loaded without problem. So then I tested its type with ":t add", which gave: add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 Then I added this signature to the function in the module. This caused ghci to refuse to load it and give the following error: src/Exercises.hs:55:11: error: • Could not deduce (Newtype Integer b1) arising from a use of ‘wrap’ from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) bound by the type signature for: add :: forall a b1 b2 b3. (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 at src/Exercises.hs:54:1-74 • In the expression: wrap $ unwrap x + unwrap y In an equation for ‘add’: add x y = wrap $ unwrap x + unwrap y | 55 | add x y = wrap $ unwrap x + unwrap y | ^^^^^^^^^^^^^^^^^^^^^^^^^^ src/Exercises.hs:55:18: error: • Could not deduce (Newtype Integer b2) arising from a use of ‘unwrap’ from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) bound by the type signature for: add :: forall a b1 b2 b3. (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 at src/Exercises.hs:54:1-74 • In the first argument of ‘(+)’, namely ‘unwrap x’ In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ In the expression: wrap $ unwrap x + unwrap y | 55 | add x y = wrap $ unwrap x + unwrap y | ^^^^^^^^ src/Exercises.hs:55:29: error: • Could not deduce (Newtype Integer b3) arising from a use of ‘unwrap’ from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) bound by the type signature for: add :: forall a b1 b2 b3. (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 at src/Exercises.hs:54:1-74 • In the second argument of ‘(+)’, namely ‘unwrap y’ In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ In the expression: wrap $ unwrap x + unwrap y | 55 | add x y = wrap $ unwrap x + unwrap y | ^^^^^^^^ Failed, no modules loaded. This does not make sense to me, since I only used the signature that ghci itself gave me. Is this a bug? if not, could someone please explain this behaviour to me? Thanks, Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Wed Apr 10 11:28:01 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 10 Apr 2019 13:28:01 +0200 Subject: [Haskell-cafe] Possible ghc bug In-Reply-To: References: Message-ID: <8317231b-27fe-36fd-5ef0-7480ca531376@haskus.fr> Hi, It looks like an effect of ExtendedDefaultRules: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#extension-ExtendedDefaultRules It's hard to tell without the code but maybe something like that will do: {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} add :: forall a b1 b2 b3. (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y -Sylvain On 10/04/2019 12:32, Michel Haber wrote: > Hello Cafe, > > I was trying to load a module containing this function in ghci: > "add x y = wrap $ unwrap x + unwrap y" > with the following extensions activated: > > ConstraintKinds > DataKinds > DeriveFunctor > DuplicateRecordFields > FlexibleContexts > FlexibleInstances > GADTs > KindSignatures > MultiParamTypeClasses > PolyKinds > TypeFamilies > TypeOperators > AllowAmbiguousTypes > > And it loaded without problem. > > So then I tested its type with ":t add", which gave: > add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 > > Then I added this signature to the function in the module. This caused > ghci > to refuse to load it and give the following error: > > src/Exercises.hs:55:11: error: >     • Could not deduce (Newtype Integer b1) >         arising from a use of ‘wrap’ >       from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >         bound by the type signature for: >                    add :: forall a b1 b2 b3. >                           (Num a, Newtype a b1, Newtype a b2, Newtype > a b3) => >                           b2 -> b3 -> b1 >         at src/Exercises.hs:54:1-74 >     • In the expression: wrap $ unwrap x + unwrap y >       In an equation for ‘add’: add x y = wrap $ unwrap x + unwrap y >    | > 55 | add x y = wrap $ unwrap x + unwrap y >    |           ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > src/Exercises.hs:55:18: error: >     • Could not deduce (Newtype Integer b2) >         arising from a use of ‘unwrap’ >       from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >         bound by the type signature for: >                    add :: forall a b1 b2 b3. >                           (Num a, Newtype a b1, Newtype a b2, Newtype > a b3) => >                           b2 -> b3 -> b1 >         at src/Exercises.hs:54:1-74 >     • In the first argument of ‘(+)’, namely ‘unwrap x’ >       In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ >       In the expression: wrap $ unwrap x + unwrap y >    | > 55 | add x y = wrap $ unwrap x + unwrap y >    |                  ^^^^^^^^ > > src/Exercises.hs:55:29: error: >     • Could not deduce (Newtype Integer b3) >         arising from a use of ‘unwrap’ >       from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >         bound by the type signature for: >                    add :: forall a b1 b2 b3. >                           (Num a, Newtype a b1, Newtype a b2, Newtype > a b3) => >                           b2 -> b3 -> b1 >         at src/Exercises.hs:54:1-74 >     • In the second argument of ‘(+)’, namely ‘unwrap y’ >       In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ >       In the expression: wrap $ unwrap x + unwrap y >    | > 55 | add x y = wrap $ unwrap x + unwrap y >    |                             ^^^^^^^^ > Failed, no modules loaded. > > This does not make sense to me, since I only used the signature that > ghci itself gave me. > > Is this a bug? if not, could someone please explain this behaviour to me? > > Thanks, > Michel > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robstewart57 at gmail.com Wed Apr 10 13:12:56 2019 From: robstewart57 at gmail.com (Rob Stewart) Date: Wed, 10 Apr 2019 14:12:56 +0100 Subject: [Haskell-cafe] ANN: gitlab-haskell Message-ID: This new gitlab-haskell library provides read/write access to data on a GitLab server, using the GitLab web API. The library provides access to: branches, commits, groups, issues, jobs, members, merge requests, pipelines, projects, repositories, repository files and users. JSON responses are parsed into typed Haskell values for convenience. https://hackage.haskell.org/package/gitlab-haskell-0.1.0.0 -- Rob Stewart -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Wed Apr 10 13:27:23 2019 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 10 Apr 2019 15:27:23 +0200 Subject: [Haskell-cafe] ANN: gitlab-haskell In-Reply-To: References: Message-ID: <20190410132723.jmtwbsxvqbmr3zqm@x60s.casa> Hello Rob, On Wed, Apr 10, 2019 at 02:12:56PM +0100, Rob Stewart wrote: > This new gitlab-haskell library provides read/write access to data on a > GitLab server, using the GitLab web API. > > The library provides access to: branches, commits, groups, issues, jobs, > members, merge requests, pipelines, projects, repositories, repository > files and users. > > JSON responses are parsed into typed Haskell values for convenience. This is extremely nice (and with the migration of GHC to gitlab, very useful too)! > https://hackage.haskell.org/package/gitlab-haskell-0.1.0.0 You might want to post in haskell announce too (and/or Discourse), since not everyone is subscribed to -cafe! -F From michelhaber1994 at gmail.com Wed Apr 10 13:29:31 2019 From: michelhaber1994 at gmail.com (Michel Haber) Date: Wed, 10 Apr 2019 15:29:31 +0200 Subject: [Haskell-cafe] Possible ghc bug In-Reply-To: <8317231b-27fe-36fd-5ef0-7480ca531376@haskus.fr> References: <8317231b-27fe-36fd-5ef0-7480ca531376@haskus.fr> Message-ID: Hello, Thanks for the answer. I tried the code you sent, but now I'm getting a "type variable not in score" error. (I added both extensions) This is the whole code pertaining to this problem (with the extensions mentioned before): class Newtype a b where wrap :: a -> b unwrap :: b -> a newtype MyInt = MyInt Int newtype YourInt = YourInt Int instance Newtype Int MyInt where wrap = MyInt unwrap (MyInt i) = i instance Newtype Int YourInt where wrap = YourInt unwrap (YourInt i) = i add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y For further reference, the exercice to which this code should be a solution can be found at: https://github.com/i-am-tom/haskell-exercises/blob/answers/09-MultiParamTypeClasses/src/Exercises.hs Finally, the question remains: Is it "normal" that ghci behave differently depending on whether the type signature is declared or not? (Remember that the signature is given by ghci itself) Thanks again, Michel :) On Wed, Apr 10, 2019 at 1:28 PM Sylvain Henry wrote: > Hi, > > It looks like an effect of ExtendedDefaultRules: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#extension-ExtendedDefaultRules > > It's hard to tell without the code but maybe something like that will do: > > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE TypeApplications #-} > > add :: forall a b1 b2 b3. (Num a, Newtype a b1, Newtype a b2, Newtype a > b3) => b2 -> b3 -> b1 > add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y > > -Sylvain > On 10/04/2019 12:32, Michel Haber wrote: > > Hello Cafe, > > I was trying to load a module containing this function in ghci: > "add x y = wrap $ unwrap x + unwrap y" > with the following extensions activated: > > ConstraintKinds > DataKinds > DeriveFunctor > DuplicateRecordFields > FlexibleContexts > FlexibleInstances > GADTs > KindSignatures > MultiParamTypeClasses > PolyKinds > TypeFamilies > TypeOperators > AllowAmbiguousTypes > > And it loaded without problem. > > So then I tested its type with ":t add", which gave: > add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 > > Then I added this signature to the function in the module. This caused ghci > to refuse to load it and give the following error: > > src/Exercises.hs:55:11: error: > • Could not deduce (Newtype Integer b1) > arising from a use of ‘wrap’ > from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) > bound by the type signature for: > add :: forall a b1 b2 b3. > (Num a, Newtype a b1, Newtype a b2, Newtype a > b3) => > b2 -> b3 -> b1 > at src/Exercises.hs:54:1-74 > • In the expression: wrap $ unwrap x + unwrap y > In an equation for ‘add’: add x y = wrap $ unwrap x + unwrap y > | > 55 | add x y = wrap $ unwrap x + unwrap y > | ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > src/Exercises.hs:55:18: error: > • Could not deduce (Newtype Integer b2) > arising from a use of ‘unwrap’ > from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) > bound by the type signature for: > add :: forall a b1 b2 b3. > (Num a, Newtype a b1, Newtype a b2, Newtype a > b3) => > b2 -> b3 -> b1 > at src/Exercises.hs:54:1-74 > • In the first argument of ‘(+)’, namely ‘unwrap x’ > In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ > In the expression: wrap $ unwrap x + unwrap y > | > 55 | add x y = wrap $ unwrap x + unwrap y > | ^^^^^^^^ > > src/Exercises.hs:55:29: error: > • Could not deduce (Newtype Integer b3) > arising from a use of ‘unwrap’ > from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) > bound by the type signature for: > add :: forall a b1 b2 b3. > (Num a, Newtype a b1, Newtype a b2, Newtype a > b3) => > b2 -> b3 -> b1 > at src/Exercises.hs:54:1-74 > • In the second argument of ‘(+)’, namely ‘unwrap y’ > In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ > In the expression: wrap $ unwrap x + unwrap y > | > 55 | add x y = wrap $ unwrap x + unwrap y > | ^^^^^^^^ > Failed, no modules loaded. > > This does not make sense to me, since I only used the signature that ghci > itself gave me. > > Is this a bug? if not, could someone please explain this behaviour to me? > > Thanks, > Michel > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Wed Apr 10 14:29:53 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 10 Apr 2019 16:29:53 +0200 Subject: [Haskell-cafe] Possible ghc bug In-Reply-To: References: <8317231b-27fe-36fd-5ef0-7480ca531376@haskus.fr> Message-ID: On 10/04/2019 15:29, Michel Haber wrote: > Hello, > Thanks for the answer. > I tried the code you sent, but now I'm getting a "type variable not in > score" error. (I added both extensions) > This is the whole code pertaining to this problem (with the extensions > mentioned before): > > class Newtype a b where >   wrap   :: a -> b >   unwrap :: b -> a > > newtype MyInt   = MyInt   Int > newtype YourInt = YourInt Int > > instance Newtype Int MyInt where >   wrap = MyInt >   unwrap (MyInt i) = i > > instance Newtype Int YourInt where >   wrap = YourInt >   unwrap (YourInt i) = i > > add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 > add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y You need to add the "forall a b1 b2 b3" to be allowed to use "@a" (with ScopedTypeVariables extension). > > For further reference, the exercice to which this code should be a > solution can be found at: > https://github.com/i-am-tom/haskell-exercises/blob/answers/09-MultiParamTypeClasses/src/Exercises.hs > c. Write a function that adds together two values of the same type, providing that the type is a newtype around some type with a 'Num' instance. You only need a single "b" type instead of b1, b2 b3. Also I think you could use a Function Dependency in the "Newtype" definition (because when we know "b" we know "a"). It will make the code of "add' much simpler. > > Finally, the question remains: Is it "normal" that ghci behave > differently depending on whether > the type signature is declared or not? (Remember that the signature is > given by ghci itself) Finally it is not related to GHCi (we get the same errors/warnings when we compile) but to the AllowAmbiguousTypes extension: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?#extension-AllowAmbiguousTypes The type of "add" is ambiguous according to the definition in the manual. My advice would be to use a Functional dependency in your definition of NewType and then you can forget about ambiguous types, type applications, scoped type variables, etc. for now. The reported type of "add" by ghci becomes non-ambiguous and everything is well :) (and I guess that it was the point of the exercise) Regards, Sylvain > > Thanks again, > Michel :) > > On Wed, Apr 10, 2019 at 1:28 PM Sylvain Henry > wrote: > > Hi, > > It looks like an effect of ExtendedDefaultRules: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#extension-ExtendedDefaultRules > > It's hard to tell without the code but maybe something like that > will do: > > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE TypeApplications #-} > > add :: forall a b1 b2 b3. (Num a, Newtype a b1, Newtype a b2, > Newtype a b3) => b2 -> b3 -> b1 > add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y > > -Sylvain > > On 10/04/2019 12:32, Michel Haber wrote: >> Hello Cafe, >> >> I was trying to load a module containing this function in ghci: >> "add x y = wrap $ unwrap x + unwrap y" >> with the following extensions activated: >> >> ConstraintKinds >> DataKinds >> DeriveFunctor >> DuplicateRecordFields >> FlexibleContexts >> FlexibleInstances >> GADTs >> KindSignatures >> MultiParamTypeClasses >> PolyKinds >> TypeFamilies >> TypeOperators >> AllowAmbiguousTypes >> >> And it loaded without problem. >> >> So then I tested its type with ":t add", which gave: >> add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> >> b3 -> b1 >> >> Then I added this signature to the function in the module. This >> caused ghci >> to refuse to load it and give the following error: >> >> src/Exercises.hs:55:11: error: >>     • Could not deduce (Newtype Integer b1) >>         arising from a use of ‘wrap’ >>       from the context: (Num a, Newtype a b1, Newtype a b2, >> Newtype a b3) >>         bound by the type signature for: >>                    add :: forall a b1 b2 b3. >>                           (Num a, Newtype a b1, Newtype a b2, >> Newtype a b3) => >>                           b2 -> b3 -> b1 >>         at src/Exercises.hs:54:1-74 >>     • In the expression: wrap $ unwrap x + unwrap y >>       In an equation for ‘add’: add x y = wrap $ unwrap x + unwrap y >>    | >> 55 | add x y = wrap $ unwrap x + unwrap y >>    |           ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> src/Exercises.hs:55:18: error: >>     • Could not deduce (Newtype Integer b2) >>         arising from a use of ‘unwrap’ >>       from the context: (Num a, Newtype a b1, Newtype a b2, >> Newtype a b3) >>         bound by the type signature for: >>                    add :: forall a b1 b2 b3. >>                           (Num a, Newtype a b1, Newtype a b2, >> Newtype a b3) => >>                           b2 -> b3 -> b1 >>         at src/Exercises.hs:54:1-74 >>     • In the first argument of ‘(+)’, namely ‘unwrap x’ >>       In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ >>       In the expression: wrap $ unwrap x + unwrap y >>    | >> 55 | add x y = wrap $ unwrap x + unwrap y >>    |                  ^^^^^^^^ >> >> src/Exercises.hs:55:29: error: >>     • Could not deduce (Newtype Integer b3) >>         arising from a use of ‘unwrap’ >>       from the context: (Num a, Newtype a b1, Newtype a b2, >> Newtype a b3) >>         bound by the type signature for: >>                    add :: forall a b1 b2 b3. >>                           (Num a, Newtype a b1, Newtype a b2, >> Newtype a b3) => >>                           b2 -> b3 -> b1 >>         at src/Exercises.hs:54:1-74 >>     • In the second argument of ‘(+)’, namely ‘unwrap y’ >>       In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ >>       In the expression: wrap $ unwrap x + unwrap y >>    | >> 55 | add x y = wrap $ unwrap x + unwrap y >>    |                             ^^^^^^^^ >> Failed, no modules loaded. >> >> This does not make sense to me, since I only used the signature >> that ghci itself gave me. >> >> Is this a bug? if not, could someone please explain this >> behaviour to me? >> >> Thanks, >> Michel >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelhaber1994 at gmail.com Wed Apr 10 14:54:07 2019 From: michelhaber1994 at gmail.com (Michel Haber) Date: Wed, 10 Apr 2019 16:54:07 +0200 Subject: [Haskell-cafe] Possible ghc bug In-Reply-To: References: <8317231b-27fe-36fd-5ef0-7480ca531376@haskus.fr> Message-ID: Hello Sylvain, and thanks again :) When adding the forall I can compile the code without a problem. For the types b1 b2 b3, they are of course not what I want (b must be unique in the context of the question). But the type for the function with b1, b2 and b3 is what I got when I did not give a type signature to the compiler/interpreter (which is understandable since it has no reason to assume they would be one and the same). I will try the Functional dependency (though I haven't learned about this yet). But the main question remains: "add x y = wrap $ unwrap x + unwrap y" can be compiled/interpreted, and when I ask about its type, the answer is: ":t add" "add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1" Then when I add that same type signature, like so: "add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 add x y = wrap $ unwrap x + unwrap y" the compiler refuses it for ambiguity reasons. So the question is: How come the compiler does not accept its own type signature? Why had it not refused to compile even without one, and only upon specification of said signature did the compilation break? Regards, Michel :) On Wed, Apr 10, 2019 at 4:29 PM Sylvain Henry wrote: > > On 10/04/2019 15:29, Michel Haber wrote: > > Hello, > Thanks for the answer. > I tried the code you sent, but now I'm getting a "type variable not in > score" error. (I added both extensions) > This is the whole code pertaining to this problem (with the extensions > mentioned before): > > class Newtype a b where > wrap :: a -> b > unwrap :: b -> a > > newtype MyInt = MyInt Int > newtype YourInt = YourInt Int > > instance Newtype Int MyInt where > wrap = MyInt > unwrap (MyInt i) = i > > instance Newtype Int YourInt where > wrap = YourInt > unwrap (YourInt i) = i > > add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 > add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y > > You need to add the "forall a b1 b2 b3" to be allowed to use "@a" (with > ScopedTypeVariables extension). > > > For further reference, the exercice to which this code should be a > solution can be found at: > > https://github.com/i-am-tom/haskell-exercises/blob/answers/09-MultiParamTypeClasses/src/Exercises.hs > > > c. Write a function that adds together two values of the same type, providing > that the type is a newtype around some type with a 'Num' instance. > > You only need a single "b" type instead of b1, b2 b3. Also I think you > could use a Function Dependency in the "Newtype" definition (because when > we know "b" we know "a"). It will make the code of "add' much simpler. > > > Finally, the question remains: Is it "normal" that ghci behave differently > depending on whether > the type signature is declared or not? (Remember that the signature is > given by ghci itself) > > Finally it is not related to GHCi (we get the same errors/warnings when we > compile) but to the AllowAmbiguousTypes extension: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?#extension-AllowAmbiguousTypes > > The type of "add" is ambiguous according to the definition in the manual. > > > My advice would be to use a Functional dependency in your definition of > NewType and then you can forget about ambiguous types, type applications, > scoped type variables, etc. for now. The reported type of "add" by ghci > becomes non-ambiguous and everything is well :) (and I guess that it was > the point of the exercise) > > Regards, > Sylvain > > > > Thanks again, > Michel :) > > On Wed, Apr 10, 2019 at 1:28 PM Sylvain Henry wrote: > >> Hi, >> >> It looks like an effect of ExtendedDefaultRules: >> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#extension-ExtendedDefaultRules >> >> It's hard to tell without the code but maybe something like that will do: >> >> {-# LANGUAGE ScopedTypeVariables #-} >> {-# LANGUAGE TypeApplications #-} >> >> add :: forall a b1 b2 b3. (Num a, Newtype a b1, Newtype a b2, Newtype a >> b3) => b2 -> b3 -> b1 >> add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y >> >> -Sylvain >> On 10/04/2019 12:32, Michel Haber wrote: >> >> Hello Cafe, >> >> I was trying to load a module containing this function in ghci: >> "add x y = wrap $ unwrap x + unwrap y" >> with the following extensions activated: >> >> ConstraintKinds >> DataKinds >> DeriveFunctor >> DuplicateRecordFields >> FlexibleContexts >> FlexibleInstances >> GADTs >> KindSignatures >> MultiParamTypeClasses >> PolyKinds >> TypeFamilies >> TypeOperators >> AllowAmbiguousTypes >> >> And it loaded without problem. >> >> So then I tested its type with ":t add", which gave: >> add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 >> >> Then I added this signature to the function in the module. This caused >> ghci >> to refuse to load it and give the following error: >> >> src/Exercises.hs:55:11: error: >> • Could not deduce (Newtype Integer b1) >> arising from a use of ‘wrap’ >> from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >> bound by the type signature for: >> add :: forall a b1 b2 b3. >> (Num a, Newtype a b1, Newtype a b2, Newtype a >> b3) => >> b2 -> b3 -> b1 >> at src/Exercises.hs:54:1-74 >> • In the expression: wrap $ unwrap x + unwrap y >> In an equation for ‘add’: add x y = wrap $ unwrap x + unwrap y >> | >> 55 | add x y = wrap $ unwrap x + unwrap y >> | ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> src/Exercises.hs:55:18: error: >> • Could not deduce (Newtype Integer b2) >> arising from a use of ‘unwrap’ >> from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >> bound by the type signature for: >> add :: forall a b1 b2 b3. >> (Num a, Newtype a b1, Newtype a b2, Newtype a >> b3) => >> b2 -> b3 -> b1 >> at src/Exercises.hs:54:1-74 >> • In the first argument of ‘(+)’, namely ‘unwrap x’ >> In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ >> In the expression: wrap $ unwrap x + unwrap y >> | >> 55 | add x y = wrap $ unwrap x + unwrap y >> | ^^^^^^^^ >> >> src/Exercises.hs:55:29: error: >> • Could not deduce (Newtype Integer b3) >> arising from a use of ‘unwrap’ >> from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >> bound by the type signature for: >> add :: forall a b1 b2 b3. >> (Num a, Newtype a b1, Newtype a b2, Newtype a >> b3) => >> b2 -> b3 -> b1 >> at src/Exercises.hs:54:1-74 >> • In the second argument of ‘(+)’, namely ‘unwrap y’ >> In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ >> In the expression: wrap $ unwrap x + unwrap y >> | >> 55 | add x y = wrap $ unwrap x + unwrap y >> | ^^^^^^^^ >> Failed, no modules loaded. >> >> This does not make sense to me, since I only used the signature that ghci >> itself gave me. >> >> Is this a bug? if not, could someone please explain this behaviour to me? >> >> Thanks, >> Michel >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.pelenitsyn at gmail.com Wed Apr 10 15:02:16 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Wed, 10 Apr 2019 11:02:16 -0400 Subject: [Haskell-cafe] Possible ghc bug In-Reply-To: References: <8317231b-27fe-36fd-5ef0-7480ca531376@haskus.fr> Message-ID: Hello Michel, I think this might be worth filing as a bug: https://gitlab.haskell.org/ghc/ghc/issues/new -- Best, Artem On Wed, 10 Apr 2019 at 10:54 Michel Haber wrote: > Hello Sylvain, and thanks again :) > > When adding the forall I can compile the code without a problem. > > For the types b1 b2 b3, they are of course not what I want (b must be > unique in the context of the question). > But the type for the function with b1, b2 and b3 is what I got when I did > not give a type signature to the compiler/interpreter (which is > understandable since it has no reason to assume they would be one and the > same). > > I will try the Functional dependency (though I haven't learned about this > yet). > > But the main question remains: > > "add x y = wrap $ unwrap x + unwrap y" can be compiled/interpreted, and > when I ask about its type, the answer is: > ":t add" > "add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> > b1" > > Then when I add that same type signature, like so: > "add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 > add x y = wrap $ unwrap x + unwrap y" > the compiler refuses it for ambiguity reasons. > > So the question is: How come the compiler does not accept its own type > signature? Why had it not refused to compile even without one, and only > upon specification of said signature did the compilation break? > > Regards, > Michel :) > > On Wed, Apr 10, 2019 at 4:29 PM Sylvain Henry wrote: > >> >> On 10/04/2019 15:29, Michel Haber wrote: >> >> Hello, >> Thanks for the answer. >> I tried the code you sent, but now I'm getting a "type variable not in >> score" error. (I added both extensions) >> This is the whole code pertaining to this problem (with the extensions >> mentioned before): >> >> class Newtype a b where >> wrap :: a -> b >> unwrap :: b -> a >> >> newtype MyInt = MyInt Int >> newtype YourInt = YourInt Int >> >> instance Newtype Int MyInt where >> wrap = MyInt >> unwrap (MyInt i) = i >> >> instance Newtype Int YourInt where >> wrap = YourInt >> unwrap (YourInt i) = i >> >> add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 >> add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y >> >> You need to add the "forall a b1 b2 b3" to be allowed to use "@a" (with >> ScopedTypeVariables extension). >> >> >> For further reference, the exercice to which this code should be a >> solution can be found at: >> >> https://github.com/i-am-tom/haskell-exercises/blob/answers/09-MultiParamTypeClasses/src/Exercises.hs >> >> > c. Write a function that adds together two values of the same type, providing >> that the type is a newtype around some type with a 'Num' instance. >> >> You only need a single "b" type instead of b1, b2 b3. Also I think you >> could use a Function Dependency in the "Newtype" definition (because when >> we know "b" we know "a"). It will make the code of "add' much simpler. >> >> >> Finally, the question remains: Is it "normal" that ghci behave >> differently depending on whether >> the type signature is declared or not? (Remember that the signature is >> given by ghci itself) >> >> Finally it is not related to GHCi (we get the same errors/warnings when >> we compile) but to the AllowAmbiguousTypes extension: >> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?#extension-AllowAmbiguousTypes >> >> The type of "add" is ambiguous according to the definition in the manual. >> >> >> My advice would be to use a Functional dependency in your definition of >> NewType and then you can forget about ambiguous types, type applications, >> scoped type variables, etc. for now. The reported type of "add" by ghci >> becomes non-ambiguous and everything is well :) (and I guess that it was >> the point of the exercise) >> >> Regards, >> Sylvain >> >> >> >> Thanks again, >> Michel :) >> >> On Wed, Apr 10, 2019 at 1:28 PM Sylvain Henry wrote: >> >>> Hi, >>> >>> It looks like an effect of ExtendedDefaultRules: >>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#extension-ExtendedDefaultRules >>> >>> It's hard to tell without the code but maybe something like that will do: >>> >>> {-# LANGUAGE ScopedTypeVariables #-} >>> {-# LANGUAGE TypeApplications #-} >>> >>> add :: forall a b1 b2 b3. (Num a, Newtype a b1, Newtype a b2, Newtype a >>> b3) => b2 -> b3 -> b1 >>> add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y >>> >>> -Sylvain >>> On 10/04/2019 12:32, Michel Haber wrote: >>> >>> Hello Cafe, >>> >>> I was trying to load a module containing this function in ghci: >>> "add x y = wrap $ unwrap x + unwrap y" >>> with the following extensions activated: >>> >>> ConstraintKinds >>> DataKinds >>> DeriveFunctor >>> DuplicateRecordFields >>> FlexibleContexts >>> FlexibleInstances >>> GADTs >>> KindSignatures >>> MultiParamTypeClasses >>> PolyKinds >>> TypeFamilies >>> TypeOperators >>> AllowAmbiguousTypes >>> >>> And it loaded without problem. >>> >>> So then I tested its type with ":t add", which gave: >>> add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> >>> b1 >>> >>> Then I added this signature to the function in the module. This caused >>> ghci >>> to refuse to load it and give the following error: >>> >>> src/Exercises.hs:55:11: error: >>> • Could not deduce (Newtype Integer b1) >>> arising from a use of ‘wrap’ >>> from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >>> bound by the type signature for: >>> add :: forall a b1 b2 b3. >>> (Num a, Newtype a b1, Newtype a b2, Newtype a >>> b3) => >>> b2 -> b3 -> b1 >>> at src/Exercises.hs:54:1-74 >>> • In the expression: wrap $ unwrap x + unwrap y >>> In an equation for ‘add’: add x y = wrap $ unwrap x + unwrap y >>> | >>> 55 | add x y = wrap $ unwrap x + unwrap y >>> | ^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> src/Exercises.hs:55:18: error: >>> • Could not deduce (Newtype Integer b2) >>> arising from a use of ‘unwrap’ >>> from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >>> bound by the type signature for: >>> add :: forall a b1 b2 b3. >>> (Num a, Newtype a b1, Newtype a b2, Newtype a >>> b3) => >>> b2 -> b3 -> b1 >>> at src/Exercises.hs:54:1-74 >>> • In the first argument of ‘(+)’, namely ‘unwrap x’ >>> In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ >>> In the expression: wrap $ unwrap x + unwrap y >>> | >>> 55 | add x y = wrap $ unwrap x + unwrap y >>> | ^^^^^^^^ >>> >>> src/Exercises.hs:55:29: error: >>> • Could not deduce (Newtype Integer b3) >>> arising from a use of ‘unwrap’ >>> from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >>> bound by the type signature for: >>> add :: forall a b1 b2 b3. >>> (Num a, Newtype a b1, Newtype a b2, Newtype a >>> b3) => >>> b2 -> b3 -> b1 >>> at src/Exercises.hs:54:1-74 >>> • In the second argument of ‘(+)’, namely ‘unwrap y’ >>> In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ >>> In the expression: wrap $ unwrap x + unwrap y >>> | >>> 55 | add x y = wrap $ unwrap x + unwrap y >>> | ^^^^^^^^ >>> Failed, no modules loaded. >>> >>> This does not make sense to me, since I only used the signature that >>> ghci itself gave me. >>> >>> Is this a bug? if not, could someone please explain this behaviour to me? >>> >>> Thanks, >>> Michel >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Wed Apr 10 15:26:33 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 10 Apr 2019 17:26:33 +0200 Subject: [Haskell-cafe] Possible ghc bug In-Reply-To: References: <8317231b-27fe-36fd-5ef0-7480ca531376@haskus.fr> Message-ID: <22f8f84d-bcb4-5dac-f21d-e03dd71a771a@haskus.fr> >So the question is: How come the compiler does not accept its own type signature? Why had it not refused to compile even without one, and only upon specification of said signature did the compilation break? It is explained here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?#extension-AllowAmbiguousTypes /> definition/ of ambiguity: a type ty is ambiguous if and only if ((undefined :: ty) :: ty) would fail to typecheck. The type of "add" is ambiguous. Regards, Sylvain On 10/04/2019 16:54, Michel Haber wrote: > Hello Sylvain, and thanks again :) > > When adding the forall I can compile the code without a problem. > > For the types b1 b2 b3, they are of course not what I want (b must be > unique in the context of the question). > But the type for the function with b1, b2 and b3 is what I got when I > did not give a type signature to the compiler/interpreter (which is > understandable since it has no reason to assume they would be one and > the same). > > I will try the Functional dependency (though I haven't learned about > this yet). > > But the main question remains: > > "add x y = wrap $ unwrap x + unwrap y" can be compiled/interpreted, > and when I ask about its type, the answer is: > ":t add" > "add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 > -> b1" > > Then when I add that same type signature, like so: > "add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 > -> b1 >  add x y = wrap $ unwrap x + unwrap y" > the compiler refuses it for ambiguity reasons. > > So the question is: How come the compiler does not accept its own type > signature? Why had it not refused to compile even without one, and only > upon specification of said signature did the compilation break? > > Regards, > Michel :) > > On Wed, Apr 10, 2019 at 4:29 PM Sylvain Henry > wrote: > > > On 10/04/2019 15:29, Michel Haber wrote: >> Hello, >> Thanks for the answer. >> I tried the code you sent, but now I'm getting a "type variable >> not in score" error. (I added both extensions) >> This is the whole code pertaining to this problem (with the >> extensions mentioned before): >> >> class Newtype a b where >>   wrap   :: a -> b >>   unwrap :: b -> a >> >> newtype MyInt   = MyInt   Int >> newtype YourInt = YourInt Int >> >> instance Newtype Int MyInt where >>   wrap = MyInt >>   unwrap (MyInt i) = i >> >> instance Newtype Int YourInt where >>   wrap = YourInt >>   unwrap (YourInt i) = i >> >> add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> >> b3 -> b1 >> add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y > > You need to add the "forall a b1 b2 b3" to be allowed to use "@a" > (with ScopedTypeVariables extension). > >> >> For further reference, the exercice to which this code should be >> a solution can be found at: >> https://github.com/i-am-tom/haskell-exercises/blob/answers/09-MultiParamTypeClasses/src/Exercises.hs > > > c. Write a function that adds together two values of the same > type, providing that the type is a newtype around some type with a > 'Num' instance. > > You only need a single "b" type instead of b1, b2 b3. Also I think > you could use a Function Dependency in the "Newtype" definition > (because when we know "b" we know "a"). It will make the code of > "add' much simpler. > >> >> Finally, the question remains: Is it "normal" that ghci behave >> differently depending on whether >> the type signature is declared or not? (Remember that the >> signature is given by ghci itself) > > Finally it is not related to GHCi (we get the same errors/warnings > when we compile) but to the AllowAmbiguousTypes extension: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?#extension-AllowAmbiguousTypes > > The type of "add" is ambiguous according to the definition in the > manual. > > > My advice would be to use a Functional dependency in your > definition of NewType and then you can forget about ambiguous > types, type applications, scoped type variables, etc. for now. The > reported type of "add" by ghci becomes non-ambiguous and > everything is well :) (and I guess that it was the point of the > exercise) > > Regards, > Sylvain > > >> >> Thanks again, >> Michel :) >> >> On Wed, Apr 10, 2019 at 1:28 PM Sylvain Henry > > wrote: >> >> Hi, >> >> It looks like an effect of ExtendedDefaultRules: >> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#extension-ExtendedDefaultRules >> >> It's hard to tell without the code but maybe something like >> that will do: >> >> {-# LANGUAGE ScopedTypeVariables #-} >> {-# LANGUAGE TypeApplications #-} >> >> add :: forall a b1 b2 b3. (Num a, Newtype a b1, Newtype a b2, >> Newtype a b3) => b2 -> b3 -> b1 >> add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y >> >> -Sylvain >> >> On 10/04/2019 12:32, Michel Haber wrote: >>> Hello Cafe, >>> >>> I was trying to load a module containing this function in ghci: >>> "add x y = wrap $ unwrap x + unwrap y" >>> with the following extensions activated: >>> >>> ConstraintKinds >>> DataKinds >>> DeriveFunctor >>> DuplicateRecordFields >>> FlexibleContexts >>> FlexibleInstances >>> GADTs >>> KindSignatures >>> MultiParamTypeClasses >>> PolyKinds >>> TypeFamilies >>> TypeOperators >>> AllowAmbiguousTypes >>> >>> And it loaded without problem. >>> >>> So then I tested its type with ":t add", which gave: >>> add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => >>> b2 -> b3 -> b1 >>> >>> Then I added this signature to the function in the module. >>> This caused ghci >>> to refuse to load it and give the following error: >>> >>> src/Exercises.hs:55:11: error: >>>     • Could not deduce (Newtype Integer b1) >>>         arising from a use of ‘wrap’ >>>       from the context: (Num a, Newtype a b1, Newtype a b2, >>> Newtype a b3) >>>         bound by the type signature for: >>>                    add :: forall a b1 b2 b3. >>>                           (Num a, Newtype a b1, Newtype a >>> b2, Newtype a b3) => >>>                           b2 -> b3 -> b1 >>>         at src/Exercises.hs:54:1-74 >>>     • In the expression: wrap $ unwrap x + unwrap y >>>       In an equation for ‘add’: add x y = wrap $ unwrap x + >>> unwrap y >>>    | >>> 55 | add x y = wrap $ unwrap x + unwrap y >>>    | ^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> src/Exercises.hs:55:18: error: >>>     • Could not deduce (Newtype Integer b2) >>>         arising from a use of ‘unwrap’ >>>       from the context: (Num a, Newtype a b1, Newtype a b2, >>> Newtype a b3) >>>         bound by the type signature for: >>>                    add :: forall a b1 b2 b3. >>>                           (Num a, Newtype a b1, Newtype a >>> b2, Newtype a b3) => >>>                           b2 -> b3 -> b1 >>>         at src/Exercises.hs:54:1-74 >>>     • In the first argument of ‘(+)’, namely ‘unwrap x’ >>>       In the second argument of ‘($)’, namely ‘unwrap x + >>> unwrap y’ >>>       In the expression: wrap $ unwrap x + unwrap y >>>    | >>> 55 | add x y = wrap $ unwrap x + unwrap y >>>    |                  ^^^^^^^^ >>> >>> src/Exercises.hs:55:29: error: >>>     • Could not deduce (Newtype Integer b3) >>>         arising from a use of ‘unwrap’ >>>       from the context: (Num a, Newtype a b1, Newtype a b2, >>> Newtype a b3) >>>         bound by the type signature for: >>>                    add :: forall a b1 b2 b3. >>>                           (Num a, Newtype a b1, Newtype a >>> b2, Newtype a b3) => >>>                           b2 -> b3 -> b1 >>>         at src/Exercises.hs:54:1-74 >>>     • In the second argument of ‘(+)’, namely ‘unwrap y’ >>>       In the second argument of ‘($)’, namely ‘unwrap x + >>> unwrap y’ >>>       In the expression: wrap $ unwrap x + unwrap y >>>    | >>> 55 | add x y = wrap $ unwrap x + unwrap y >>>    | ^^^^^^^^ >>> Failed, no modules loaded. >>> >>> This does not make sense to me, since I only used the >>> signature that ghci itself gave me. >>> >>> Is this a bug? if not, could someone please explain this >>> behaviour to me? >>> >>> Thanks, >>> Michel >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Apr 10 18:16:25 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 10 Apr 2019 14:16:25 -0400 Subject: [Haskell-cafe] Possible ghc bug In-Reply-To: <22f8f84d-bcb4-5dac-f21d-e03dd71a771a@haskus.fr> References: <8317231b-27fe-36fd-5ef0-7480ca531376@haskus.fr> <22f8f84d-bcb4-5dac-f21d-e03dd71a771a@haskus.fr> Message-ID: More precisely, given that definition and no type signature and no fundeps or other constraints, ghci gave you the most general type for "add", which is indeed ambiguous as there is no way for it to prove from the definition of class Newtype that all the "b"s should be the same. This ambiguity is why fundeps (and type families) exist: they extend the semantics of typeclasses to allow this determination. Without AllowAmbiguousTypes, it would have told you this because typeclasses also prevent its resolution as part of using the "add" function. But TypeApplications lets you specify the "hidden" types, hence the AllowAmbiguousTypes extension for when you actually intend to use TypeApplications that way. (It's something of a Big Hammer; it'd be nice if it could be constrained to the specific types where you want to use that.) On Wed, Apr 10, 2019 at 11:27 AM Sylvain Henry wrote: > >So the question is: How come the compiler does not accept its own type > signature? Why had it not refused to compile even without one, and only > upon specification of said signature did the compilation break? > > It is explained here: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?#extension-AllowAmbiguousTypes > > *> definition* of ambiguity: a type ty is ambiguous if and only if > ((undefined :: ty) :: ty) would fail to typecheck. > > The type of "add" is ambiguous. > > Regards, > Sylvain > > > > On 10/04/2019 16:54, Michel Haber wrote: > > Hello Sylvain, and thanks again :) > > When adding the forall I can compile the code without a problem. > > For the types b1 b2 b3, they are of course not what I want (b must be > unique in the context of the question). > But the type for the function with b1, b2 and b3 is what I got when I did > not give a type signature to the compiler/interpreter (which is > understandable since it has no reason to assume they would be one and the > same). > > I will try the Functional dependency (though I haven't learned about this > yet). > > But the main question remains: > > "add x y = wrap $ unwrap x + unwrap y" can be compiled/interpreted, and > when I ask about its type, the answer is: > ":t add" > "add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> > b1" > > Then when I add that same type signature, like so: > "add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 > add x y = wrap $ unwrap x + unwrap y" > the compiler refuses it for ambiguity reasons. > > So the question is: How come the compiler does not accept its own type > signature? Why had it not refused to compile even without one, and only > upon specification of said signature did the compilation break? > > Regards, > Michel :) > > On Wed, Apr 10, 2019 at 4:29 PM Sylvain Henry wrote: > >> >> On 10/04/2019 15:29, Michel Haber wrote: >> >> Hello, >> Thanks for the answer. >> I tried the code you sent, but now I'm getting a "type variable not in >> score" error. (I added both extensions) >> This is the whole code pertaining to this problem (with the extensions >> mentioned before): >> >> class Newtype a b where >> wrap :: a -> b >> unwrap :: b -> a >> >> newtype MyInt = MyInt Int >> newtype YourInt = YourInt Int >> >> instance Newtype Int MyInt where >> wrap = MyInt >> unwrap (MyInt i) = i >> >> instance Newtype Int YourInt where >> wrap = YourInt >> unwrap (YourInt i) = i >> >> add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> b1 >> add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y >> >> You need to add the "forall a b1 b2 b3" to be allowed to use "@a" (with >> ScopedTypeVariables extension). >> >> >> For further reference, the exercice to which this code should be a >> solution can be found at: >> >> https://github.com/i-am-tom/haskell-exercises/blob/answers/09-MultiParamTypeClasses/src/Exercises.hs >> >> > c. Write a function that adds together two values of the same type, providing >> that the type is a newtype around some type with a 'Num' instance. >> >> You only need a single "b" type instead of b1, b2 b3. Also I think you >> could use a Function Dependency in the "Newtype" definition (because when >> we know "b" we know "a"). It will make the code of "add' much simpler. >> >> >> Finally, the question remains: Is it "normal" that ghci behave >> differently depending on whether >> the type signature is declared or not? (Remember that the signature is >> given by ghci itself) >> >> Finally it is not related to GHCi (we get the same errors/warnings when >> we compile) but to the AllowAmbiguousTypes extension: >> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?#extension-AllowAmbiguousTypes >> >> The type of "add" is ambiguous according to the definition in the manual. >> >> >> My advice would be to use a Functional dependency in your definition of >> NewType and then you can forget about ambiguous types, type applications, >> scoped type variables, etc. for now. The reported type of "add" by ghci >> becomes non-ambiguous and everything is well :) (and I guess that it was >> the point of the exercise) >> >> Regards, >> Sylvain >> >> >> >> Thanks again, >> Michel :) >> >> On Wed, Apr 10, 2019 at 1:28 PM Sylvain Henry wrote: >> >>> Hi, >>> >>> It looks like an effect of ExtendedDefaultRules: >>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#extension-ExtendedDefaultRules >>> >>> It's hard to tell without the code but maybe something like that will do: >>> >>> {-# LANGUAGE ScopedTypeVariables #-} >>> {-# LANGUAGE TypeApplications #-} >>> >>> add :: forall a b1 b2 b3. (Num a, Newtype a b1, Newtype a b2, Newtype a >>> b3) => b2 -> b3 -> b1 >>> add x y = wrap @a @b1 $ unwrap @a x + unwrap @a y >>> >>> -Sylvain >>> On 10/04/2019 12:32, Michel Haber wrote: >>> >>> Hello Cafe, >>> >>> I was trying to load a module containing this function in ghci: >>> "add x y = wrap $ unwrap x + unwrap y" >>> with the following extensions activated: >>> >>> ConstraintKinds >>> DataKinds >>> DeriveFunctor >>> DuplicateRecordFields >>> FlexibleContexts >>> FlexibleInstances >>> GADTs >>> KindSignatures >>> MultiParamTypeClasses >>> PolyKinds >>> TypeFamilies >>> TypeOperators >>> AllowAmbiguousTypes >>> >>> And it loaded without problem. >>> >>> So then I tested its type with ":t add", which gave: >>> add :: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) => b2 -> b3 -> >>> b1 >>> >>> Then I added this signature to the function in the module. This caused >>> ghci >>> to refuse to load it and give the following error: >>> >>> src/Exercises.hs:55:11: error: >>> • Could not deduce (Newtype Integer b1) >>> arising from a use of ‘wrap’ >>> from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >>> bound by the type signature for: >>> add :: forall a b1 b2 b3. >>> (Num a, Newtype a b1, Newtype a b2, Newtype a >>> b3) => >>> b2 -> b3 -> b1 >>> at src/Exercises.hs:54:1-74 >>> • In the expression: wrap $ unwrap x + unwrap y >>> In an equation for ‘add’: add x y = wrap $ unwrap x + unwrap y >>> | >>> 55 | add x y = wrap $ unwrap x + unwrap y >>> | ^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> src/Exercises.hs:55:18: error: >>> • Could not deduce (Newtype Integer b2) >>> arising from a use of ‘unwrap’ >>> from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >>> bound by the type signature for: >>> add :: forall a b1 b2 b3. >>> (Num a, Newtype a b1, Newtype a b2, Newtype a >>> b3) => >>> b2 -> b3 -> b1 >>> at src/Exercises.hs:54:1-74 >>> • In the first argument of ‘(+)’, namely ‘unwrap x’ >>> In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ >>> In the expression: wrap $ unwrap x + unwrap y >>> | >>> 55 | add x y = wrap $ unwrap x + unwrap y >>> | ^^^^^^^^ >>> >>> src/Exercises.hs:55:29: error: >>> • Could not deduce (Newtype Integer b3) >>> arising from a use of ‘unwrap’ >>> from the context: (Num a, Newtype a b1, Newtype a b2, Newtype a b3) >>> bound by the type signature for: >>> add :: forall a b1 b2 b3. >>> (Num a, Newtype a b1, Newtype a b2, Newtype a >>> b3) => >>> b2 -> b3 -> b1 >>> at src/Exercises.hs:54:1-74 >>> • In the second argument of ‘(+)’, namely ‘unwrap y’ >>> In the second argument of ‘($)’, namely ‘unwrap x + unwrap y’ >>> In the expression: wrap $ unwrap x + unwrap y >>> | >>> 55 | add x y = wrap $ unwrap x + unwrap y >>> | ^^^^^^^^ >>> Failed, no modules loaded. >>> >>> This does not make sense to me, since I only used the signature that >>> ghci itself gave me. >>> >>> Is this a bug? if not, could someone please explain this behaviour to me? >>> >>> Thanks, >>> Michel >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zocca.marco at gmail.com Thu Apr 11 06:30:20 2019 From: zocca.marco at gmail.com (Marco Zocca) Date: Thu, 11 Apr 2019 08:30:20 +0200 Subject: [Haskell-cafe] [CfP] Functional High-Performance and Numerical Computing 2019 Message-ID: ===================================================== Call for Papers (Extended Abstracts and Full Papers) ACM SIGPLAN Workshop on Functional High-Performance and Numerical Computing (FHPNC), Berlin, August 18, 2019 Satellite event of the 24th ACM SIGPLAN International Conference on Functional Programming (ICFP 2019) 18 - 23 August, 2019 ===================================================== https://icfp19.sigplan.org/home/FHPNC-2019#Call-for-Papers The ACM SIGPLAN International Workshop on Functional High-Performance and Numerical Computing aims to bring together researchers and practitioners exploring or employing the use of functional or declarative programming languages or techniques in scientific computing, and specifically in the domains of high-performance computing and numerical programming. The purpose of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative techniques can help make high-performance, distributed/parallel, or numerically-intensive code dealing with computationally challenging problems easier to write, read, maintain, or portable to new hardware architectures. Areas of interest include, but are not limited to: * relevant compiler technologies * runtime systems (including fault tolerance mechanisms and those supporting distributed or parallel computation) * domain-specific languages (embedded or standalone) * type systems * formal methods * software libraries (e.g. for exact or interval arithmetic). ## Submission details Submissions should fall into one of two categories: * Regular research papers (up to 12 pages) * Extended abstracts (1 - 2 pages) The bibliography will not be counted against the page limits for either category. Regular research papers are expected to present novel and interesting research results, and will be included in the formal proceedings. Extended abstracts should report work in progress that the authors would like to present at the workshop; they will be evaluated primarily for relevance and interest. Extended abstracts will be distributed to workshop attendees but will not be published in the formal proceedings. We welcome submissions from PC members (with the exception of the PC Chair), but these submissions will be held to a higher standard. Submission is handled through the HotCRP site. All submissions should be in portable document format (PDF) and formatted using the ACM SIGPLAN style guidelines. Submissions written with LaTeX are required to use the ‘acmart’ format and the two-column ‘sigplan’ subformat (not to be confused with the one-column ‘acmlarge’ subformat!). Extended Abstracts must be submitted with the label ‘Extended abstract’ clearly in the title. ## Publication The proceedings of FHPNC 2019 will be published in the ACM Digital Library. ## Related links * Author Information and LaTeX templates : http://www.sigplan.org/Resources/Author/ * Attendee Code of Conduct: http://www.sigplan.org/Resources/Policies/CodeOfConduct/ From j.stutterheim at me.com Thu Apr 11 12:29:19 2019 From: j.stutterheim at me.com (J. Stutterheim) Date: Thu, 11 Apr 2019 20:29:19 +0800 Subject: [Haskell-cafe] First Call for Papers for IFL 2019 (Implementation and Application of Functional Languages) Message-ID: <1AA93BC8-AA03-4539-8566-FC1CCE7FEA43@me.com> Dear all, Please, find below the first call for papers for IFL 2019. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. Best regards, Jurriën Stutterheim --- ================================================================================ IFL 2019 31st Symposium on Implementation and Application of Functional Languages National University of Singapore September 25th-27th, 2019 http://2019.iflconference.org ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2019 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Keynote Speaker * Olivier Danvy, Yale-NUS College ### Submissions and peer-review Differently from previous editions of IFL, IFL 2019 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2019. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication ### Important dates Submission of regular papers: May 31, 2019 Submission of draft papers: July 15, 2019 Regular and draft papers notification: August 1, 2019 Deadline for early registration: August 15, 2019 Submission of pre-proceedings version: September 15, 2019 IFL Symposium: September 25-27, 2019 Submission of papers for post-proceedings: November 30, 2019 Notification of acceptance: January 31, 2020 Camera-ready version: February 29, 2020 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2019 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organization and Program committee Chairs: Jurrien Stutterheim (Standard Chartered Bank Singapore), Wei Ngan Chin (National University of Singapore) Program Committee: - Olaf Chitil, University of Kent - Clemens Grelck, University of Amsterdam - Daisuke Kimura, The University of Tokyo - Pieter Koopman, Radboud University - Tamás Kozsik, Eötvös Loránd University - Roman Leschinskiy, Facebook - Ben Lippmeier, The University of New South Wales - Marco T. Morazan, Seton Hall University - Sven-Bodo Scholz, Heriot-Watt University - Tom Schrijvers, Katholieke Universiteit Leuven - Alejandro Serrano, Utrecht University - Tony Sloane, Macquarie University - Simon Thompson, University of Kent - Marcos Viera, Universidad de la República - Wei Ngan Chin, NUS - Jurriën Stutterheim, Standard Chartered Bank ### Venue The 30th IFL is organized by the University of Massachusetts Lowell. The City of Lowell is located at the heart of the Merrimack Valley just 30 miles northwest of Boston. Lowell can be easily reached by train or taxi. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2019 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences. From rae at richarde.dev Fri Apr 12 02:12:46 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 11 Apr 2019 22:12:46 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? Message-ID: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Hi café, Why are && and || in the Prelude right-associative? This contradicts my expectation and the way these work in other languages. That said, I can't think of any harm in it. This came up from a question asked by a student, and I have no idea why the design is this way. Thanks, Richard From ivanperezdominguez at gmail.com Fri Apr 12 02:26:44 2019 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Thu, 11 Apr 2019 22:26:44 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: Could it be so that you can shortcut in the expected order (left to right)? Left associative: a && b && c = (a && b) && c which means going into a && b, which means going into a, and if it is False, then going up in the expression tree. If it is right associative: a && b && c = a && (b && c), which means going into a, and if it is False, you are done. If you have a conjunction of n booleans, the complexity of evaluating this expression is linear with respect to the position of the first False (in the case of &&). In the left-associative case, it is linear in the number of &&s. Just a guess. But you got me interested now. Does anyone have the real explanation? Cheers, Ivan On Thu, 11 Apr 2019 at 22:13, Richard Eisenberg wrote: > Hi café, > > Why are && and || in the Prelude right-associative? This contradicts my > expectation and the way these work in other languages. That said, I can't > think of any harm in it. This came up from a question asked by a student, > and I have no idea why the design is this way. > > Thanks, > Richard > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Apr 12 02:29:12 2019 From: david.feuer at gmail.com (David Feuer) Date: Thu, 11 Apr 2019 22:29:12 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: I don't know the historical answer, but I think it's because the true fixity can't be expressed in Haskell. As far as I can tell, there's no operator with the same precedence as && or || that can be meaningfully combined with it. But if these operators were defined just "infix", then we'd have to write junk like x || (y || z). So instead we picked a direction out of a bag and never had a reason to look back. On Thu, Apr 11, 2019, 10:13 PM Richard Eisenberg wrote: > Hi café, > > Why are && and || in the Prelude right-associative? This contradicts my > expectation and the way these work in other languages. That said, I can't > think of any harm in it. This came up from a question asked by a student, > and I have no idea why the design is this way. > > Thanks, > Richard > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guy-laurent at subri.ch Fri Apr 12 04:40:34 2019 From: guy-laurent at subri.ch (Guy-Laurent Subri) Date: Fri, 12 Apr 2019 06:40:34 +0200 Subject: [Haskell-cafe] Newtype, Data.Text and instance declarations... Message-ID: <155504403410.16115.16800630542979552790@lennie> Hi all, There are a few things that I don't understand involving Data.Text and instance declarations... I'm building a small web app to practise Haskell and am using the SQLite.Simple library. I have defined a few types and functions like so: ''' data BookmarkDB = BookmarkDB Connection Table newtype Table = Table Text instance ToField Table where toField = SQLText initDB :: FilePath -> Table -> IO BookmarkDB initDB fp table = do let query = Query ("CREATE TABLE IF NOT EXISTS :table " <> " (url TEXT, tags TEXT, date INTEGER)") conn <- open fp executeNamed conn query [":table" := table] return $ BookmarkDB conn table ''' 1. My first question is about the instance declaration. Why would ''' instance ToField Table where toField = SQLText ''' return this error ? ''' Couldn't match type ‘Table’ with ‘Text’ Expected type: Table -> SQLData Actual type: Text -> SQLData • In the expression: SQLText In an equation for ‘toField’: toField = SQLText In the instance declaration for ‘ToField Table’ ''' I've noticed that if I write ''' instance ToField Table where toField (Table t) = SQLText t ''' I have no error and it compiles. I don't get it, what is 'toField' supposed to receive except a Table? 2. My second question is concerning the initDB function. If I write it that way, the code compiles, but I get an error during execution: bkmrk: SQLite3 returned ErrorError while attempting to perform prepare "CREATE TABLE IF NOT EXISTS :table (url TEXT, tags TEXT, date INTEGER)": near ":table": syntax error I don't understand what is wrong with the code and I doubt that my query is wrong because everything works with the last code snippet I wrote (see question #3). 3. Trying to get around the error I've noticed a few things. If I try to write this instead: ''' initDB :: FilePath -> Table -> IO BookmarkDB initDB fp table = do let query = Query ("CREATE TABLE IF NOT EXISTS " <> table <> " (url TEXT, tags TEXT, date INTEGER)") conn <- open fp execute_ conn query return $ BookmarkDB conn table ''' it doesn't compile because table is of type Table and not Data.Text.Internal.Text, which I get, but I don't know what is the Haskell way of resolving this. I've also noticed that this will help: ''' initDB :: FilePath -> Table -> IO BookmarkDB initDB fp t@(Table table) = do let query = Query ("CREATE TABLE IF NOT EXISTS " <> table <> " (url TEXT, tags TEXT, date INTEGER)") conn <- open fp execute_ conn query return $ BookmarkDB conn t ''' But I *really* don't get why! The most confusing part for me is that the last initDB function will do exactly what I want it to do, but I am unable to understand why it works...Why am I able to concatenate the 'table' now and not before and why is 't' of a different type than 'table'? All of this is very confusing and I find myself unable to reason about it. Sorry if this is a big/messy question. I hope everything is clear enough to answer... Thank you all! From jo at durchholz.org Fri Apr 12 04:42:33 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 12 Apr 2019 06:42:33 +0200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: <2d1a0b3f-1188-734b-ceab-ec3e45503a9a@durchholz.org> Am 12.04.19 um 04:26 schrieb Ivan Perez: > Could it be so that you can shortcut in the expected order (left to right)? > > Left associative: > a && b && c = (a && b) && c which means going into a && b, which means > going into a, and if it is False, then going up in the expression tree. For compile-time evaluation of known-to-be-constant values, this is what would indeed happen, but it wouldn't matter because such evaluation is done O(1) times. Generated code will simply evaluate the conditions one after the other and abort as soon as it sees False. > If you have a conjunction of n booleans, the complexity of evaluating > this expression is linear with respect to the position of the first > False (in the case of &&). In the left-associative case, it is linear > in the number of &&s. This isn't the case. From allbery.b at gmail.com Fri Apr 12 04:59:44 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 12 Apr 2019 00:59:44 -0400 Subject: [Haskell-cafe] Newtype, Data.Text and instance declarations... In-Reply-To: <155504403410.16115.16800630542979552790@lennie> References: <155504403410.16115.16800630542979552790@lennie> Message-ID: On Fri, Apr 12, 2019 at 12:42 AM Guy-Laurent Subri wrote: > I've noticed that if I write > ''' > instance ToField Table where > toField (Table t) = SQLText t > ''' > > I have no error and it compiles. I don't get it, what is 'toField' > supposed to receive except a Table? > Haskell does not automatically "convert" types. If something wants a Text, it will not accept a Table, even though that Table is just a wrapper around a Text. You must unwrap it to get the Text inside, which is what the (Table t) pattern is doing: matches a Table by its constructor, and gives you the contained Text bound to "t". This is somewhat more obvious when you have a type with multiple fields, or with multiple constructors, since pattern matching then lets you access all the fields, and you can have multiple patterns matching different constructors. data Foo = Foo Int Text someFoo (Foo i t) = -- do something with the Int i and Text t here data Foo = FooI Int | FooT Text someFoo (FooI i) = -- do something with the Int i here someFoo (FooT t) = -- do something with the Text t here (You can of course also combine them, multiple constructors each with zero or more fields.) 2. My second question is concerning the initDB function. If I write it > that way, the code compiles, but I get an error during execution: > > bkmrk: SQLite3 returned ErrorError while attempting to perform prepare > "CREATE TABLE IF NOT EXISTS :table (url TEXT, tags TEXT, date > INTEGER)": near ":table": syntax error > > I don't understand what is wrong with the code and I doubt that my query > is wrong because everything works with the last code snippet I wrote > (see question #3). > In general, you can't use that kind of substitution with SQL Data Definition Language (e.g. CREATE TABLE), nor is it generally usable to replace table or column names, only values. You need to concatenate the actual table name into the command, not a SQL string-like value nor an embedded SQL placeholder. 3. Trying to get around the error I've noticed a few things. If I try to > write this instead: > > ''' > initDB :: FilePath -> Table -> IO BookmarkDB > initDB fp table = do > let query = Query ("CREATE TABLE IF NOT EXISTS " <> table > <> " (url TEXT, tags TEXT, date INTEGER)") > conn <- open fp > execute_ conn query > return $ BookmarkDB conn table > ''' > > it doesn't compile because table is of type Table and not > Data.Text.Internal.Text, which I get, but I don't know what is the > Haskell way of resolving this. > Same as your first question: initDB fp t@(Table table) = do -- which unwraps the Table and gives you the Text within it as "table". But you also need the actual Table value, since you use it in the last line of your function, so you also need the as-pattern. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From guy-laurent at subri.ch Fri Apr 12 05:12:28 2019 From: guy-laurent at subri.ch (Guy-Laurent Subri) Date: Fri, 12 Apr 2019 07:12:28 +0200 Subject: [Haskell-cafe] Newtype, Data.Text and instance declarations... In-Reply-To: References: <155504403410.16115.16800630542979552790@lennie> Message-ID: <155504594889.16115.8866681377412674596@lennie> Thank you, it makes perfect sense now. I don't know why I got confused with the pattern matching. Maybe it just looked like casting and I got the types wrong. > In general, you can't use that kind of substitution with SQL Data Definition Language (e.g. CREATE > TABLE), nor is it generally usable to replace table or column names, only values. You need to > concatenate the actual table name into the command, not a SQL string-like value nor an embedded SQL > placeholder. I didn't know that. Thank you. -- Guy-Laurent Subri From lysxia at gmail.com Fri Apr 12 06:48:39 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Fri, 12 Apr 2019 08:48:39 +0200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <2d1a0b3f-1188-734b-ceab-ec3e45503a9a@durchholz.org> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> <2d1a0b3f-1188-734b-ceab-ec3e45503a9a@durchholz.org> Message-ID: On 4/12/19 6:42 AM, Joachim Durchholz wrote: > > Am 12.04.19 um 04:26 schrieb Ivan Perez: >> Could it be so that you can shortcut in the expected order (left to >> right)? >> >> Left associative: >> a && b && c = (a && b) && c which means going into a && b, which means >> going into a, and if it is False, then going up in the expression tree. > > For compile-time evaluation of known-to-be-constant values, this is what > would indeed happen, but it wouldn't matter because such evaluation is > done O(1) times. > Generated code will simply evaluate the conditions one after the other > and abort as soon as it sees False. > >> If you have a conjunction of n booleans, the complexity of evaluating >> this expression is linear with respect to the position of the first >> False (in the case of &&). In the left-associative case, it is linear >> in the number of &&s. > This isn't the case. The program below is evidence that it *is* the case: the way the expression is associated has an effect on run time. Adding more (&&) in the condition of the following function doesn't change the run time, but substituting the infixl variant (&.) does result in a measurable growth linear in the number of (&.). Of course, this is true only without optimizations, but the distinction is there, and many people do not have intuition about what is and isn't optimized by GHC, so this is certainly a worthwhile point of discussion. Li-yao import Control.Monad f :: Bool -> IO () f b = if b && True -- 9 more && True && True && True && True && True && True && True && True then error "oops" else return () (&.) :: Bool -> Bool -> Bool (&.) = (&&) infixl 1 &. main :: IO () main = do mapM_ f (replicate 1000000 False) From jon.fairbairn at cl.cam.ac.uk Fri Apr 12 09:08:04 2019 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Fri, 12 Apr 2019 10:08:04 +0100 Subject: [Haskell-cafe] Why are && and || right-associative? References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: David Feuer writes: > I don't know the historical answer, but I think it's because the true > fixity can't be expressed in Haskell. No, the historical answer is that with lazy evaluation the shortcutting happens in the expected order. We did think about that. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk From raoknz at gmail.com Fri Apr 12 09:21:03 2019 From: raoknz at gmail.com (Richard O'Keefe) Date: Fri, 12 Apr 2019 21:21:03 +1200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: How does the right associativity of the short-circuiting Boolean operators in any way contradict the way that such operators work in other languages? These operators are associative, so a && (b && c) necessarily has the same value and effects as (a && b) && c. It has never been the case that all operators in all programming languages were left associative. For addition and subtraction it matters; you don't want a-b+c interpreted as a-(b+c), but not for || and not for &&. My expectation is that these operators should be right associative. On Fri, 12 Apr 2019 at 14:13, Richard Eisenberg wrote: > Hi café, > > Why are && and || in the Prelude right-associative? This contradicts my > expectation and the way these work in other languages. That said, I can't > think of any harm in it. This came up from a question asked by a student, > and I have no idea why the design is this way. > > Thanks, > Richard > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Fri Apr 12 09:44:33 2019 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 12 Apr 2019 05:44:33 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: Correct me if I'm wrong here. On Fri, 12 Apr 2019 at 05:21, Richard O'Keefe wrote: > How does the right associativity of the short-circuiting > Boolean operators in any way contradict the way that such operators work > in other languages? These operators are associative, so a && (b && c) > necessarily has the same value and effects as (a && b) && c. > In pure Haskell, perhaps, but in other languages, I would say no. In a language like C, I would expect that: - a && b && c be represented in the AST as (a && b) && c - The compiler optimizes the implementation of && to short circuit, which is, in some way, using laziness. This is not to say that they are right-associative; it's just a compiler optimization. > It has never been the case that all operators in all programming > languages were left associative. For addition and subtraction it matters; > you don't want a-b+c interpreted as a-(b+c), but not for || and not for > &&. My expectation is that these operators should be right associative. > I can't find any reference for logic itself and, because /\ is introduced as associative from the start in propositional logic, it does not really matter. However, my training as a kid in math and the exposure to how I studied to solve (+) left to right (implicitly associating to the left) would have led me to intuitively parse / parenthesize conjunctions with multiple (&&) the same way unless instructed otherwise. I think this portion of the Haskell Report is also relevant to this intuition in the case of haskell programmers: "If no fixity declaration is given for `op` then it defaults to highest precedence and left associativity" (Section 4.4.2). Cheers Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Fri Apr 12 09:47:15 2019 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 12 Apr 2019 05:47:15 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: > > > I think this portion of the Haskell Report is also relevant to this > intuition in the case of haskell programmers: "If no fixity declaration is > given for `op` then it defaults to highest precedence and left > associativity" (Section 4.4.2). > Sorry, this is from section 3.2. Section 4.4.2 goes on to say: "Any operator lacking a fixity declaration is assumed to be infixl 9" Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From komendantskaya at gmail.com Fri Apr 12 10:29:49 2019 From: komendantskaya at gmail.com (Ekaterina Komendantskaya) Date: Fri, 12 Apr 2019 11:29:49 +0100 Subject: [Haskell-cafe] PPDP'19 Final CFP Message-ID: FINAL CALL FOR PAPERS -- PPDP 2019 21st International Symposium on Principles and Practice of Declarative Programming 7–9 October 2019, Porto, Portugal Collocated with FM'19 http://ppdp2019.macs.hw.ac.uk ====================================================================== Important Dates --------------- Title and abstract registration 26 April 2019 (AoE) Paper submission 3 May 2019 (AoE) Rebuttal period (48 hours) 3 June 2019 (AoE) Author notification 14 June 2019 Final paper version 15 July 2019 Conference 7–9 October 2019 About PPDP ---------- The PPDP 2019 symposium brings together researchers from the declarative programming communities, including those working in the functional, logic, answer-set, and constraint handling programming paradigms. The goal is to stimulate research in the use of logical formalisms and methods for analyzing, performing, specifying, and reasoning about computations, including mechanisms for concurrency, security, static analysis, and verification. Invited Speakers ---------------- Amal Ahmed Northeastern University, USA Title: TBA Naoki Kobayashi The University of Tokyo, Japan Title: 10 Years of the Higher-Order Model Checking Project Scope ----- Submissions are invited on all topics related to declarative programming, from principles to practice, from foundations to applications. Topics of interest include, but are not limited to - Language Design: domain-specific languages; interoperability; concurrency, parallelism and distribution; modules; probabilistic languages; functional languages; reactive languages; database languages; knowledge representation languages; languages with objects; language extensions for tabulation; metaprogramming. - Implementations: abstract machines; interpreters; compilation; compile-time and run-time optimization; memory management. - Foundations: types; logical frameworks; monads and effects; semantics. - Analysis and Transformation: partial evaluation; abstract interpretation; control flow; data flow; information flow; termination analysis; resource analysis; type inference and type checking; verification; validation; debugging; testing. - Tools and Applications: programming and proof environments; verification tools; case studies in proof assistants or interactive theorem provers; certification; novel applications of declarative programming inside and outside of CS; declarative programming pearls; practical experience reports and industrial application; education. For further information, please visit: http://ppdp2019.macs.hw.ac.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Fri Apr 12 14:47:27 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 12 Apr 2019 10:47:27 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: <23E32FEE-142D-4A76-9F81-9DC1F760DDCF@richarde.dev> > On Apr 12, 2019, at 5:21 AM, Richard O'Keefe wrote: > > How does the right associativity of the short-circuiting > Boolean operators in any way contradict the way that such operators work in other languages? If you look at definitions of other languages (C, Java), you see that the operators are defined to be left-associative. Perhaps those other languages got it wrong, then. :) In any case, this conversation has been illuminating. Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil_mayhew at users.sourceforge.net Fri Apr 12 18:43:54 2019 From: neil_mayhew at users.sourceforge.net (Neil Mayhew) Date: Fri, 12 Apr 2019 12:43:54 -0600 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <23E32FEE-142D-4A76-9F81-9DC1F760DDCF@richarde.dev> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> <23E32FEE-142D-4A76-9F81-9DC1F760DDCF@richarde.dev> Message-ID: On 2019-04-12 8:47 AM, Richard Eisenberg wrote: > Perhaps those other languages got it wrong, then. :) I don't think so. It's just that short-circuit evaluation isn't a direct consequence of associativity in those languages because they're otherwise strict and this is an exception to their default semantics. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Fri Apr 12 19:15:36 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 12 Apr 2019 21:15:36 +0200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: <55d4f487-3bb1-d9df-cc1d-9c0481bae504@durchholz.org> Am 12.04.19 um 11:21 schrieb Richard O'Keefe: > It has > never been the case that all operators in all programming languages were > left associative.  For addition and subtraction it matters; you don't > want a-b+c interpreted as a-(b+c), but not for || and not for &&.  My > expectation is that these operators should be right associative. What is the basis for this expectation? My expectation would be left associativity, just because I read stuff from left to right, and left associativity is what I get if I mentally parse from left to right. So I'm curious what thought process arrives at the opposite expectation. Regards, Jo From ietf-dane at dukhovni.org Fri Apr 12 23:16:12 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Apr 2019 19:16:12 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <55d4f487-3bb1-d9df-cc1d-9c0481bae504@durchholz.org> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> <55d4f487-3bb1-d9df-cc1d-9c0481bae504@durchholz.org> Message-ID: <4E1A5545-36B8-4EA6-9F97-0677F65D4215@dukhovni.org> > On Apr 12, 2019, at 3:15 PM, Joachim Durchholz wrote: > > What is the basis for this expectation? > My expectation would be left associativity, just because I read stuff from left to right, and left associativity is what I get if I mentally parse from left to right. > So I'm curious what thought process arrives at the opposite expectation. Since (&&) short-circuits on first failure, and (||) short-circuits on first success, right associativity is more intuitive: a && b && c == a && (b && c) a || b || c == a || (b || c) as each can stop immediately when `a` is respectively False or True. This matches the fact that (&&) is naturally strict in its first argument and and lazy in the second, which works well with currying. Also consider that, for example, in "ghci": foldr (&&) True (replicate 100000000000 False) returns immediately, while: foldr (&&) True (replicate 100000000000 False) hangs, which clearly shows that right folds are the more natural way to combine these boolean operators. And reading left to right, *is* IMHO right associative! You see: a || ... and immediately process a, then move on to what follows. When reading an English sentence, you don't have to reach the last word before you can start to make sense of the preceding words, for left associativity, try German... [ Oops! Never mind, perhaps that explains the difference in perspective. :-) :-) ] -- Viktor. From monnier at iro.umontreal.ca Fri Apr 12 23:32:34 2019 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Fri, 12 Apr 2019 19:32:34 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: >> I don't know the historical answer, but I think it's because the true >> fixity can't be expressed in Haskell. > No, the historical answer is that with lazy evaluation the > shortcutting happens in the expected order. We did think about > that. I don't understand how laziness enters the picture: (False && ⊥) && ⊥ ≡ False False && (⊥ && ⊥) ≡ False in both cases we get the same result. Stefan From allbery.b at gmail.com Fri Apr 12 23:35:05 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 12 Apr 2019 19:35:05 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: Er? Without laziness, you're going to try to evaluate the bottoms regardless of where they are. Or are you asserting that the short-circuiting done by many strict languages is their standard evaluation model? On Fri, Apr 12, 2019 at 7:32 PM Stefan Monnier wrote: > >> I don't know the historical answer, but I think it's because the true > >> fixity can't be expressed in Haskell. > > No, the historical answer is that with lazy evaluation the > > shortcutting happens in the expected order. We did think about > > that. > > I don't understand how laziness enters the picture: > > (False && ⊥) && ⊥ ≡ False > False && (⊥ && ⊥) ≡ False > > in both cases we get the same result. > > > Stefan > > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From monnier at IRO.UMontreal.CA Fri Apr 12 23:52:02 2019 From: monnier at IRO.UMontreal.CA (Stefan Monnier) Date: Fri, 12 Apr 2019 19:52:02 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: (Brandon Allbery's message of "Fri, 12 Apr 2019 19:35:05 -0400") References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: > Er? Without laziness, you're going to try to evaluate the bottoms > regardless of where they are. Exactly: with lazyness, either associativity gives the same result, and without lazyness either associativity also gives the same result. The two seem orthogonal to me. Stefan From tanuki at gmail.com Sat Apr 13 01:19:19 2019 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Fri, 12 Apr 2019 18:19:19 -0700 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: I think Brandon's point is that short-circuiting is in fact an example of lazy evaluation, regardless of the language being otherwise strict. On Fri, Apr 12, 2019, 4:52 PM Stefan Monnier wrote: > > Er? Without laziness, you're going to try to evaluate the bottoms > > regardless of where they are. > > Exactly: with lazyness, either associativity gives the same result, > and without lazyness either associativity also gives the same result. > The two seem orthogonal to me. > > > Stefan > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Apr 13 01:47:57 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 12 Apr 2019 21:47:57 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: Exactly. Short-circuiting is emulating laziness in this one case where it turns out to be generally useful. And while (_|_ && _|_) may be evaluatable from a logical standpoint, computer languages tend to not do well with it: regardless of how it evaluates, (&&) is going to try to force at least one of the bottoms. On Fri, Apr 12, 2019 at 9:19 PM Theodore Lief Gannon wrote: > I think Brandon's point is that short-circuiting is in fact an example of > lazy evaluation, regardless of the language being otherwise strict. > > On Fri, Apr 12, 2019, 4:52 PM Stefan Monnier > wrote: > >> > Er? Without laziness, you're going to try to evaluate the bottoms >> > regardless of where they are. >> >> Exactly: with lazyness, either associativity gives the same result, >> and without lazyness either associativity also gives the same result. >> The two seem orthogonal to me. >> >> >> Stefan >> _______________________________________________ >> 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From monnier at iro.umontreal.ca Sat Apr 13 02:28:07 2019 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Fri, 12 Apr 2019 22:28:07 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: > I think Brandon's point is that short-circuiting is in fact an example of > lazy evaluation, regardless of the language being otherwise strict. Sure, call it "short-circuiting", my comment stays the same: in which way is it related to *associativity*? In terms of semantics, all three (++), (||), and (&&) are associative AFAICT, so the choice of which associativity to use in the syntax is not related to the semantics (instead it's likely related to secondary concerns like efficiency). Stefan From ryan.reich at gmail.com Sat Apr 13 03:21:34 2019 From: ryan.reich at gmail.com (Ryan Reich) Date: Fri, 12 Apr 2019 20:21:34 -0700 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: > I don't understand how laziness enters the picture: > > (False && ⊥) && ⊥ ≡ False > False && (⊥ && ⊥) ≡ False > > in both cases we get the same result. > The first expression builds two thunks before trying the leftmost operand, and the second one only builds one thunk. More generally, a left-associative conjunction of n lazy Bools will build n - 1 thunks at once when forced, but a right-associative one will have only one at a time, though it may have to iterate through all n - 1 before finishing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz at gmail.com Sat Apr 13 10:14:11 2019 From: raoknz at gmail.com (Richard O'Keefe) Date: Sat, 13 Apr 2019 22:14:11 +1200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: I repeat: the short circuit operations are associative, so a && (b && c) necessarily has the same value and effects as (a && b) && c. And this is just as true in C as in Haskell. It is equally true in SML and Erlang (which use andalso and orelse), Pascal Extended and Ada, OCaml and F#, and Unix shells, to mention but a few. Because the operations are associative, the associativity of the operators is of no interest. Associativity is of interest only when (a) there is more than one operator at the same precedence level or (b) the operation is not associative. Your "training as a kid in math" almost certainly did not include any discussion of logical operators, and I would be astonished if you had been told that a ** b ** c was defined to be a ** (b ** c) back in 1950-something, or that there is a famous programming language where A-B-C-D means A-(B-(C-D)) that is nearly as old. Your "training as a kid in math" probably did not include operators which are neither left associative nor right associative but have a hidden conjunction, e.g., a <= b < c does not, in a sane programming language (that is, a language that is *not* C and didn't copy its blunders), means a <= b && b < c (unless it is a syntax error). Ada and SETLX do something interesting. They put conjunction and disjunction at the same level, refuse to define an associativity for them, and forbid mixing them. That is, 'p and then q or else r' is simply not legal in Ada. Programming languages have done more and weirder things with operators than you imagine. Take nothing for granted. On Fri, 12 Apr 2019 at 21:45, Ivan Perez wrote: > Correct me if I'm wrong here. > > On Fri, 12 Apr 2019 at 05:21, Richard O'Keefe wrote: > >> How does the right associativity of the short-circuiting >> Boolean operators in any way contradict the way that such operators work >> in other languages? These operators are associative, so a && (b && c) >> necessarily has the same value and effects as (a && b) && c. >> > > In pure Haskell, perhaps, but in other languages, I would say no. > > In a language like C, I would expect that: > - a && b && c be represented in the AST as (a && b) && c > - The compiler optimizes the implementation of && to short circuit, which > is, in some way, using laziness. > > This is not to say that they are right-associative; it's just a compiler > optimization. > > >> It has never been the case that all operators in all programming >> languages were left associative. For addition and subtraction it matters; >> you don't want a-b+c interpreted as a-(b+c), but not for || and not for >> &&. My expectation is that these operators should be right associative. >> > > I can't find any reference for logic itself and, because /\ is introduced > as associative from the start in propositional logic, it does not really > matter. However, my training as a kid in math and the exposure to how I > studied to solve (+) left to right (implicitly associating to the left) > would have led me to intuitively parse / parenthesize conjunctions with > multiple (&&) the same way unless instructed otherwise. > > I think this portion of the Haskell Report is also relevant to this > intuition in the case of haskell programmers: "If no fixity declaration is > given for `op` then it defaults to highest precedence and left > associativity" (Section 4.4.2). > > Cheers > > Ivan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Sat Apr 13 10:38:59 2019 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sat, 13 Apr 2019 06:38:59 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: > > Your "training as a kid in math" almost certainly did not > include any discussion of logical operators, and I would > be astonished if you had been told that > a ** b ** c > was defined to be > a ** (b ** c) > back in 1950-something, or that there is a famous programming > language where A-B-C-D means A-(B-(C-D)) that is nearly as > old. > This is clearly not what I said. Also, I never implied my training to be 'special'. I'm sure people were taught math similarly. Finally, and very important: I would like to ask that you stop speculating about what I did or did not learn, or when, to try and keep this civil, and focus on the technical discussion, and not the people. Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sat Apr 13 12:25:02 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 13 Apr 2019 14:25:02 +0200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <4E1A5545-36B8-4EA6-9F97-0677F65D4215@dukhovni.org> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> <55d4f487-3bb1-d9df-cc1d-9c0481bae504@durchholz.org> <4E1A5545-36B8-4EA6-9F97-0677F65D4215@dukhovni.org> Message-ID: <62caef1a-0855-299c-06cd-b5a2447de394@durchholz.org> Am 13.04.19 um 01:16 schrieb Viktor Dukhovni: >> On Apr 12, 2019, at 3:15 PM, Joachim Durchholz wrote: >> >> What is the basis for this expectation? >> My expectation would be left associativity, just because I read stuff from left to right, and left associativity is what I get if I mentally parse from left to right. >> So I'm curious what thought process arrives at the opposite expectation. > > Since (&&) short-circuits on first failure, and (||) short-circuits on > first success, right associativity is more intuitive: > > a && b && c == a && (b && c) > a || b || c == a || (b || c) > > as each can stop immediately when `a` is respectively False or True. > This matches the fact that (&&) is naturally strict in its first argument > and and lazy in the second, which works well with currying. I guess my intuition is more based on math, where associativity is an irrelevant detail, then LR parsing, where left associativity requires less stack work. BTW I have a feeling that the LR parsing process is pretty natural: we read symbols from left to right, mentally combining them into groups as soon as possible so we can abstract away from individual symbols. > Also consider that, for example, in "ghci": > > foldr (&&) True (replicate 100000000000 False) > > returns immediately, while: > > foldr (&&) True (replicate 100000000000 False) > > hangs, which clearly shows that right folds are the more > natural way to combine these boolean operators. That's a Haskellism. Not that anything is wrong with that, of course :-) > And reading left to right, *is* IMHO right associative! You > see: > > a || ... > > and immediately process a, then move on to what follows. No, you see a || ... but you don't process anything, there's just a and ||. Then you see a || b ... but you still don't know what to do with that, because maybe the next operator has higher precedence (maybe &&, maybe even + or *). Then you see a || b || ... and now you can tick off the first three symbols: whatever || ... where somewhere back in your mind, whatever === a || b. > When reading an English sentence, you don't have to reach > the last word before you can start to make sense of the > preceding words, for left associativity, try German... > > [ Oops! Never mind, perhaps that explains the difference > in perspective. :-) :-) ] Don't worry :-) Though I don't think that natural language processing works at any conscious level, so I don't think that that influence is too important. I German were the main influence, I would have to insist on postfix btw. From jo at durchholz.org Sat Apr 13 12:29:06 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 13 Apr 2019 14:29:06 +0200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: Am 13.04.19 um 12:14 schrieb Richard O'Keefe: > I would > be astonished if you had been told that >    a ** b ** c > was defined to be >    a ** (b ** c) > back in 1950-something, Actually we were told, with the reasoning that (a ** b) ** c is the same as a ** (b * c), I recall that that was presented as "nothing new there so not worth defining it that way). Truth be told, that was the 1970-something for me. From jerzy.karczmarczuk at unicaen.fr Sat Apr 13 13:34:53 2019 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Sat, 13 Apr 2019 15:34:53 +0200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> Message-ID: <49946f2c-0067-28cc-3225-e076f0d810a1@unicaen.fr> Le 13/04/2019 à 14:29, Joachim Durchholz cites Richard O'Keefe : >> I would >> be astonished if you had been told that >>     a ** b ** c >> was defined to be >>     a ** (b ** c) >> back in 1950-something, > > Actually we were told, with the reasoning that (a ** b) ** c is the > same as a ** (b * c), I recall that that was presented as "nothing new > there so not worth defining it that way). > > Truth be told, that was the 1970-something for me. '70?? Even worse... I began my school in '50-something, and I was duly taught that. And without "nothing new here", which I find rather unpleasantly surprising. My teacher pointed out that (a**b)**c is equal to a**(b*c), so the left associativity would not be extremely clever. Joachim says in his previous posting: > I guess my intuition is more based on math, where associativity is an > irrelevant detail Now, this is for me a *REALLY* peculiar vision of math. Irrelevant detail?? Where? In the categorical calculus perhaps? Abandon the associativity of morphisms, and you will see... In Lie algebras maybe? Well, add the associativity to it, and kill all the quantum theory. Good luck. There are many people, mainly young (e.g. my students) who have a tendency to "see mathematics" through "computer lenses" - parsing, implementable data structures, recursion as an implementation detail, etc. For the mathematical culture this is harmful. Jerzy Karczmarczuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sat Apr 13 15:22:42 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 13 Apr 2019 17:22:42 +0200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <49946f2c-0067-28cc-3225-e076f0d810a1@unicaen.fr> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> <49946f2c-0067-28cc-3225-e076f0d810a1@unicaen.fr> Message-ID: <61ee53e4-45db-b02d-ce82-9c358d3d91ba@durchholz.org> Am 13.04.19 um 15:34 schrieb Jerzy Karczmarczuk: > Joachim says in his previous posting: > >> I guess my intuition is more based on math, where associativity is an >> irrelevant detail > Now, this is for me a *REALLY* peculiar vision of math. Irrelevant > detail?? Please look at the context: This is about left vs. right associativity (the parsing property). Which is irrelevant if the operator is associative (the algebraic property). Regards, Jo From alexey.raga at gmail.com Mon Apr 15 11:24:46 2019 From: alexey.raga at gmail.com (Alexey Raga) Date: Mon, 15 Apr 2019 21:24:46 +1000 Subject: [Haskell-cafe] When does ICFP open registration? Message-ID: Hello, For bureaucracy reasons, it may be a time in our company to start sorting out ICFP trips/tickets. Does anyone have any information about when the registration may be opening? I couldn't find anything on their website, and I couldn't find any contact details on that website either, so asking here just in case if anyone knows :) Best Regards, Alexey Raga -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Mon Apr 15 12:19:06 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Mon, 15 Apr 2019 12:19:06 +0000 Subject: [Haskell-cafe] shake and cmd argument dependency Message-ID: Hello, I am writting a program which execute some scientific task via shake. liftIO $ shake shakeOptions{ shakeFiles=shakeFiles' , shakeReport=["/tmp/shake.html"] , shakeVerbosity=Diagnostic} $ do want [toFilePath uploaded] -- execute xdsme and deal with input dependencies toFilePath xml %> \_out -> do need (map toFilePath is) processXdsMe cwd' cell sg mr mo rdir images -- upload the result into the Databse toFilePath uploaded %> \_out -> actionXml xml b c uploaded processXdsMe :: Path Abs Dir -> Maybe Cell -> Maybe SpaceGroup -> Maybe Resolution -> Maybe Optimize -> Path Rel File -> String -> Action () processXdsMe cwd' mcell msg mr mo rdir images = cmd opts args where opts :: [CmdOption] opts = px1Opts ++ [Cwd . fromAbsDir $ cwd', AutoDeps] args = xdsMePath : catMaybes params params :: [Maybe String] params = [ Just "--brute" , Just "--weak" , Just "--xml" , Just ("-p" ++ fromRelFile rdir) , fmap (\(Cell a b c alpha beta gamma) -> printf "-c%f,%f,%f,%f,%f,%f" a b c alpha beta gamma) mcell , fmap (\sg -> "-s" ++ unpack sg) msg , fmap (\(Resolution r) -> printf "--resolution %f" r) mr , fmap (\o -> printf "--optimize %d" (fromEnum o)) mo , Just images ] actionXml :: Path Abs File -> Beamline -> SomeDataCollection -> Path Abs File -> Action () actionXml xml b c uploaded = do need [toFilePath xml] container <- liftIO . fromFile . toFilePath $ xml -- post processing let attachment = _autoProcProgramAttachment . _autoProcProgramContainer $ container attachment' <- liftIO $ runReaderT (toRuchePath attachment) b _ <- copyAttachment' attachment attachment' let container' = (autoProcProgramContainer . autoProcProgramAttachment .~ attachment') container -- replace attachement -- upload into ISPYB liftIO $ storeAutoProcIntoISPyB c NoAnomalous container' cmd_ ("touch" :: String) (toFilePath uploaded) My users want to change the arguments in the processXdsMe cmd args. How can I teach shake to rebuild a rules when the argument of the cmd change ? thanks for your help. Cheers From a.pelenitsyn at gmail.com Mon Apr 15 16:10:19 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Mon, 15 Apr 2019 12:10:19 -0400 Subject: [Haskell-cafe] When does ICFP open registration? In-Reply-To: References: Message-ID: Hello Alexey, A reasonable way to go about that is to contact the general chair Derek Dreyer (dreyer at mpi-sws.org) and the publicity chair Sam Tobin-Hochstadt ( samth at cs.indiana.edu). -- Best, Artem понедельник, 15 апреля 2019 г. пользователь Alexey Raga < alexey.raga at gmail.com> написал: > Hello, > > For bureaucracy reasons, it may be a time in our company to start sorting > out ICFP trips/tickets. > Does anyone have any information about when the registration may be > opening? > > I couldn't find anything on their website, and I couldn't find any contact > details on that website either, so asking here just in case if anyone knows > :) > > Best Regards, > Alexey Raga > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mightybyte at gmail.com Tue Apr 16 18:36:31 2019 From: mightybyte at gmail.com (MightyByte) Date: Tue, 16 Apr 2019 18:36:31 +0000 Subject: [Haskell-cafe] Compose Conference tickets are now available Message-ID: I'm pleased to announce that ticket sales are now open for both the New York Compose Conference and Unconference happening June 22 - 25. See our website for more details: http://www.composeconference.org/ There is one week left until the talk submission deadline. So, if you would like to submit a talk, make sure you get it in before April 23 at 11:59PM EDT. Part of our mission is to be as open and inclusive as possible. To support this, we have a limited number of volunteer tickets available if you would like to attend but the ticket price is an obstacle for you. Email us at nyc at composeconference.org with some information about you, your situation, and what you would like to get out of the conference and we will work with you. Sent via Superhuman ( https://sprh.mn/?vip=mightybyte at gmail.com ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Wed Apr 17 04:39:33 2019 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 17 Apr 2019 13:39:33 +0900 (JST) Subject: [Haskell-cafe] GHC 8.8 and MonadFail proposal Message-ID: <20190417.133933.603521466026846438.kazu@iij.ad.jp> Hello, I built the GHC 8.8 branch and tried to use it. I was very surprised because many packages cannot be built due to the removal of the "fail" method from the Monad typeclass. GHC 8.6 (with -Wcompat) does not warn even if "fail" is defined. I had no chance to notice this change. Isn't this change too radical? The same thing happened in GHC 8.4 due to Semigroup. I could not notice this change beforehand because I did not know the "-Wcompat" option. In my opinion, we should have included "-Wcampat" in "-Wall". Anyway, if I understand correctly, "-Wcompat" does not help in the MonadFail case. I'm a fan of both proposal. But I feel that no period of warnings is not a good approach. --Kazu From branimir.maksimovic at gmail.com Wed Apr 17 04:47:41 2019 From: branimir.maksimovic at gmail.com (Branimir Maksimovic) Date: Wed, 17 Apr 2019 06:47:41 +0200 Subject: [Haskell-cafe] GHC 8.8 and MonadFail proposal In-Reply-To: <20190417.133933.603521466026846438.kazu@iij.ad.jp> References: <20190417.133933.603521466026846438.kazu@iij.ad.jp> Message-ID: <12cf9641-050b-b8fb-18ae-cbd2055a5c27@gmail.com> That's always like that. I build packages from git in such cases. You remind me to build new ghc now ;) Greets! On 4/17/19 6:39 AM, Kazu Yamamoto (山本和彦) wrote: > Hello, > > I built the GHC 8.8 branch and tried to use it. I was very surprised > because many packages cannot be built due to the removal of the "fail" > method from the Monad typeclass. > > GHC 8.6 (with -Wcompat) does not warn even if "fail" is defined. I > had no chance to notice this change. Isn't this change too radical? > > The same thing happened in GHC 8.4 due to Semigroup. I could not > notice this change beforehand because I did not know the "-Wcompat" > option. In my opinion, we should have included "-Wcampat" in "-Wall". > > Anyway, if I understand correctly, "-Wcompat" does not help in > the MonadFail case. > > I'm a fan of both proposal. But I feel that no period of warnings > is not a good approach. > > --Kazu > _______________________________________________ > 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. From magicloud.magiclouds at gmail.com Wed Apr 17 09:29:20 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Wed, 17 Apr 2019 17:29:20 +0800 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? Message-ID: Hi, I saw this function in some web tools, pretty useful when parsing log or so. So I wonder if Haskell has similar libs already. Sample: Input line: "2019/04/17 17:27 User magicloud runs command ls." Pattern: "${year}/${month}/${day} ${hour}:${minute} User ${username} runs command ${command}." Output: toList [ ("year", "2019"), ("month", "04") , etc ] -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From simons at nospf.cryp.to Wed Apr 17 10:28:59 2019 From: simons at nospf.cryp.to (Peter Simons) Date: Wed, 17 Apr 2019 12:28:59 +0200 Subject: [Haskell-cafe] shake and cmd argument dependency References: Message-ID: <87ef616i38.fsf@write-only.cryp.to> Hi, > How can I teach shake to rebuild a rules when > the argument of the cmd change? wrap the arguments that are subject to change into an oracle to detect changes and to re-run all actions that depend on the value: {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE TypeFamilies #-} import Development.Shake import Development.Shake.Classes newtype GetCmdlineArgs = GetCmdlineArgs () deriving (Show,Typeable,Eq,Hashable,Binary,NFData) type instance RuleResult GetCmdlineArgs = String main :: IO () main = shake shakeOptions $ do want ["foo.txt"] getCmdlineArgs <- addOracle $ \(GetCmdlineArgs ()) -> return "This is a test!" "*.txt" %> \out -> do args <- getCmdlineArgs (GetCmdlineArgs ()) command [FileStdout out] "echo" [args] Best regards, Peter From vanessa.mchale at iohk.io Wed Apr 17 12:11:02 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Wed, 17 Apr 2019 07:11:02 -0500 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? In-Reply-To: References: Message-ID: I would use Dhall: https://dhall-lang.org/ (I can answer questions but the documentation is reasonably good) Cheers, Vanessa On 4/17/19 4:29 AM, Magicloud Magiclouds wrote: > Hi, > > I saw this function in some web tools, pretty useful when parsing log > or so. So I wonder if Haskell has similar libs already. > > Sample: > > Input line: "2019/04/17 17:27 User magicloud runs command ls." > > Pattern: "${year}/${month}/${day} ${hour}:${minute} User ${username} > runs command ${command}." > > Output: toList [ ("year", "2019"), ("month", "04") , etc ] > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From schernichkin at gmail.com Wed Apr 17 13:46:19 2019 From: schernichkin at gmail.com (=?UTF-8?B?0KHRgtCw0L3QuNGB0LvQsNCyINCn0LXRgNC90LjRh9C60LjQvQ==?=) Date: Wed, 17 Apr 2019 16:46:19 +0300 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? In-Reply-To: References: Message-ID: I think specific formats can be parsed with attoparsec (Data.Attoparsec.Text): p = do year <- yearP char '/' month <- monthP char '/' .... return (year, month, ...) You may also use cassava to parse csv-like files, or Frames for type-safe parsing. With Frames you may custom readers ( http://acowley.github.io/Frames/#orgfa57664 ) with complex pattern-matching, this will require typing skills though. ср, 17 апр. 2019 г. в 12:30, Magicloud Magiclouds < magicloud.magiclouds at gmail.com>: > Hi, > > I saw this function in some web tools, pretty useful when parsing log > or so. So I wonder if Haskell has similar libs already. > > Sample: > > Input line: "2019/04/17 17:27 User magicloud runs command ls." > > Pattern: "${year}/${month}/${day} ${hour}:${minute} User ${username} > runs command ${command}." > > Output: toList [ ("year", "2019"), ("month", "04") , etc ] > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. > _______________________________________________ > 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. -- Sincerely, Stanislav Chernichkin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.mattei at gmail.com Wed Apr 17 14:06:12 2019 From: damien.mattei at gmail.com (Damien Mattei) Date: Wed, 17 Apr 2019 16:06:12 +0200 Subject: [Haskell-cafe] monad example Message-ID: hello, i still seaching a good monad example and after passed the classic tutorial about Maybe monad or State monad which is found in almost 90% of the litterature i try to learn in deep the example of monad that talk about probability ( http://learnyouahaskell.com/for-a-few-monads-more ) for this i try to trace the calls of the inner monad definition like in the file, i give the file in attachment (monade.hs) and the output has a lot of garbage data, not the nicer way to display it,sorry. What i can not figure out is at what stage the program construct the [Tails,Heads] , [Heads,Heads] ... etc i do not know, if someone could explain me in detail the action of a <- coin b <- loadedCoin return [a,b] step by step it would be of great help... Regards, Damien note: here is the ouput: *Main> :load monade.hs [1 of 1] Compiling Main ( monade.hs, interpreted ) Ok, one module loaded. *Main> flipTwoVal Prob {getProb = (Monad Prob >>= flatten (fmap f m) Functor Prob Functor Prob (f x,1 % 2) flatten multAll map ... p= 1 % 2 (Monad Prob >>= flatten (fmap f m) Functor Prob Functor Prob (f x,1 % 10) flatten multAll map ... p= 1 % 10 Monad Prob return) [ flatten multAll (1 % 10*1 % 1) flatten multAll (1 % 2*1 % 10) ([Heads,Heads],1 % 20) Functor Prob (f x,9 % 10) flatten multAll map ... p= 9 % 10 Monad Prob return) , flatten multAll (9 % 10*1 % 1) flatten multAll (1 % 2*9 % 10) ([Heads,Tails],9 % 20) Functor Prob (f x,1 % 2) flatten multAll map ... p= 1 % 2 (Monad Prob >>= flatten (fmap f m) Functor Prob Functor Prob (f x,1 % 10) flatten multAll map ... p= 1 % 10 Monad Prob return) , flatten multAll (1 % 10*1 % 1) flatten multAll (1 % 2*1 % 10) ([Tails,Heads],1 % 20) Functor Prob (f x,9 % 10) flatten multAll map ... p= 9 % 10 Monad Prob return) , flatten multAll (9 % 10*1 % 1) flatten multAll (1 % 2*9 % 10) ([Tails,Tails],9 % 20)]} *Main> flipTwoVal Prob {getProb = [([Heads,Heads],1 % 20),([Heads,Tails],9 % 20),([Tails,Heads],1 % 20),([Tails,Tails],9 % 20)]} -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: monade.hs Type: text/x-haskell Size: 3155 bytes Desc: not available URL: From magicloud.magiclouds at gmail.com Wed Apr 17 14:29:46 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Wed, 17 Apr 2019 22:29:46 +0800 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? In-Reply-To: References: Message-ID: Sorry, I am not sure how this relates to my thought? I want a parsing tool. On Wed, Apr 17, 2019 at 8:11 PM Vanessa McHale wrote: > > I would use Dhall: https://dhall-lang.org/ > > (I can answer questions but the documentation is reasonably good) > > Cheers, > Vanessa > > On 4/17/19 4:29 AM, Magicloud Magiclouds wrote: > > Hi, > > > > I saw this function in some web tools, pretty useful when parsing log > > or so. So I wonder if Haskell has similar libs already. > > > > Sample: > > > > Input line: "2019/04/17 17:27 User magicloud runs command ls." > > > > Pattern: "${year}/${month}/${day} ${hour}:${minute} User ${username} > > runs command ${command}." > > > > Output: toList [ ("year", "2019"), ("month", "04") , etc ] > > > > -- > > 竹密岂妨流水过 > > 山高哪阻野云飞 > > > > And for G+, please use magiclouds#gmail.com. > > _______________________________________________ > > 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. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From magicloud.magiclouds at gmail.com Wed Apr 17 14:32:07 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Wed, 17 Apr 2019 22:32:07 +0800 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? In-Reply-To: References: Message-ID: Thanks. I am familiar with this kind of usage (attoparsec). But it is still somehow complex and not flexible. Let me see what Frame can do. On Wed, Apr 17, 2019 at 9:46 PM Станислав Черничкин wrote: > > I think specific formats can be parsed with attoparsec (Data.Attoparsec.Text): > > p = do > year <- yearP > char '/' > month <- monthP > char '/' > .... > return (year, month, ...) > > You may also use cassava to parse csv-like files, or Frames for type-safe parsing. With Frames you may custom readers ( http://acowley.github.io/Frames/#orgfa57664 ) with complex pattern-matching, this will require typing skills though. > > ср, 17 апр. 2019 г. в 12:30, Magicloud Magiclouds : >> >> Hi, >> >> I saw this function in some web tools, pretty useful when parsing log >> or so. So I wonder if Haskell has similar libs already. >> >> Sample: >> >> Input line: "2019/04/17 17:27 User magicloud runs command ls." >> >> Pattern: "${year}/${month}/${day} ${hour}:${minute} User ${username} >> runs command ${command}." >> >> Output: toList [ ("year", "2019"), ("month", "04") , etc ] >> >> -- >> 竹密岂妨流水过 >> 山高哪阻野云飞 >> >> And for G+, please use magiclouds#gmail.com. >> _______________________________________________ >> 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. > > > > -- > Sincerely, Stanislav Chernichkin. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From frank at dedden.net Wed Apr 17 15:27:22 2019 From: frank at dedden.net (Frank Dedden) Date: Wed, 17 Apr 2019 17:27:22 +0200 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? In-Reply-To: References: Message-ID: <20190417152722.GC9735@shodan.lan> I think you're looking for a scanf (well known in C) like function. A quick search give me: https://hackage.haskell.org/package/scanf https://hackage.haskell.org/package/xformat I haven't used either of them, so I can't recommend one. Regards, Frank Dedden On Wed, Apr 17, 2019 at 10:32:07PM +0800, Magicloud Magiclouds wrote: > Thanks. I am familiar with this kind of usage (attoparsec). But it is > still somehow complex and not flexible. > > Let me see what Frame can do. > > On Wed, Apr 17, 2019 at 9:46 PM Станислав Черничкин > wrote: > > > > I think specific formats can be parsed with attoparsec (Data.Attoparsec.Text): > > > > p = do > > year <- yearP > > char '/' > > month <- monthP > > char '/' > > .... > > return (year, month, ...) > > > > You may also use cassava to parse csv-like files, or Frames for type-safe parsing. With Frames you may custom readers ( http://acowley.github.io/Frames/#orgfa57664 ) with complex pattern-matching, this will require typing skills though. > > > > ср, 17 апр. 2019 г. в 12:30, Magicloud Magiclouds : > >> > >> Hi, > >> > >> I saw this function in some web tools, pretty useful when parsing log > >> or so. So I wonder if Haskell has similar libs already. > >> > >> Sample: > >> > >> Input line: "2019/04/17 17:27 User magicloud runs command ls." > >> > >> Pattern: "${year}/${month}/${day} ${hour}:${minute} User ${username} > >> runs command ${command}." > >> > >> Output: toList [ ("year", "2019"), ("month", "04") , etc ] > >> > >> -- > >> 竹密岂妨流水过 > >> 山高哪阻野云飞 > >> > >> And for G+, please use magiclouds#gmail.com. > >> _______________________________________________ > >> 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. > > > > > > > > -- > > Sincerely, Stanislav Chernichkin. > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. > _______________________________________________ > 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. From neil_mayhew at users.sourceforge.net Wed Apr 17 16:07:26 2019 From: neil_mayhew at users.sourceforge.net (Neil Mayhew) Date: Wed, 17 Apr 2019 10:07:26 -0600 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? In-Reply-To: References: Message-ID: <66984729-65f7-8420-e2b6-f59975864446@users.sourceforge.net> I’m a fan of |regex-applicative|. It’s a combinator library modelled on the parsec family but because it parses only regular languages rather than context-free ones, it’s a bit simpler to use and is a better match for some tasks. It uses |OverloadedStrings| to make it easier to include literal string matches and provides a non-greedy repeating combinator called |few| that avoids having to specify exclusive matches. I think it solves this problem quite nicely: |{-# LANGUAGE OverloadedStrings #-} import Text.Regex.Applicative -- This is just <*> with right associativity (<&>) :: Applicative f => f (a -> b) -> f a -> f b (<&>) = (<*>) infixr 3 <&> type Item = (String, String) item :: String -> RE Char ([Item] -> [Item]) item key = (:) . (,) key <$> few anySym -- ${year}/${month}/${day} ${hour}:${minute} User ${username} runs command ${command}. pattern :: RE Char [Item] pattern = item "year" <* "/" <&> item "month" <* "/" <&> item "day" <* " " <&> item "hour" <* ":" <&> item "minute" <* " User " <&> item "username" <* " runs command " <&> item "command" <* "." <&> pure [] input :: String input = "2019/04/17 17:27 User magicloud runs command ls." output :: Maybe [Item] output = match pattern input -- Just [("year","2019"),("month","04"),("day","17"),("hour","17"),("minute","27"),("username","magicloud"),("command","ls")] | (Also available as a gist .) Obviously the combinator version is less compact and therefore could be considered less readable, but the implementation details could probably be tweaked a bit. It would also be relatively easy to write a quasi-quoter that turns the original input syntax (with |${variable}|) into the equivalent I’ve shown here. ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil_mayhew at users.sourceforge.net Wed Apr 17 16:14:00 2019 From: neil_mayhew at users.sourceforge.net (Neil Mayhew) Date: Wed, 17 Apr 2019 10:14:00 -0600 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? In-Reply-To: References: Message-ID: I'm sorry, the formatting got mangled in my last message, because I was using MarkdownHere. I'll try again without converting it to HTML. I'm a fan of `regex-applicative`. It's a combinator library modelled on the parsec family but because it parses only regular languages rather than context-free ones, it's a bit simpler to use and is a better match for some tasks. It uses `OverloadedStrings` to make it easier to include literal string matches and provides a non-greedy repeating combinator called `few` that avoids having to specify exclusive matches. I think it solves this problem quite nicely: ```haskell {-# LANGUAGE OverloadedStrings #-} import Text.Regex.Applicative -- This is just <*> with right associativity (<&>) :: Applicative f => f (a -> b) -> f a -> f b (<&>) = (<*>) infixr 3 <&> type Item = (String, String) item :: String -> RE Char ([Item] -> [Item]) item key = (:) . (,) key <$> few anySym -- ${year}/${month}/${day} ${hour}:${minute} User ${username} runs command ${command}. pattern :: RE Char [Item] pattern =     item "year" <* "/" <&> item "month" <* "/" <&> item "day" <* " " <&>     item "hour" <* ":" <&> item "minute" <* " User " <&>     item "username" <* " runs command " <&> item "command" <* "." <&>     pure [] input :: String input = "2019/04/17 17:27 User magicloud runs command ls." output :: Maybe [Item] output = match pattern input -- Just [("year","2019"),("month","04"),("day","17"),("hour","17"),("minute","27"),("username","magicloud"),("command","ls")] ``` (Also available as a [gist](https://gist.github.com/neilmayhew/e4fc90b7eaeb7bbcfeb6d6938544ecc9).) Obviously the combinator version is less compact and therefore could be considered less readable, but the implementation details could probably be tweaked a bit. It would also be relatively easy to write a quasi-quoter that turns the original input syntax (with `${variable}`) into the equivalent I've shown here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Wed Apr 17 20:01:28 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 17 Apr 2019 22:01:28 +0200 (CEST) Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? Message-ID: You could emulate this with some custom parser combinators on top of any monadic parser combinator library such as attoparsec or megaparsec. keyed :: (Ord key, Functor parser) => key -> parser a -> parser (Map key a) keyed key = fmap (singleton key) Then, assuming 'char' and 'digitChar' exists in the parser library, you may write integer = some digitChar logline = fmap mconcat $ sequence [ keyed "year" (integer <* char '/'), keyed "month" (integer <* char '/'), keyed "day" (integer <* char ' '), -- etc. ] Olaf From william.hallahan at yale.edu Wed Apr 17 20:17:17 2019 From: william.hallahan at yale.edu (Bill Hallahan) Date: Wed, 17 Apr 2019 16:17:17 -0400 Subject: [Haskell-cafe] -fdefer-type-errors Message-ID: <8E075C22-3B64-40B2-BF0E-64643CADA3D0@yale.edu> Hi, I'm trying to use the -fdefer-type-error flag, discussed in an ICFP paper from 2012: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.366.841&rep=rep1&type=pdf On page 2, the paper has an example, showing that fdefer-type-errors will allow a the first element to be extracted fro a tuple, even if the second element does not correctly typecheck: ghci> let foo = (True, ’a’ && False) Warning: Couldn’t match ‘Bool’ with ‘Char’ ghci> :type foo (Bool, Bool) ghci> fst foo True However, with GHC 8.2.2, I get an error when trying to do this: GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Prelude> let foo = (True, 'a' && False) :1:18: warning: [-Wdeferred-type-errors] • Couldn't match expected type ‘Bool’ with actual type ‘Char’ • In the first argument of ‘(&&)’, namely ‘'a'’ In the expression: 'a' && False In the expression: (True, 'a' && False) Prelude> :type foo foo :: (Bool, Bool) Prelude> fst foo *** Exception: :1:18: error: • Couldn't match expected type ‘Bool’ with actual type ‘Char’ • In the first argument of ‘(&&)’, namely ‘'a'’ In the expression: 'a' && False In the expression: (True, 'a' && False) (deferred type error) Does anyone know the reason for the change in the behavior? Is there any way to get back to the old behavior, i.e. allow the first element of the tuple to still be extracted? Ideally, I would like to get the errors given by defer-type-errors to be as fine-grained/close-to-the-source as possible. Thanks, Bill Hallahan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Wed Apr 17 20:26:20 2019 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 17 Apr 2019 21:26:20 +0100 Subject: [Haskell-cafe] -fdefer-type-errors In-Reply-To: <8E075C22-3B64-40B2-BF0E-64643CADA3D0@yale.edu> References: <8E075C22-3B64-40B2-BF0E-64643CADA3D0@yale.edu> Message-ID: <20190417202620.y6owhndbqxof22x6@weber> On Wed, Apr 17, 2019 at 04:17:17PM -0400, Bill Hallahan wrote: > However, with GHC 8.2.2, I get an error when trying to do this: [...] > Prelude> let foo = (True, 'a' && False) [...] > Prelude> fst foo > *** Exception: :1:18: error: > • Couldn't match expected type ‘Bool’ with actual type ‘Char’ FWIW I see this behaviour in GHC 8.0.1 too. From a.pelenitsyn at gmail.com Wed Apr 17 22:20:23 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Wed, 17 Apr 2019 18:20:23 -0400 Subject: [Haskell-cafe] -fdefer-type-errors In-Reply-To: <20190417202620.y6owhndbqxof22x6@weber> References: <8E075C22-3B64-40B2-BF0E-64643CADA3D0@yale.edu> <20190417202620.y6owhndbqxof22x6@weber> Message-ID: I checked the release prior to 8.0.1 — 7.10.3, and it worked as expected (returned `True`). This looks like a bug introduced somewhere in between. I wish I could do git bisect on GHC properly… Worth reporting, I guess. -- Best, Artem On Wed, 17 Apr 2019 at 16:26, Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > On Wed, Apr 17, 2019 at 04:17:17PM -0400, Bill Hallahan wrote: > > However, with GHC 8.2.2, I get an error when trying to do this: > [...] > > Prelude> let foo = (True, 'a' && False) > [...] > > Prelude> fst foo > > *** Exception: :1:18: error: > > • Couldn't match expected type ‘Bool’ with actual type ‘Char’ > > FWIW I see this behaviour in GHC 8.0.1 too. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Thu Apr 18 03:03:25 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 17 Apr 2019 23:03:25 -0400 Subject: [Haskell-cafe] -fdefer-type-errors In-Reply-To: References: <8E075C22-3B64-40B2-BF0E-64643CADA3D0@yale.edu> <20190417202620.y6owhndbqxof22x6@weber> Message-ID: <86EC2CFC-1395-4BD5-8186-7AD7FC636B52@richarde.dev> I believe this is a known bug: #11197 (https://gitlab.haskell.org/ghc/ghc/issues/11197 ) If you reported this again, could you please update your post to point to #11197? Thanks for reporting, regardless! Richard > On Apr 17, 2019, at 6:20 PM, Artem Pelenitsyn wrote: > > I checked the release prior to 8.0.1 — 7.10.3, and it worked as expected (returned `True`). This looks like a bug introduced somewhere in between. I wish I could do git bisect on GHC properly… > > Worth reporting, I guess. > > -- > Best, Artem > > On Wed, 17 Apr 2019 at 16:26, Tom Ellis > wrote: > On Wed, Apr 17, 2019 at 04:17:17PM -0400, Bill Hallahan wrote: > > However, with GHC 8.2.2, I get an error when trying to do this: > [...] > > Prelude> let foo = (True, 'a' && False) > [...] > > Prelude> fst foo > > *** Exception: :1:18: error: > > • Couldn't match expected type ‘Bool’ with actual type ‘Char’ > > FWIW I see this behaviour in GHC 8.0.1 too. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Thu Apr 18 15:13:18 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Thu, 18 Apr 2019 23:13:18 +0800 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? In-Reply-To: <20190417152722.GC9735@shodan.lan> References: <20190417152722.GC9735@shodan.lan> Message-ID: scanf looks interesting. Closer to my case. Thanks. Neil, the formation looks OK in GMail. The lib gives me some other thoughts. Thanks. On Wed, Apr 17, 2019 at 11:24 PM Frank Dedden wrote: > > I think you're looking for a scanf (well known in C) like function. A quick > search give me: > https://hackage.haskell.org/package/scanf > https://hackage.haskell.org/package/xformat > > I haven't used either of them, so I can't recommend one. > > Regards, > Frank Dedden > > On Wed, Apr 17, 2019 at 10:32:07PM +0800, Magicloud Magiclouds wrote: > > Thanks. I am familiar with this kind of usage (attoparsec). But it is > > still somehow complex and not flexible. > > > > Let me see what Frame can do. > > > > On Wed, Apr 17, 2019 at 9:46 PM Станислав Черничкин > > wrote: > > > > > > I think specific formats can be parsed with attoparsec (Data.Attoparsec.Text): > > > > > > p = do > > > year <- yearP > > > char '/' > > > month <- monthP > > > char '/' > > > .... > > > return (year, month, ...) > > > > > > You may also use cassava to parse csv-like files, or Frames for type-safe parsing. With Frames you may custom readers ( http://acowley.github.io/Frames/#orgfa57664 ) with complex pattern-matching, this will require typing skills though. > > > > > > ср, 17 апр. 2019 г. в 12:30, Magicloud Magiclouds : > > >> > > >> Hi, > > >> > > >> I saw this function in some web tools, pretty useful when parsing log > > >> or so. So I wonder if Haskell has similar libs already. > > >> > > >> Sample: > > >> > > >> Input line: "2019/04/17 17:27 User magicloud runs command ls." > > >> > > >> Pattern: "${year}/${month}/${day} ${hour}:${minute} User ${username} > > >> runs command ${command}." > > >> > > >> Output: toList [ ("year", "2019"), ("month", "04") , etc ] > > >> > > >> -- > > >> 竹密岂妨流水过 > > >> 山高哪阻野云飞 > > >> > > >> And for G+, please use magiclouds#gmail.com. > > >> _______________________________________________ > > >> 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. > > > > > > > > > > > > -- > > > Sincerely, Stanislav Chernichkin. > > > > > > > > -- > > 竹密岂妨流水过 > > 山高哪阻野云飞 > > > > And for G+, please use magiclouds#gmail.com. > > _______________________________________________ > > 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. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From william.hallahan at yale.edu Thu Apr 18 15:22:26 2019 From: william.hallahan at yale.edu (Bill Hallahan) Date: Thu, 18 Apr 2019 11:22:26 -0400 Subject: [Haskell-cafe] -fdefer-type-errors In-Reply-To: <86EC2CFC-1395-4BD5-8186-7AD7FC636B52@richarde.dev> References: <8E075C22-3B64-40B2-BF0E-64643CADA3D0@yale.edu> <20190417202620.y6owhndbqxof22x6@weber> <86EC2CFC-1395-4BD5-8186-7AD7FC636B52@richarde.dev> Message-ID: <9BAC0F84-38A3-48A0-B8E1-651AB9C04904@yale.edu> Thanks for the pointer! I hadn't gotten to reporting it yet, so nothing to update. Bill > On Apr 17, 2019, at 11:03 PM, Richard Eisenberg wrote: > > I believe this is a known bug: #11197 (https://gitlab.haskell.org/ghc/ghc/issues/11197 ) > > If you reported this again, could you please update your post to point to #11197? Thanks for reporting, regardless! > > Richard > >> On Apr 17, 2019, at 6:20 PM, Artem Pelenitsyn > wrote: >> >> I checked the release prior to 8.0.1 — 7.10.3, and it worked as expected (returned `True`). This looks like a bug introduced somewhere in between. I wish I could do git bisect on GHC properly… >> >> Worth reporting, I guess. >> >> -- >> Best, Artem >> >> On Wed, 17 Apr 2019 at 16:26, Tom Ellis > wrote: >> On Wed, Apr 17, 2019 at 04:17:17PM -0400, Bill Hallahan wrote: >> > However, with GHC 8.2.2, I get an error when trying to do this: >> [...] >> > Prelude> let foo = (True, 'a' && False) >> [...] >> > Prelude> fst foo >> > *** Exception: :1:18: error: >> > • Couldn't match expected type ‘Bool’ with actual type ‘Char’ >> >> FWIW I see this behaviour in GHC 8.0.1 too. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhujinxuan at gmail.com Fri Apr 19 14:18:00 2019 From: zhujinxuan at gmail.com (Jinxuan Zhu) Date: Fri, 19 Apr 2019 10:18:00 -0400 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? In-Reply-To: References: Message-ID: I feel like the type with Map is not very nice (as map can be anything). Given the simplicity of year parsing , how about traditional ``` data DateTime = DT Int Int Int timeP :: Parser DateTime timeP = DT <*> p <$> p <$> p where p = integer <* char '/' ``` Olaf Klinke writes: > You could emulate this with some custom parser combinators on > top of any > monadic parser combinator library such as attoparsec or > megaparsec. > > keyed :: (Ord key, Functor parser) => > key -> parser a -> parser (Map key a) > keyed key = fmap (singleton key) > > Then, assuming 'char' and 'digitChar' exists in the parser > library, > you may write > > integer = some digitChar > logline = fmap mconcat $ sequence [ > keyed "year" (integer <* char '/'), > keyed "month" (integer <* char '/'), > keyed "day" (integer <* char ' '), > -- etc. > ] > > Olaf > _______________________________________________ > 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. From olf at aatal-apotheke.de Fri Apr 19 15:14:34 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 19 Apr 2019 17:14:34 +0200 Subject: [Haskell-cafe] Is there already a lib to parse a line of string with a pattern and generate key-value map or a record? In-Reply-To: References: Message-ID: <6E3C730D-96CD-4A4B-BF1D-6CABE1969C00@aatal-apotheke.de> I'd rather go for LocalTime from the time package, if there must be a custom data type for time and date. But beware: If you parse the line into a Map, then you can not mix the types of the individual fields: all must be the same. Hence in my example I went for String. It is the duty of downstream functions to transform the Map String String into a more detailed data structure. Olaf > Am 19.04.2019 um 16:18 schrieb Jinxuan Zhu : > > > I feel like the type with Map is not very nice (as map can be anything). > Given the simplicity of year parsing , how about traditional > > ``` > data DateTime = DT Int Int Int > timeP :: Parser DateTime > timeP = DT <*> p <$> p <$> p where > p = integer <* char '/' > ``` > > > > Olaf Klinke writes: > >> You could emulate this with some custom parser combinators on top of any monadic parser combinator library such as attoparsec or megaparsec. >> >> keyed :: (Ord key, Functor parser) => >> key -> parser a -> parser (Map key a) >> keyed key = fmap (singleton key) >> >> Then, assuming 'char' and 'digitChar' exists in the parser library, >> you may write >> >> integer = some digitChar >> logline = fmap mconcat $ sequence [ >> keyed "year" (integer <* char '/'), >> keyed "month" (integer <* char '/'), >> keyed "day" (integer <* char ' '), >> -- etc. >> ] >> >> Olaf >> _______________________________________________ >> 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. > From trebla at vex.net Fri Apr 19 17:31:09 2019 From: trebla at vex.net (Albert Y. C. Lai) Date: Fri, 19 Apr 2019 13:31:09 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <23E32FEE-142D-4A76-9F81-9DC1F760DDCF@richarde.dev> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> <23E32FEE-142D-4A76-9F81-9DC1F760DDCF@richarde.dev> Message-ID: On 2019-04-12 10:47 a.m., Richard Eisenberg wrote: > If you look at definitions of other languages (C, Java), you see that > the operators are defined to be left-associative. Perhaps those other > languages got it wrong, then. :) > > In any case, this conversation has been illuminating. Thanks! I am late to this discussion but here is my solution. This is really just story-telling to end-users. The real story you want to tell everyone is this: "x && y && z && t" means Scheme's "(and x y z t)", and it means you try the sequence from left to right, stopping at the first incident of "false". To those people who evaluate an AST in the bottom-up order, e.g., C programmers, this sounds like left-associating because the left is more likely evaluated so these people need to envision a left-leaning AST. So you comfort them with "yeah!". To those people who evaluate an AST in the top-down order, e.g., Haskell programmers, this sounds like right-associating because the right is more likely skipped so these people need to envision a right-leaning AST. So you comfort them with "yeah!". So either (both C and Haskell are right) or (both C and Haskell are wrong). As many of you have observed, it doesn't matter, a compiler writer already knows it's "(and x y z t)" and generates the correct code and not bother to split hair. From jerzy.karczmarczuk at unicaen.fr Fri Apr 19 19:43:46 2019 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Fri, 19 Apr 2019 21:43:46 +0200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> <23E32FEE-142D-4A76-9F81-9DC1F760DDCF@richarde.dev> Message-ID: <50333d55-322a-c1b2-63a7-65c8ab9e261f@unicaen.fr> Le 19/04/2019 à 19:31, Albert Y. C. Lai a écrit : > I am late to this discussion but here is my solution. > > This is really just story-telling to end-users. > > The real story you want to tell everyone is this: "x && y && z && t" > means Scheme's "(and x y z t)", and it means you try the sequence from > left to right, stopping at the first incident of "false". > /.../ > As many of you have observed, it doesn't matter, a compiler writer > already knows it's "(and x y z t)" and generates the correct code and > not bother to split hair. Very, ehm, interesting methodology... I suspect that you missed that part of the discussion where people discussed parsing. I don't know if you ever taught compilation, but imagine that your students ask you: */HOW /**/"x && y && z && t" is transformed into /**/"(and x y z t)" ?/* Will your answer be: */it doesn't matter, a compiler writer already knows it's "(and x y z t)" and generates the correct code and not bother to split hair/* Everybody will be happy. Bon courage. Jerzy Karczmarczuk */ /* -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Mon Apr 22 04:44:03 2019 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon, 22 Apr 2019 00:44:03 -0400 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <50333d55-322a-c1b2-63a7-65c8ab9e261f@unicaen.fr> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> <23E32FEE-142D-4A76-9F81-9DC1F760DDCF@richarde.dev> <50333d55-322a-c1b2-63a7-65c8ab9e261f@unicaen.fr> Message-ID: <1027f9b0-155f-9acf-d5c8-8f9a0dd24901@vex.net> On 2019-04-19 3:43 p.m., Jerzy Karczmarczuk wrote: > > Le 19/04/2019 à 19:31, Albert Y. C. Lai a écrit : > >> I am late to this discussion but here is my solution. >> >> This is really just story-telling to end-users. >> >> The real story you want to tell everyone is this: "x && y && z && t" >> means Scheme's "(and x y z t)", and it means you try the sequence >> from left to right, stopping at the first incident of "false". >> /.../ >> As many of you have observed, it doesn't matter, a compiler writer >> already knows it's "(and x y z t)" and generates the correct code and >> not bother to split hair. > > Very, ehm, interesting methodology... > > I suspect that you missed that part of the discussion where people > discussed parsing. I don't know if you ever taught compilation, but > imagine that your students ask you: > > */HOW /**/"x && y && z && t" is transformed into /**/"(and x y z t)" ?/* > > Will your answer be: > > */it doesn't matter, a compiler writer already knows it's "(and x y z > t)" and generates the correct code and not bother to split hair/* > What would you tell students about commas and semicolons in the following?  Are these commas and semicolons left associating? Right associating?  Both?  Neither?  Has anyone even asked?  How to parse them?  I would tell the same. Pascal's "begin foo() ; tora() ; tigger() end" C's "x = (y=10 , y=f(y) , y=g(y) ,  y);" Haskell's "f x | g x > 0 , h x < 0 , sin x > 0 = ()" Prolog's "g(X,Y) :- parent(X,C1) , parent(C1,C2) , parent(C2,Y)." Matlab's "[3+4i , 3 , 5-i ; 1-i , 1+i , 1 ; 7+8i , 4-3i , -i]" -------------- next part -------------- An HTML attachment was scrubbed... URL: From javran.c at gmail.com Mon Apr 22 08:58:31 2019 From: javran.c at gmail.com (Javran Cheng) Date: Mon, 22 Apr 2019 01:58:31 -0700 Subject: [Haskell-cafe] how do I intercalate for Data.Text.Lazy.Builder Message-ID: Hi Cafe, Just a quick question, the title says it all: how do I intercalate for the Builder? Given what it does, it makes sense that things like `intercalate` should be out of the box, yet I feel the export list of Builder is very limited. -- Javran (Fang) Cheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From chpatrick at gmail.com Mon Apr 22 09:50:11 2019 From: chpatrick at gmail.com (Patrick Chilton) Date: Mon, 22 Apr 2019 11:50:11 +0200 Subject: [Haskell-cafe] how do I intercalate for Data.Text.Lazy.Builder In-Reply-To: References: Message-ID: If you want to join a list of Builders with a delimiter, you can use `mconcat (intersperse d xs)` This works for any Monoid. On Mon, Apr 22, 2019 at 10:59 AM Javran Cheng wrote: > Hi Cafe, > > Just a quick question, the title says it all: how do I intercalate for the > Builder? > Given what it does, it makes sense that things like `intercalate` should > be out of the box, > yet I feel the export list of Builder is very limited. > > -- > Javran (Fang) Cheng > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhi.1990 at gmail.com Mon Apr 22 15:03:20 2019 From: fhi.1990 at gmail.com (=?UTF-8?Q?Frederik_Hangh=C3=B8j_Iversen?=) Date: Mon, 22 Apr 2019 17:03:20 +0200 Subject: [Haskell-cafe] When does ICFP open registration? In-Reply-To: References: Message-ID: Hi Alexey, could you post here when you figure out? I'd like to know as well. On Mon, Apr 15, 2019, 13:25 Alexey Raga wrote: > Hello, > > For bureaucracy reasons, it may be a time in our company to start sorting > out ICFP trips/tickets. > Does anyone have any information about when the registration may be > opening? > > I couldn't find anything on their website, and I couldn't find any contact > details on that website either, so asking here just in case if anyone knows > :) > > Best Regards, > Alexey Raga > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From javran.c at gmail.com Mon Apr 22 16:38:32 2019 From: javran.c at gmail.com (Javran Cheng) Date: Mon, 22 Apr 2019 09:38:32 -0700 Subject: [Haskell-cafe] how do I intercalate for Data.Text.Lazy.Builder In-Reply-To: References: Message-ID: Darn right! I've checked Foldable, Semigroup and Monoid, never thought about the function right above intercalate, thanks! On Mon, Apr 22, 2019 at 2:50 AM Patrick Chilton wrote: > If you want to join a list of Builders with a delimiter, you can use > `mconcat (intersperse d xs)` > This works for any Monoid. > > On Mon, Apr 22, 2019 at 10:59 AM Javran Cheng wrote: > >> Hi Cafe, >> >> Just a quick question, the title says it all: how do I intercalate for >> the Builder? >> Given what it does, it makes sense that things like `intercalate` should >> be out of the box, >> yet I feel the export list of Builder is very limited. >> >> -- >> Javran (Fang) Cheng >> _______________________________________________ >> 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. > > -- Javran (Fang) Cheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Tue Apr 23 06:00:22 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Tue, 23 Apr 2019 14:00:22 +0800 Subject: [Haskell-cafe] Problem on exception and laziness Message-ID: Hi, I am aware that laziness sometimes may cause exception handling in unexpected ways. Recently I have such a problem that I cannot figure out how to fix (simply). I have a function `watch` that parse the content of /proc/. And I use `catch` to wrap `readFile` call, since the data in /proc/ could be gone any time. ```Haskell wrap2Maybe :: IO a -> IO (Maybe a) wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> return Nothing) watch args = do mStat <- wrap2Maybe (readFile ("/proc/" fp "stat")) >>= return . flip (>>=) parseStat print mStat watch args ``` But occasionally, my tool exits with message: GoM: /proc/1484/stat: hGetContents: does not exist (No such process) Since above code is the only `readFile` call which leads to hGetContents, I could not figure out what else should I do to catch the error. -- 竹密岂妨流水过 山高哪阻野云飞 From allbery.b at gmail.com Tue Apr 23 06:06:30 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 23 Apr 2019 02:06:30 -0400 Subject: [Haskell-cafe] Problem on exception and laziness In-Reply-To: References: Message-ID: At a guess, include the parseStat in the wrap2Maybe so that the input is evaluated. Alternately, force the spine of the list produced by readFile so that the entire file is read immediately. Note that the error is from getContents, which produces a lazy list that reads "in the background" as the resulting list is consumed (see unsafeInterleaveIO): "files" in /proc are generated as they are read, so if a process exits while you have an open handle on one of its files in /proc, it will be invalidated on you like that. On Tue, Apr 23, 2019 at 2:01 AM Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Hi, > I am aware that laziness sometimes may cause exception handling in > unexpected ways. Recently I have such a problem that I cannot figure > out how to fix (simply). > > I have a function `watch` that parse the content of /proc/. And I use > `catch` to wrap `readFile` call, since the data in /proc/ could be > gone any time. > > ```Haskell > wrap2Maybe :: IO a -> IO (Maybe a) > wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> return > Nothing) > > watch args = do > mStat <- wrap2Maybe (readFile ("/proc/" fp "stat")) >>= > return . flip (>>=) parseStat > print mStat > watch args > ``` > > But occasionally, my tool exits with message: > GoM: /proc/1484/stat: hGetContents: does not exist (No such process) > > Since above code is the only `readFile` call which leads to > hGetContents, I could not figure out what else should I do to catch > the error. > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Tue Apr 23 06:49:43 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Tue, 23 Apr 2019 14:49:43 +0800 Subject: [Haskell-cafe] Problem on exception and laziness In-Reply-To: References: Message-ID: Thanks. I thought $! could help on this, so tried to avoid DeepSeq. Let me try. On Tue, Apr 23, 2019 at 2:06 PM Brandon Allbery wrote: > > At a guess, include the parseStat in the wrap2Maybe so that the input is evaluated. Alternately, force the spine of the list produced by readFile so that the entire file is read immediately. > > Note that the error is from getContents, which produces a lazy list that reads "in the background" as the resulting list is consumed (see unsafeInterleaveIO): "files" in /proc are generated as they are read, so if a process exits while you have an open handle on one of its files in /proc, it will be invalidated on you like that. > > On Tue, Apr 23, 2019 at 2:01 AM Magicloud Magiclouds wrote: >> >> Hi, >> I am aware that laziness sometimes may cause exception handling in >> unexpected ways. Recently I have such a problem that I cannot figure >> out how to fix (simply). >> >> I have a function `watch` that parse the content of /proc/. And I use >> `catch` to wrap `readFile` call, since the data in /proc/ could be >> gone any time. >> >> ```Haskell >> wrap2Maybe :: IO a -> IO (Maybe a) >> wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> return Nothing) >> >> watch args = do >> mStat <- wrap2Maybe (readFile ("/proc/" fp "stat")) >>= >> return . flip (>>=) parseStat >> print mStat >> watch args >> ``` >> >> But occasionally, my tool exits with message: >> GoM: /proc/1484/stat: hGetContents: does not exist (No such process) >> >> Since above code is the only `readFile` call which leads to >> hGetContents, I could not figure out what else should I do to catch >> the error. >> -- >> 竹密岂妨流水过 >> 山高哪阻野云飞 >> _______________________________________________ >> 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. > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From allbery.b at gmail.com Tue Apr 23 07:06:27 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 23 Apr 2019 03:06:27 -0400 Subject: [Haskell-cafe] Problem on exception and laziness In-Reply-To: References: Message-ID: It's /proc that is messing you up here, I suspect: it's regenerated on every read system call, not on open, so if it's more than one block then it can go away between reading the blocks because there's nothing to generate the next block from. Flip side, because of this most files in /proc are kept small, so it's safe to read them all at once. (Memory images being an exception, but those are handled differently anyway.) Moral of the story is you should probably use strict I/O with stuff under /proc, not (h)getContents or anything based on it like readFile. On Tue, Apr 23, 2019 at 2:50 AM Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Thanks. I thought $! could help on this, so tried to avoid DeepSeq. Let me > try. > > On Tue, Apr 23, 2019 at 2:06 PM Brandon Allbery > wrote: > > > > At a guess, include the parseStat in the wrap2Maybe so that the input is > evaluated. Alternately, force the spine of the list produced by readFile so > that the entire file is read immediately. > > > > Note that the error is from getContents, which produces a lazy list that > reads "in the background" as the resulting list is consumed (see > unsafeInterleaveIO): "files" in /proc are generated as they are read, so if > a process exits while you have an open handle on one of its files in /proc, > it will be invalidated on you like that. > > > > On Tue, Apr 23, 2019 at 2:01 AM Magicloud Magiclouds < > magicloud.magiclouds at gmail.com> wrote: > >> > >> Hi, > >> I am aware that laziness sometimes may cause exception handling in > >> unexpected ways. Recently I have such a problem that I cannot figure > >> out how to fix (simply). > >> > >> I have a function `watch` that parse the content of /proc/. And I use > >> `catch` to wrap `readFile` call, since the data in /proc/ could be > >> gone any time. > >> > >> ```Haskell > >> wrap2Maybe :: IO a -> IO (Maybe a) > >> wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> return > Nothing) > >> > >> watch args = do > >> mStat <- wrap2Maybe (readFile ("/proc/" fp "stat")) >>= > >> return . flip (>>=) parseStat > >> print mStat > >> watch args > >> ``` > >> > >> But occasionally, my tool exits with message: > >> GoM: /proc/1484/stat: hGetContents: does not exist (No such process) > >> > >> Since above code is the only `readFile` call which leads to > >> hGetContents, I could not figure out what else should I do to catch > >> the error. > >> -- > >> 竹密岂妨流水过 > >> 山高哪阻野云飞 > >> _______________________________________________ > >> 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. > > > > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From leah at vuxu.org Tue Apr 23 08:48:28 2019 From: leah at vuxu.org (Leah Neukirchen) Date: Tue, 23 Apr 2019 10:48:28 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2019-04-25 @ 19:30 Message-ID: <8736m9m7j7.fsf@vuxu.org> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, April 25 at Cafe Puck at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-apr-2019/ Everybody is welcome! cu, -- Leah Neukirchen http://leahneukirchen.org/ From ben at well-typed.com Wed Apr 24 04:55:39 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 24 Apr 2019 00:55:39 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.6.5 is now available Message-ID: <8736m8uhme.fsf@smart-cactus.org> Hello everyone, The GHC team is proud to announce the release of GHC 8.6.5. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.6.5 Release notes are also available [1]. This release fixes a handful of issues with 8.6.4: - Binary distributions once again ship with Haddock documentation including syntax highlighted source of core libraries (#16445) - A build system issue where use of GCC with `-flto` broke `configure` was fixed (#16440) - An bug affecting Windows platforms wherein XMM register values could be mangled when entering STG has been fixed (#16514) - Several Windows packaging issues resulting from the recent CI rework. (#16408, #16398, #16516) Do note that due to linking issues (see #15934) profiling will be rather unreliable on Windows. This will be fixed in 8.8.1. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] http://downloads.haskell.org/~ghc/8.6.5/docs/html/users_guide/8.6.5-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jerzy.karczmarczuk at unicaen.fr Wed Apr 24 07:52:27 2019 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Wed, 24 Apr 2019 09:52:27 +0200 Subject: [Haskell-cafe] Why are && and || right-associative? In-Reply-To: <1027f9b0-155f-9acf-d5c8-8f9a0dd24901@vex.net> References: <52723F13-686F-4824-9295-E98E2E5CD9B2@richarde.dev> <23E32FEE-142D-4A76-9F81-9DC1F760DDCF@richarde.dev> <50333d55-322a-c1b2-63a7-65c8ab9e261f@unicaen.fr> <1027f9b0-155f-9acf-d5c8-8f9a0dd24901@vex.net> Message-ID: <45a062ea-29a8-82aa-7643-d1b4ef424895@unicaen.fr> After the non-answer of Albert Y. C. Lai about the associativity of logical connectives: > a compiler writer already knows it's "(and x y z t)" and generates the > correct code and not bother to split hair. I issued a bit acrimonious remark pointing out that a parsing question should not be answered  that a compiler writer "knows". > imagine that your students ask you: */HOW /**/"x && y && z && t" is > transformed into /**/"(and x y z t)/* I got my reward... > What would you tell students about commas and semicolons in the > following?  Are these commas and semicolons left associating?  Right > associating?  Both? Neither?  Has anyone even asked?  How to parse > them?  I would tell the same. > > Pascal's "begin foo() ; tora() ; tigger() end" > C's "x = (y=10 , y=f(y) , y=g(y) ,  y);" > Haskell's "f x | g x > 0 , h x < 0 , sin x > 0 = ()" > Prolog's "g(X,Y) :- parent(X,C1) , parent(C1,C2) , parent(C2,Y)." > Matlab's "[3+4i , 3 , 5-i ; 1-i , 1+i , 1 ; 7+8i , 4-3i , -i]" > Now I don't know whether Albert Y. C. Lai is pulling my leg, or he really confuses the operator grammars and other ways of parsing...  Everybody who taught Prolog knows that commas and semicolons in this language ARE logical connectives, so replacing one non-answer by another one "I would tell the same" is not an appropriate response.  There IS a concrete answer to this question, both operators are xfy with well defined precedence. In Pascal commas and semicolons are not operators at all, and the standard parsing is a recursive top-down old machinery (well, it was, when I studied the Wirth & Amman compiler sources). The associativity is implicitly specified by the grammar productions. In Matlab the syntactic connectives in matrices are not operators either. In one detail Albert Y. C. Lai is absolutely right, namely that this discussion is completely pointless. Jerzy Karczmarczuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From tysha at pyrofex.net Thu Apr 25 19:21:00 2019 From: tysha at pyrofex.net (Tysha Moore) Date: Thu, 25 Apr 2019 13:21:00 -0600 Subject: [Haskell-cafe] CDelta and Haskell Message-ID: <5FFE7A1D-09DF-4A88-8E6C-00C91273E94C@pyrofex.net> Haskell Developers, We at Pyrofex Corporation are working on an exciting new project called CDelta (cdelta.io ), a transaction based blockchain that will compete with Visa and Venmo. This blockchain is written in Haskell and we are looking for build a team of Haskell developers here in Utah to bring this project to fruition. Our job description is below. We would LOVE to hear from you. Cryptocurrency Software Engineer Are you ready to work for a company of engineers, managed by engineers, and focused on engineers and the work they can do? Your opportunity to work with a brilliant team that’s developing world-changing technology is here—seize it! At Pyrofex, we do things differently: we hire great engineers, give them the tools to do great things, and expect them to do so. We are invested in each team member's growth and foster a workplace that celebrates accomplishments and hard work by focusing on our engineers and what they need in order to be successful. Pyrofex is hiring. Show us your best work. About Us Pyrofex Corporation is changing the blockchain game and quickly growing a world-class team to do it. As one of Utah Valley’s first cryptocurrency startups, founded in 2016 by ex-Googlers Mike Stay and Nash Foster, Pyrofex is busy creating next-generation blockchain platforms that are simple, secure, and always reliable. We take pride in our work. We set high expectations for everyone, from our founders to each team member, and as a result we deliver extraordinary products and services. At Pyrofex, we hire for strength, not for lack of weakness. We hire for capability and talent, not specific knowledge of a tool or language. We hire people who have a passion for quality and innovation. Each team member achieves great things in an environment supporting both independence and collaboration. About You You collaborate well with others to design and architect our complex systems. You take the amorphous sets of needs and use cases and distill these into written designs and specifications. You demonstrate a fastidious attention to detail, knowledge of your programming tools, and the ability to regularly produce working, correct code. You are interested in building high-performance, high-bandwidth networks, and solving interesting problems. Pyrofex hires engineers at all levels of experience—from current students to engineers with decades of experience. Our engineers have worked on compilers, system software, distributed data storage, service and reliability, and JavaScript language security features through their careers. The path each of us has taken to get here is unique and we suspect the same will be true of our best employees. We are most interested in hiring strong programmers with experience working with large datasets and peer-to-peer networking. We desire to hear from candidates with experience with functional programming (Scala, Clojure, F#, SCheme, Haskell) and encryption technology. Our most successful candidates also have a background in computer science, but if you think this job is for you, we'll take a look. About the Job Developers on our team design, implement, test, deploy, and manage a variety of systems and products using technologies like Haskell, GNU/Linux, and C/C++. The engineers on this team will design, implement, test, deploy, and manage a large-scale global software system using Linux and the JVM. Pyrofex builds cryptocurrency systems and large-scale distributed and decentralized applications. If this sounds good to you, then e-mail us at jobs at pyrofex.net with the subject line, “AWW MAN! I CAN”T WAIT!!!” and your resume or linkedin profile. We would also enjoy a cover letter telling us about your work ethic and your favorite project. If you can send us examples of your code, that would be most excellent. Tysha Moore Talent Acquisition Specialist Pyrofex Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Thu Apr 25 23:14:58 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Thu, 25 Apr 2019 23:14:58 +0000 Subject: [Haskell-cafe] Repa array and Data.Vector.Storable.Mutable. Message-ID: Hello I would like a function which allows to freeze a Mutable Vector into a Repa array. of type Array F DIM2 a It seems to me that the the foreignPtr ownership should be transfer to the Repa Array, but I can not find a way to do this... So what is the proper way to achieve this ? thansk for your help. Frederic From ben at well-typed.com Thu Apr 25 23:51:17 2019 From: ben at well-typed.com (Ben Gamari) Date: Thu, 25 Apr 2019 19:51:17 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.1-alpha1 is now available Message-ID: <87a7gdtziv.fsf@smart-cactus.org> Hello everyone, The GHC team is pleased to announce the first alpha release of GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.1-alpha1 A draft of the release notes is also available [1]. This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * More locations where users can write `forall` (GHC Proposal #0007) * Further work on the Hadrian build system This release starts the pre-release cycle for GHC 8.8. This cycle is starting quite a bit later than expected due recent work on GHC's CI and release infrastructure. See the GHC Blog [2] for more on this. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1-alpha1/docs/html/users_guide/8.8.1-notes.html [2] https://www.haskell.org/ghc/blog/20190405-ghc-8.8-status.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jevans at interos.net Fri Apr 26 15:38:31 2019 From: jevans at interos.net (John Evans) Date: Fri, 26 Apr 2019 15:38:31 +0000 Subject: [Haskell-cafe] [Job] Interos is hiring Haskell developers (Arlington, VA and Menlo Park, CA) Message-ID: When I posted this on reddit, someone suggested I post it here as well, so: Interos Solutions, Inc. is a fast-growing venture backed company with an AI-driven SaaS application that delivers our commercial and government customers unique insight into their ever-changing business ecosystems. The core of our platform is the compilation, analysis and visualization of dynamically changing big data collected across open source, proprietary and public data sources. By continuously analyzing our "real-time" data stream we provide our customers with unique insights into their business relations, supply chains and other third-party activities. To accelerate the growth of our application, we are putting together a team of Haskell engineers, data analysts, data scientists, UI/UX professionals and product managers. We are committed to building a world class product organization that leverages tools like Haskell and latest machine learning techniques to achieve outsized results as individuals and as a team. Salary and benefits are competitive for the areas. We have offices in Arlington, VA and Menlo Park, CA. We are unable to consider remote employees at this time. https://interos.applicantpro.com/jobs/986652-306361.html https://interos.applicantpro.com/jobs/1004858-306361.html https://interos.applicantpro.com/jobs/1004874-306361.html We are also hiring for Business Analysts, Data Analysts, Data Visualization, DevOps engineers and Data Scientists, email me for links to those opportunities. From evan at evan-borden.com Fri Apr 26 23:53:07 2019 From: evan at evan-borden.com (Evan Borden) Date: Fri, 26 Apr 2019 16:53:07 -0700 Subject: [Haskell-cafe] ANN: network-3.1.0.0, network-2.8.0.1 Message-ID: Announcing the release of network-3.1.0.0 and network-2.8.0.1 . *Version 3.1.0.0* - Made GC of socket safer.(#399 ) - Deprecating fdSocket. Use withFdSocket instead to ensure that sockets are GCed in proper time. (#399 ) *Version 2.8.0.1* - Ensure that accept returns a correct sockaddr for unix domain. (#400 ) - Avoid out of bounds writes in pokeSockAddr. (#400 ) As always thank you to network's contributors and bug reporters. -------------- next part -------------- An HTML attachment was scrubbed... URL: From godzbanebane at gmail.com Sun Apr 28 09:38:17 2019 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Sun, 28 Apr 2019 12:38:17 +0300 Subject: [Haskell-cafe] Agda's BUILTIN Naturals in Haskell Message-ID: Hey, Is there any way to do something similar to what Agda does with natural numbers via BUILTIN pragmas? More precisely I want to have correct-by-construction natural numbers, that at runtime are treated as `Integer`s. My initial idea was to abuse rewrite rules to turn `data N = Z | S N` into `Integer` terms somehow, but I'm not sure if this is possible. ======= Georgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From godzbanebane at gmail.com Sun Apr 28 09:45:24 2019 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Sun, 28 Apr 2019 12:45:24 +0300 Subject: [Haskell-cafe] Type information in MVars Message-ID: Hi, There are obviously a lot of cool tricks you can do with phantom parameters, but they are all lost when you start looking at a `MVar` holding a type with a phantom parameter. Is there any way to track this type-level information, while still being able to write/read values from multiple threads? ======= Georgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Apr 28 09:56:42 2019 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 28 Apr 2019 10:56:42 +0100 Subject: [Haskell-cafe] Type information in MVars In-Reply-To: References: Message-ID: <20190428095642.24txd56oiptw4jft@weber> On Sun, Apr 28, 2019 at 12:45:24PM +0300, Georgi Lyubenov wrote: > There are obviously a lot of cool tricks you can do with phantom > parameters, but they are all lost when you start looking at a `MVar` > holding a type with a phantom parameter. That's an intriguing statement. Why are they lost? From ietf-dane at dukhovni.org Sun Apr 28 10:37:50 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 28 Apr 2019 06:37:50 -0400 Subject: [Haskell-cafe] Type information in MVars In-Reply-To: <20190428095642.24txd56oiptw4jft@weber> References: <20190428095642.24txd56oiptw4jft@weber> Message-ID: <20190428103750.GP87116@straasha.imrryr.org> On Sun, Apr 28, 2019 at 10:56:42AM +0100, Tom Ellis wrote: > On Sun, Apr 28, 2019 at 12:45:24PM +0300, Georgi Lyubenov wrote: > > There are obviously a lot of cool tricks you can do with phantom > > parameters, but they are all lost when you start looking at a `MVar` > > holding a type with a phantom parameter. > > That's an intriguing statement. Why are they lost? The types don't look lost to me at first blush: ghci> import Control.Concurrent.MVar ghci> import Data.Proxy ghci> let p = Proxy :: Proxy Int ghci> m <- newMVar p ghci> let q = Proxy :: Proxy Char ghci> x <- readMVar m ghci> q == x :20:6: error: • Couldn't match type ‘Int’ with ‘Char’ Expected type: Proxy Char Actual type: Proxy Int • In the second argument of ‘(==)’, namely ‘x’ In the expression: q == x In an equation for ‘it’: it = q == x ghci> modifyMVar_ m $ const $ return q :25:17: error: • Couldn't match type ‘Char’ with ‘Int’ Expected type: Proxy Int -> IO (Proxy Int) Actual type: Proxy Int -> IO (Proxy Char) • In the second argument of ‘($)’, namely ‘const $ return q’ In the expression: modifyMVar_ m $ const $ return q In an equation for ‘it’: it = modifyMVar_ m $ const $ return q -- Viktor. From godzbanebane at gmail.com Sun Apr 28 10:53:57 2019 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Sun, 28 Apr 2019 13:53:57 +0300 Subject: [Haskell-cafe] Type information in MVars In-Reply-To: <20190428103750.GP87116@straasha.imrryr.org> References: <20190428095642.24txd56oiptw4jft@weber> <20190428103750.GP87116@straasha.imrryr.org> Message-ID: Sorry! I phrased my question very pooryl and/or was not clear on what I exactly I had difficulty with. I have an external "machine" M, with some states and two IO actions that operate on M - A and B. A changes the state of the machine to "ready", and I want to enforce at the type level that B is always executed when M is "ready". I could normally do something like this by adding a phantom parameter to M, to track it's state and allow B to only be called with M "ready". This is fine, and I could use an indexed monad to not have to pass around M explicitly. However I cannot figure out how to enforce something like this when dealing with multiple threads, with more than one potentially executing A and/or B (changing the state or requiring the state to be changed). ======= Georgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From lysxia at gmail.com Sun Apr 28 12:00:56 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Sun, 28 Apr 2019 08:00:56 -0400 Subject: [Haskell-cafe] Agda's BUILTIN Naturals in Haskell In-Reply-To: References: Message-ID: Hi Georgi, That sounds like a use case for pattern synonyms. As its name suggests, it allows you to give constructor names to patterns. This is quite powerful when combined with view patterns, which allow patterns to use arbitrary logic. User Guide on pattern synonyms: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#pattern-synonyms pattern Z :: Integer pattern Z = 0 pattern S :: Integer -> Integer pattern S n <- (succ' -> Just n) where S n = n + 1 succ' :: Integer -> Maybe Integer succ' n | n > 0 = Just (n - 1) | otherwise = Nothing Cheers, Li-yao On 4/28/19 5:38 AM, Georgi Lyubenov wrote: > Hey, > > Is there any way to do something similar to what Agda does with natural > numbers via BUILTIN pragmas? > More precisely I want to have correct-by-construction natural numbers, that > at runtime are treated as `Integer`s. My initial idea was to abuse rewrite > rules to turn `data N = Z | S N` into `Integer` terms somehow, but I'm not > sure if this is possible. > > ======= > Georgi > > > _______________________________________________ > 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. > From a.pelenitsyn at gmail.com Sun Apr 28 14:41:11 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Sun, 28 Apr 2019 10:41:11 -0400 Subject: [Haskell-cafe] Agda's BUILTIN Naturals in Haskell In-Reply-To: References: Message-ID: succ' in Li-yao's message is meant to be pred, I guess. -- Best, Artem On Sun, 28 Apr 2019, 8:01 am Li-yao Xia, wrote: > Hi Georgi, > > That sounds like a use case for pattern synonyms. As its name suggests, > it allows you to give constructor names to patterns. This is quite > powerful when combined with view patterns, which allow patterns to use > arbitrary logic. > > User Guide on pattern synonyms: > > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#pattern-synonyms > > pattern Z :: Integer > pattern Z = 0 > > pattern S :: Integer -> Integer > pattern S n <- (succ' -> Just n) where > S n = n + 1 > > succ' :: Integer -> Maybe Integer > succ' n | n > 0 = Just (n - 1) > | otherwise = Nothing > > Cheers, > Li-yao > > On 4/28/19 5:38 AM, Georgi Lyubenov wrote: > > Hey, > > > > Is there any way to do something similar to what Agda does with natural > > numbers via BUILTIN pragmas? > > More precisely I want to have correct-by-construction natural numbers, > that > > at runtime are treated as `Integer`s. My initial idea was to abuse > rewrite > > rules to turn `data N = Z | S N` into `Integer` terms somehow, but I'm > not > > sure if this is possible. > > > > ======= > > Georgi > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From komendantskaya at gmail.com Sun Apr 28 15:06:46 2019 From: komendantskaya at gmail.com (Ekaterina Komendantskaya) Date: Sun, 28 Apr 2019 16:06:46 +0100 Subject: [Haskell-cafe] PPDP'19 Deadline extension Message-ID: DEADLINE EXTENSION TO *10 MAY* - PPDP 2019 21st International Symposium on Principles and Practice of Declarative Programming 7–9 October 2019, Porto, Portugal Collocated with FM'19 http://ppdp2019.macs.hw.ac.uk ====================================================================== Important Dates --------------- Title and abstract registration 4 May 2019 (AoE) (extended) Paper submission 10 May 2019 (AoE) (extended) Rebuttal period (48 hours) 10 June 2019 (AoE) (extended) Author notification 20 June 2019 (extended) Final paper version 15 July 2019 Conference 7–9 October 2019 About PPDP ---------- The PPDP 2019 symposium brings together researchers from the declarative programming communities, including those working in the functional, logic, answer-set, and constraint handling programming paradigms. The goal is to stimulate research in the use of logical formalisms and methods for analyzing, performing, specifying, and reasoning about computations, including mechanisms for concurrency, security, static analysis, and verification. See http://ppdp2019.macs.hw.ac.uk for further information and information. Invited Speakers ---------------- Amal Ahmed Northeastern University, USA Title: TBA Naoki Kobayashi The University of Tokyo, Japan Title: 10 Years of the Higher-Order Model Checking Project Submission page: ---------------- https://easychair.org/conferences/?conf=ppdp19 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Tue Apr 30 09:54:39 2019 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Tue, 30 Apr 2019 09:54:39 +0000 Subject: [Haskell-cafe] MPC 2019 deadline extension Message-ID: ====================================================================== DEADLINE EXTENSION TO *10 MAY* -- MPC 2019 13th International Conference on Mathematics of Program Construction 7-9 October 2019, Porto, Portugal Co-located with Formal Methods 2019 https://tinyurl.com/MPC-Porto ====================================================================== TIMELINE: Abstract submission 7th May 2019 (AoE) (extended) Paper submission 10th May 2019 (AoE) (extended) Author notification 14th June 2019 Camera ready copy 12th July 2019 Conference 7-9 October 2019 KEYNOTE SPEAKERS: Assia Mahboubi INRIA, France Annabelle McIver Macquarie University, Australia BACKGROUND: The International Conference on Mathematics of Program Construction (MPC) aims to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs. MPC 2019 will be held in Porto, Portugal from 7-9 October 2019, and is co-located with the International Symposium on Formal Methods, FM 2019. Previous conferences were held in Königswinter, Germany (2015); Madrid, Spain (2012); Québec City, Canada (2010); Marseille, France (2008); Kuressaare, Estonia (2006); Stirling, UK (2004); Dagstuhl, Germany (2002); Ponte de Lima, Portugal (2000); Marstrand, Sweden (1998); Kloster Irsee, Germany (1995); Oxford, UK (1992); Twente, The Netherlands (1989). SCOPE: MPC seeks original papers on mathematical methods and tools put to use in program construction. Topics of interest range from algorithmics to support for program construction in programming languages and systems. Typical areas include type systems, program analysis and transformation, programming language semantics, security, and program logics. The notion of a 'program' is interpreted broadly, ranging from algorithms to hardware. Theoretical contributions are welcome, provided that their relevance to program construction is clear. Reports on applications are welcome, provided that their mathematical basis is evident. We also encourage the submission of 'programming pearls' that present elegant and instructive examples of the mathematics of program construction. SUBMISSION: Submission is in two stages. Abstracts (plain text, maximum 250 words) must be submitted by 7th May 2019. Full papers (pdf, formatted using the llncs.sty style file for LaTex) must be submitted by 10th May 2019. There is no prescribed page limit, but authors should strive for brevity. Both abstracts and papers will be submitted using EasyChair. Papers must present previously unpublished work, and not be submitted concurrently to any other publication venue. Submissions will be evaluated by the program committee according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. Accepted papers must be presented in person at the conference by one of the authors. The proceedings of MPC 2019 will be published in the Lecture Notes in Computer Science (LNCS) series, as with all previous instances of the conference. Authors of accepted papers will be expected to transfer copyright to Springer for this purpose. After the conference, authors of the best papers from MPC 2019 and MPC 2015 will be invited to submit revised versions to a special issue of Science of Computer Programming (SCP). For any queries about submission please contact the program chair, Graham Hutton . PROGRAM COMMITTEE: Patrick Bahr IT University of Copenhagen, Denmark Richard Bird University of Oxford, UK Corina Cîrstea University of Southampton, UK Brijesh Dongol University of Surrey, UK João F. Ferreira University of Lisbon, Portugal Jennifer Hackett University of Nottingham, UK William Harrison University of Missouri, USA Ralf Hinze University of Kaiserslautern, Germany Zhenjiang Hu National Institute of Informatics, Japan Graham Hutton (chair) University of Nottingham, UK Cezar Ionescu University of Oxford, UK Mauro Jaskelioff National University of Rosario, Argentina Ranjit Jhala University of California, USA Gabriele Keller Utrecht University, The Netherlands Ekaterina Komendantskaya Heriot-Watt University, UK Chris Martens North Carolina State University, USA Bernhard Möller University of Augsburg, Germany Shin-Cheng Mu Academia Sinica, Taiwan Mary Sheeran Chalmers University of Technology, Sweden Alexandra Silva University College London, UK Georg Struth University of Sheffield, UK CONFERENE VENUE: The conference will be held at the Alfândega Porto Congress Centre, a 150 year old former custom's house located in the historic centre of Porto on the bank of the river Douro. The venue was renovated by a Pritzer prize winning architect and has received many awards. LOCAL ORGANISERS: José Nuno Oliveira University of Minho, Portugal For any queries about local issues please contact the local organiser, José Nuno Oliveira . ====================================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From jake.waksbaum at gmail.com Tue Apr 30 18:25:06 2019 From: jake.waksbaum at gmail.com (Jake) Date: Tue, 30 Apr 2019 14:25:06 -0400 Subject: [Haskell-cafe] Agda's BUILTIN Naturals in Haskell In-Reply-To: References: Message-ID: I also think it makes sense to allow the O pattern to match any number less than or equal to 0 to make our functions total. So putting it all together, we get something like {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE PatternSynonyms #-} import Prelude hiding (pred) leZero :: Int -> Maybe Int leZero n | n <= 0 = Just 0 | otherwise = Nothing pred :: Int -> Maybe Int pred n | n > 0 = Just (n - 1) | otherwise = Nothing pattern O <- (leZero -> Just n) where O = 0 pattern S n <- (pred -> Just n) where S n = n + 1 fib :: Int -> Int fib O = 1 fib (S n) = (S n) * fib n On Sun, Apr 28, 2019 at 10:41 AM Artem Pelenitsyn wrote: > succ' in Li-yao's message is meant to be pred, I guess. > > -- > Best, Artem > > On Sun, 28 Apr 2019, 8:01 am Li-yao Xia, wrote: > >> Hi Georgi, >> >> That sounds like a use case for pattern synonyms. As its name suggests, >> it allows you to give constructor names to patterns. This is quite >> powerful when combined with view patterns, which allow patterns to use >> arbitrary logic. >> >> User Guide on pattern synonyms: >> >> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#pattern-synonyms >> >> pattern Z :: Integer >> pattern Z = 0 >> >> pattern S :: Integer -> Integer >> pattern S n <- (succ' -> Just n) where >> S n = n + 1 >> >> succ' :: Integer -> Maybe Integer >> succ' n | n > 0 = Just (n - 1) >> | otherwise = Nothing >> >> Cheers, >> Li-yao >> >> On 4/28/19 5:38 AM, Georgi Lyubenov wrote: >> > Hey, >> > >> > Is there any way to do something similar to what Agda does with natural >> > numbers via BUILTIN pragmas? >> > More precisely I want to have correct-by-construction natural numbers, >> that >> > at runtime are treated as `Integer`s. My initial idea was to abuse >> rewrite >> > rules to turn `data N = Z | S N` into `Integer` terms somehow, but I'm >> not >> > sure if this is possible. >> > >> > ======= >> > Georgi >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> > >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: