- Haskell-Cafe - Haskell.org

Haskell grammar ambiguity
by Li-yao Xia 16 Jun '21

16 Jun '21

Hello Café, With the BlockArguments proposal[1], the formal grammar of Haskell has become much nicer, with all of the "boring" expression constructs (i.e., other than function or operator application) under one non-terminal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0090-b… Its one flaw, inherited from Haskell2010, is ambiguity. I wonder whether that ambiguity is necessary. Currently, a meta-rule fixes that flaw: > The grammar is ambiguous regarding the extent of lambda abstractions, let expressions, and conditionals. The ambiguity is resolved by the meta-rule that each of these constructs extends as far to the right as possible. That is quite informal, so interpreting it takes a bit of thinking. 1. Does the rule make sense? That seems quite likely, but at the same time it seems to depend on some good behavior of the grammar. Like, aren't there grammars where such an "extend far to the right" meta-rule would itself be ambiguous? What's the key criterion for that meta-rule to make sense? 2. How to implement this rule? It might be obvious, with shift-reduce parsing ("shift always"). It also seems feasible with Earley parsing (the only other technique I am familiar with). But, either way, you have to dig into the internals of the chosen parsing method to resolve ambiguities. Instead, what if the grammar were unambiguous to start with? I share an attempt at the bottom of this email. Which brings me to my main two questions: 3. Is this grammar unambiguous? 4. Does it match the meta-rule? I also can't help but think about how it might look like in a hypothetical language report. 5. What are the pros and cons of using a ambiguous or unambiguous grammar for a programming language standard? A plausible starting point is thus: - An ambiguous grammar may be more readable (since there are strictly more choices available), especially if you care more about the AST than the concrete syntax. - An unambiguous grammar is easier to implement: just throw it into an Earley parser. This unambiguous grammar can somewhat easily be "flattened" into the ambiguous one from the report. That challenges the assumption that ambiguous grammars are generally more readable. In fact, the current ambiguous grammar already exposes other concrete syntax concerns (via the distinction between exp, infixexp, fexp, and aexp). In contrast, turning an ambiguous grammar into an unambiguous one takes a bit of effort (when it's possible at all). So if there are ambiguities worth keeping, is there a clear threshold? One other possible issue is that non-ambiguity is a fragile property, so extending the grammar requires extra care. Furthermore, even if the updated grammar is unambiguous, it might not be obvious that it still encodes the intent behind the meta-rule. That meta-rule may still be worth clarifying as a requirement for language extensions at least. Haskell syntax can be pretty, but the process behind it is a wee bit complicated. Regards, Li-yao --- # Unambiguous grammar for expressions (some rules omitted for brevity) # Compared to Haskell2010+BlockArguments, we move the rules for if, lambdas and lets into their own non-terminal rexp, and add four extra rules in exp, ensuring that rexp occurs only to the right end of function/operator applications. # Possibly simplifiable more # * and + represent repetition. # Expressions. exp -> iexp "::" type | iexp # EXTRA RULES with rexp | rexp | iexp qop rexp | iexp qop frexp | frexp # EXTRA SYMBOL rexp # Expressions with right-recursive syntax. rexp -> "if" exp "then" exp "else" exp | "\\" var "->" exp | "let" decls "in" exp # EXTRA (AUXILIARY) SYMBOL frexp # Function application with a trailing block argument. frexp -> aexp aexp* rexp # Infix expression (was infixexp). OLD iexp -> fexp (qop fexp)* # Optional function applications. OLD fexp -> aexp | aexp aexp+ # Atomic expressions. OLD with removed if/lambda/let aexp -> qvar | "[" "]" | "(" ")" | qcon | "(" exp ")" | "do" "{" stmts "}" | "case" exp "of" "{" alts "}"

5 8

IFL2021 second call for papers
by Pieter Koopman 15 Jun '21

15 Jun '21

================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> ================================================================================ News - Paper submission is now open: https://easychair.org/conferences/?conf=ifl21 <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . - Invited speakers are added: Stephanie Weirich and John Hughes - Sponsor added: Facebook Research <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> 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 2021 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. Industrial track and topics of interest This year's edition of IFL explicitly solicits original work concerning *applications* of functional programming in industry and academia. These contributions will be reviewed by experts with an industrial background. 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 specialisation * run-time code generation * partial evaluation * (abstract) interpretation * meta-programming * 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 * testing and proofing * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * applications of functional programming in the industry, including ** functional programming techniques for large applications ** successes of the application functional programming ** challenges for functional programming encountered ** any topic related to the application of functional programming that is interesting for the IFL community Post-symposium peer-review Following IFL tradition, IFL 2021 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chairs to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. 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 for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. Moreover, the proceedings will also be made publicly available as open access. Important dates Submission deadline of draft papers: 17 August 2021 Notification of acceptance for presentation: 19 August 2021 Registration deadline: 30 August 2021 IFL Symposium: 1-3 September 2021 Submission of papers for proceedings: 6 December 2021 Notification of acceptance: 3 February 2022 Camera-ready version: 15 March 2022 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 <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> The submission Web page for IFL21 is https://easychair.org/conferences/?conf=ifl21 <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured 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. Organisation IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands PC: Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary Virtual symposium Because of the Covid-19 pandemic, this year IFL 2021 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. [image: beacon]

1 0

ccall vs capi
by Julian Ospald 14 Jun '21

14 Jun '21

Hi, recently during a ghcup release, we stumbled over yet another `ccall` bug on Darwin: https://github.com/biegunka/terminal-size/pull/16 This took Ben some time to debug (thanks again) and it isn't always clear with such bugs whether something is wrong with GHC/RTS/GC or a library, so this can be a time-sink. It's also not the first time it happened: * https://github.com/haskell/unix/pull/110#issuecomment-613384845 * https://github.com/hasufell/hpath/commit/74d686547e67da3eeae327c84c63f83833… I can't say that I fully understood what the exact difference here is and why it seems to matter much more on Darwin than on other systems. So I think it would be helpful if we could come up with: 1. a clear description of the differences of ccall vs capi 2. an explanation why ccall can lead to terrible bugs on darwin 3. a guideline of when using one over the other is appropriate Not everyone deals with ffi on a regular basis, so I hope the experts here can shed some light! Cheers, Julian

3 2

Need advise with using Quickcheck
by Han Joosten 12 Jun '21

12 Jun '21

Dear café, I want to implement a roundtrip test for a parser/prettyprinter combination. Let me try to explain what I am struggling with. I start with some type definitions of functions I have *data Guarded a =* * Errors (NE.NonEmpty CtxError) | Checked a [Warning]* *parseFoo :: Text -> Guarded Foo* *prettyFoo :: Foo -> Text* The idea is that for all foo :: Foo, the following holds: *parseFoo . prettyFoo $ foo* should be equal to *Checked foo []* Now, if there is a counterexample, I would like to see prettyFoo foo as output, folowed by the show of the Errors part. I have been struggling to get this working, but without luck so far. I am not very familiar with Quickcheck, so that could be the problem too. Any help would be appreciated! Thanks Han

5 6

ZuriHac 2021 is happening in a week!
by Jasper Van der Jeugt 12 Jun '21

12 Jun '21

Hey folks, This is a final reminder that ZuriHac is taking place next weekend, Friday 18 June - Sunday 20 June 2021. Here are a couple of things to know: - You can register and join the Discord server through the following link: https://zureg.zfoh.ch/register/ - There will be the traditional pre-event socializing on Thursday, starting at 19:00 CEST. - We finalised the schedule, and there have been a couple of really cool additions. You can seee the calendar at https://zfoh.ch/zurihac2021/#schedule If you submitted a project, please ping us anytime on Discord in the #helpdesk channel, and we'll set up text and video channels for you. Happy hacking! The Zurich Friends of Haskell - https://zfoh.ch/

1 0

Optimizing Eq instances with reallyUnsafePtrEquality#
by Simon Jakobi 11 Jun '21

11 Jun '21

Hi everyone! In https://github.com/haskell-unordered-containers/unordered-containers/issues… we're wondering whether certain Eq instances, for example record types or strings, could be optimized by including a pointer equality check that detects when an object is compared with itself. Does anyone here have experience with such an optimization? Has this been considered before, for example in GHC's deriving machinery? One complication seems to be the correct handling of fields with irreflexive instances, for example Float and Double. In such a case, pointer equality doesn't imply "==-equality". I'm looking forward to hearing your thoughts on this! :) Cheers, Simon

6 7

Could optimize attoparsec if GHC would collapse `runParser (Parser parser)` to `parser`
by Tyson Whitehead 11 Jun '21

11 Jun '21

Hi. I'm hoping someone with some knowledge about GHC optimizations can weigh in and help out here. The attoparsec library has a `<|>` combinator for choice. Since attoparsec does arbitrary backtracking, you would expect that `recursiveLhs <|> rhs` would stack up a bunch of `rhs` alternatives to the depth of the recursion. Looking at the definitions though, would make you believe that so long as the `rhs` is constant as it usually is (e.g., `pure []` if you are collecting a list), inlining should result in it not stacking up a bunch of the `rhs` alternatives (intuitively the most recent one will always succeed so there is no reason to hold on to more than one). Unfortunately, it doesn't seem to work. The full details can be found in this bug report https://github.com/haskell/attoparsec/issues/186 but I believe it comes down to the fact that GHC is not collapsing a packing and immediate unpacking of the parser datatype ``` runParser (Parser parser) -> parser ``` which is resulting in the fact that the `rhs` always succeeds (i.e., doesn't use the failure continuation) not being exposed. I am hoping someone knowledgeable in these matters could weigh in. Thanks! -Tyson PS: The parser datatype is a wrapper on CPS style lambda ``` newtype Parser i a = Parser { runParser :: forall r. State i -> Pos -> More -> Failure i (State i) r -> Success i (State i) a r -> IResult i r } ``` where Failure and Success are type synonyms for the continuations ``` type Failure i t r = t -> Pos -> More -> [String] -> String -> IResult i r type Success i t a r = t -> Pos -> More -> a -> IResult i r ```

2 1

A matrix.org client library proposal
by Tristan Cacqueray 11 Jun '21

11 Jun '21

Dear Café, I'd like to publish a rather simple `matrix-client` package on hackage based on this implementation: https://github.com/softwarefactory-project/matrix-client-haskell Please let me know if you are interested or if you have a similar implementation we could collaborate on. Kind Regards, -Tristan

2 2

Hiring two Haskell devs at Standard Chartered bank
by José Pedro Magalhães 09 Jun '21

09 Jun '21

Hello, I'm hiring two Haskell devs for my team at Standard Chartered bank, in London, Singapore, or Hong Kong. My team sits in front office and has about 20 Haskell devs (well, technically Mu, our in-house variant). We work in close collaboration with trading, sales, and structuring to build diverse software, from desktop GUI applications to server-side financial analytics reports and services. The current roles are at a relatively junior level -- 2 to 5 years industrial experience expected, or a relevant PhD. Feel free to reach out to me directly if you're interested and have any questions, but applications should go via the links below. Singapore: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100014272 Hong Kong: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100014571 London: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100012204 Standard Chartered supports (practically fully) remote working, but only from the country of payroll. We will cover visa and relocation costs for successful applicants. Cheers, Pedro

1 0

Using stack outside the project box
by Galaxy Being 08 Jun '21

08 Jun '21

As a beginner, I was told to use stack. And I seemed to get something Haskell installed initially on my Ubuntu 21.04. But stack seems to be geared toward projects and compiling executables with ghc, and not a global ghci REPL-based way. I'm using Emacs org mode "Babel" which allows for a very nice "literate" programming in tandem with a running REPL in many REPL-friendly languages, e.g., here are code blocks in an org-mode file #+begin_src haskell :results silent :exports code data Peano = Zero | Succ Peano deriving (Show) #+end_src #+begin_src haskell :results silent :exports code myThree = Succ (Succ (Succ Zero)) #+end_src #+begin_src haskell :results verbatim :exports both myThree #+end_src #+RESULTS: : Succ (Succ (Succ Zero)) I simply hit Evaluate (Ctr-C Ctr-C) and the evaluation is handled by a running ghci REPL started up in another Emacs buffer. Supposedly, a haskell-mode and a specific Babel ob-haskell package are working together to enable this. And so it works okay, once quirks (must enclose multi-lined code in :{..:} and every REPL session seems to need a :set +m as well). I'm really quite happy with this way of doing things and have resisted the whole monolithic 1) create project in a directory, 2) put code into .hs file, 3) compile with ghc. But what I'm constantly having problems with is getting additional packages beyond the Prelude basics. My org files are in various directories, but I want (like most languages offer) to simply interact with that language on a global level wherever I am, whatever files and directories and Haskell code I'm working on. Sometimes doing an import works; often enough not. Then I have to do something with stack -- hopefully globally . . . and there the confusion and inconsistencies begin. Lately I can't seem to get Safe installed. And all docs about editing some yaml stuff get me lost in the weeds quickly. What yaml where for my "global" situation? If you simply say to me, Don't try to work outside of the project--hs files--compile to executable framework I'll say okay, then have to decide whether I want to stay within the org-mode world or leave Haskell for an org-mode friendlier language. And no, lhs and jupyter are primitive compared to org-mode literate programming. Both are a step backwards. Any help on working outside the project box with stack, e.g., how to install and use packages (and even how to update/upgrade ghc and ghci would be a start!). - ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf(a)gmail.com

6 14