August 2020 - Haskell-Cafe

ICFP tutorial on hardware design using BH (Bluespec Haskell)
by Rishiyur Nikhil 20 Aug '20

20 Aug '20

REMINDER: My tutorial "Designing Hardware Systems and Accelerators with Open-Source BH (Bluespec Haskell)" on Aug 23 at #ICFP2020 (online). Please pre-install tools; instructions in tutorial repo README: https://tinyurl.com/y29zxrow . ICFP web page: https://icfp20.sigplan.org . #RISCV #Bluespec #BSV #BH.

1 0

Dhall for Word8, Word16, Double, etc
by ☂Josh Chia (謝任中) 19 Aug '20

19 Aug '20

Hi, Let's say I have a record type: data Foo = Foo { v :: Word16 } I want to have a FromDhall instance for Foo. I know this is easy to do if v is Integer instead of Word16. But v is Word16. Does Dhall enable the user to cleanly express how to input a Word16 with the requisite range checks, or is the user expected to only use Integer and do his own conversion and range checks within Haskell after inputting the Integer from Dhall? I have a record with Word32, Word16, Word8 & Double fields instead of Integer & Scientific.

3 3

Third Call for Participation: ICFP 2020
by Sam Tobin-Hochstadt 19 Aug '20

19 Aug '20

===================================================================== Third Call for Participation ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 23 - August 28, 2020 Online http://icfp20.sigplan.org/ Pre-registration ends August 21! ==================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. Watch our new video, and Don't Stop ICFP: https://www.youtube.com/watch?v=Fte5wwnwCws Pre-registration ends August 21st! https://icfp20.sigplan.org/attending/Registration This year, the conference will be a virtual event. All activities will take place online. There are training sessions for Clowdr, our new online platform, on August 20 and 21. https://icfp20.sigplan.org/track/icfp-2020-clowdr-training#program The main conference will take place from August 24-26, 2020 during two time bands. The first band will be 9AM-5:30PM New York, and will include both technical and social activities. The second band will repeat (with some variation) the technical program and social activities 12 hours later, 9AM-5:30PM Beijing, the following day. We've written a blog post about how conference mirroring will work for ICFP: https://blog.sigplan.org/2020/08/04/come-to-virtual-icfp/ We’re excited to announce our two invited speakers for 2020: Evan Czaplicki, covering the Elm programming language and hard lessons learned on driving adoption of new programming languages; and Audrey Tang, Haskeller and Taiwan’s Digital Minister, on how software developers can contribute to fighting the pandemic. ICFP has officially accepted 37 exciting papers, and (as a fresh experiment this year) there will also be presentations of 8 papers accepted recently to the Journal of Functional Programming. Co-located symposia and workshops will take place the day before and two days immediately after the main conference. Registration is now open. The early registration deadline is August 8th, 2020. Registration is not free, but is significantly lower than usual. Students who are ACM or SIGPLAN members may register for FREE before the early deadline. https://regmaster.com/2020conf/ICFP20/register.php New this year: Attendees will be able to sign-up for the ICFP Mentoring Program (either to be a mentor, receive mentorship or both). * Overview and affiliated events: http://icfp20.sigplan.org/home * Full Schedule: https://icfp20.sigplan.org/program/program-icfp-2020 * Accepted papers: http://icfp20.sigplan.org/track/icfp-2020-papers#event-overview * JFP Talks: https://icfp20.sigplan.org/track/icfp-2020-jfp-talks#event-overview * Registration is available via: https://regmaster.com/2020conf/ICFP20/register.php Early registration ends 8 August, 2020. * Programming contest: https://icfpcontest2020.github.io/ * Student Research Competition: https://icfp20.sigplan.org/track/icfp-2020-Student-Research-Competition * Tutorials https://icfp20.sigplan.org/track/icfp-2020-tutorials#program * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference This year, there are 10 events co-located with ICFP: * Erlang Workshop (8/23) * Haskell Implementors' Workshop (8/28) * Haskell Symposium (8/27-8/28) * Higher-Order Programming with Effects (8/23) * miniKanren Workshop (8/27) * ML Family Workshop (8/27) * OCaml Workshop (8/28) * Programming Languages Mentoring Workshop (8/23) * Scheme Workshop (8/28) * Type-Driven Development (8/23) As well as tutorials on 8/23, 8/27, and 8/28. ### ICFP Organizers General Chair: Stephanie Weirich (University of Pennsylvania, USA) Program Chair: Adam Chlipala (MIT, USA) Artifact Evaluation Co-Chairs: Brent Yorgey (Hendrix College, USA) Ben Lippmeier (Ghost Locomotion, Australia) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organizer: Igor Lukanin (Kontur, Russia) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Youyou Cong (Tokyo Institute of Technology, Japan) Workshops Co-Chair: Jennifer Hackett (University of Nottingham, UK) Leonidas Lampropoulos (University of Pennsylvania, USA) Video Chair: Leif Andersen (Northeastern University, USA) Student Volunteer Co-Chair: Hanneli Tavante (McGill University, Canada) Victor Lanvin (IRIF, Université Paris Diderot, France)

1 0

Re: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour
by Anthony Clayden 17 Aug '20

17 Aug '20

Well I'll go to 'foot of our stairs! > [Erik] the above feels very similar to writing something like: > add :: _ => a -> b -> _ > add x y = x + y > > But that doesn't type check, since the types `a` and `b` are not the same, > but `+` needs them to be. Replying to both Erik's and Tom's replies. I'm afraid Alexis' went completely over my head. As I mentioned, the `PatternSignatures` part of `ScopedTypeVariables` has been around a long time. So long that it's in Hugs 2006. The same? Not quite. If I try Tom's O.P. add (x :: aa) (y :: b) = x + y Hugs complains 'Type annotation uses distinct variables aa and b where a single variable was inferred'. So the short answer is: if that's how your intuitions go, use Hugs. My explanation was going to be (this now only applies for GHC): just as using `x, y` as the dummy arguments to `add` doesn't come with any guarantees they're distinct values; so using `aa, b` as the dummy variables doesn't come with any guarantees they're distinct types. Specifying distinct tyvars in a stand-alone signature is different: you're giving the most general type to which `add` must conform. And using distinct tyvars means `add` must cope with those being distinct types. (Which it's equation doesn't.) BTW GHC accepts: add (x :: aa) (y :: b) = (x + y :: aa) :: b which shows how happy it is to use distinct tyvars for the same type. AntC

1 0

Re: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour
by Anthony Clayden 17 Aug '20

17 Aug '20

Hi Tom, I see nothing bizarre nor counterintuitive. Perhaps you need to retrain your intuitions ;-) > I have just noticed that with ScopedTypeVariables one can write the > following bizarre definition > > -- Inferred signature: > -- add :: Num a => a -> a -> a > add (x :: a) (y :: b) = x + y What do you think is bizarre? GHC makes a reasonable attempt to use the tyvar names you put in a signature -- remembering that alpha-renaming means the name is not really significant. I can get `add :: Num c => c -> c -> c`, etc. > The reason for this behaviour is that > >>* in all patterns other than pattern bindings, a pattern type *>>* signature may mention a type variable that is not in scope; in this *>>* case, the signature brings that type variable into scope. * OK so your `PatternSignatures` (a part of `ScopedTypeVariables` that existed long before the more dubious parts of that extension) are bringing `a`, `b`, into scope. It might have been clearer if you'd used `b`, `c`, to avoid confusing yours with some `a` that might have been lurking in the environment. Anyhoo your definition is equivalent to this, by eta-reduction: add = (+) and `(+) :: Num a => a -> a -> a` from the Prelude. So the inferred signature for `add` must be the same, possibly alpha-renamed. Perhaps you think you could add an Int to a Float, as you can in languages (COBOL, Algol 68) with implicit type coercion? That's not what the signatures from the Prelude Num methods support. And with Haskell's proclivity for partial application, type inference would rapidly become incoherent; so we don't do that. > But this leads to a rather puzzling user experience. Was it really > not possible to design this extension in a way that would allow > bringing new type variables into scope locally but not allow them to > unify with other type variables from outer scopes? > > To be more concrete, what I would like to see is a design where `k` is > allowed because the type `a` (bound within a pattern) does not need to > unify with anything but `k2` is not allowed because `a` is forbidden > to unify with `b`. ... No: any tyvar might unify with any other. You can't ban tyvars from unifying. Unification would be useless if you can't unify globally. That's why all tyvars are (implicitly) universally quantified. (With the exception of existentially-quantified tyvars as you quote, which is another can of worms and we don't want to go there.) You can use as many distinct tyvars as you like, but if type inference resolves them to the same type, it must use the same tyvar in the inferred signature. > I believe this design might lead to much less puzzling behaviour. > Would it be possible (within a new extension, of course) or have I > overlooked something? There's the `GADTs` or `TypeFamilies` extensions that introduce `~` as a constraint-level equality on types. I suppose we might use that, but (thinking creatively) any of these would be a legitimate resulting signature; how should GHC choose amongst them? add :: (Num a, a ~ b) => a -> b -> a add :: (Num b, a ~ b) => a -> b -> b add :: (Num a, Num b, a ~ b) => a -> b -> a The point is: the return type for `add` aka `(+)` must be the same as the first argument type must be the same as the second argument type must be the same as the `Num` constraint applies to. Any of those three signatures I've given (and there could be several more in the same vein) obfuscates what's going on. Actually, thinking a bit more: we want to infer a 'Principal type' (see wikipedia). Precisely because there's no good reason to choose amongst those I gave, none of them can be Principal. AntC

3 2

Library for serial communications?
by Christian Gosch 14 Aug '20

14 Aug '20

Hi Haskellers, I was wondering if there is a "canonical" choice of library for using serial interfaces from within Haskell. I found a few in Hackage, but all of them seem to not have seen updates in a few years. Any hint is much appreciated. Christian

1 0

3rd Call for Papers: REBLS 20: Reactive and Event-Based Languages and Systems
by Ivan Perez 14 Aug '20

14 Aug '20

Dear all, Apologies if you see this multiple times. Gentle reminder that the REBLS workshop will take place online. The deadline has been extended till next week. Cheers, Ivan CALL FOR PAPERS 7th Workshop on Reactive and Event-based Languages and Systems (REBLS 2020) co-located with the SPLASH Conference *** BOTH EVENTS WILL NOW TAKE PLACE ONLINE *** Sun 15 - Fri 20 November 2020 Website: https://2020.splashcon.org/home/rebls-2020 IMPORTANT DATES Submission Deadline: 21 Aug 2020 (extended) Author Notification: 18 Sep 2020 Camera Ready Deadline: 9 Oct 2020 INTRODUCTION Reactive programming and event-based programming are two closely related programming styles that are becoming more important with the ever increasing requirement for applications to run on the web or on mobile devices, and the advent of advanced High-Performance Computing (HPC) technology. A number of publications on middleware and language design -- so-called reactive and event-based languages and systems (REBLS) -- have already seen the light, but the field still raises several questions. For example, the interaction with mainstream language concepts is poorly understood, implementation technology is still lacking, and modularity mechanisms remain largely unexplored. Moreover, large applications are still to be developed, and, consequently, patterns and tools for developing large reactive applications are still in their infancy. This workshop will gather researchers in reactive and event-based languages and systems. The goal of the workshop is to exchange new technical research results and to better define the field by developing taxonomies and discussing overviews of the existing work. We welcome all submissions on reactive programming, functional reactive programming, and event- and aspect- oriented systems, including but not limited to: * Language design, implementation, runtime systems, program analysis, software metrics, patterns and benchmarks. * Formal models for reactive and event-based programming. * Study of the paradigm: interaction of reactive and event-based programming with existing language features such as object-oriented programming, pure functional programming, mutable state, concurrency. * Modularity and abstraction mechanisms in large systems. * Advanced event systems, event quantification, event composition, aspect-oriented programming for reactive applications. * Functional Reactive Programming (FRP), self-adjusting computation and incremental computing. * Synchronous languages, modeling real-time systems, safety-critical reactive and embedded systems. * Applications, case studies that show the efficacy of reactive programming. * Empirical studies that motivate further research in the field. * Patterns and best-practices. * Related fields, such as complex event processing, reactive data structures, view maintenance, constraint-based languages, and their integration with reactive programming. * Implementation technology, language runtimes, virtual machine support, compilers. * IDEs, Tools. The format of the workshop is that of a mini-conference. Participants can present their work in slots of 30 mins with Q&A included. Because of the declarative nature of reactive programs, it is often hard to understand their semantics just by looking at the code. We therefore also encourage authors to use their slots for presenting their work based on live demos. SUBMISSIONS REBLS encourages submissions of two types of papers: * Full papers: papers that describe complete research results. These papers will be published in the ACM digital library. * In-progress papers: papers that have the potential of triggering an interesting discussion at the workshop or present new ideas that require further systematic investigation. These papers will not be published in the ACM digital library. Format: * Submissions should use the ACM SIGPLAN Conference acmart Format with the two-column, sigplan Subformat, 10 point font, using Biolinum as sans-serif font and Libertine as serif font. All submissions should be in PDF format. If you use LaTeX or Word, please use the ACM SIGPLAN acmart Templates. The page http://www.sigplan.org/Resources/Author/#acmart-format contains instructions for authors, and a package that includes an example file acmart-sigplan.tex. * Authors are required to explicitly specify the type of paper in the submission (i.e., full paper, in-progress paper). * Full papers can be *up to* 12 pages in length, excluding references. In-progress papers can be *up to* 6 pages, excluding references. Papers do not need to make use of all pages, but they will be summarily rejected if they exceed the page limits. Instructions for the Authors: * Papers should be submitted through: https://rebls20.hotcrp.com/ * For fairness reasons, all submitted papers should conform to the formatting instructions. Submissions that violate these instructions will be summarily rejected. * Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. * Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy (http://www.sigplan.org/Resources/Policies/Republication) Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism. * All submissions are expected to comply with the ACM Policies for Authorship detailed at https://www.acm.org/publications/authors/information-for-authors. PROGRAM COMMITTEE Ivan Perez (PC Chair; NIA) Alan Jeffrey, Mozilla Research. Christiaan Baaij, QBayLogic. César Sánchez, IMDEA Software. Daniel Winograd-Cort, Target Corp. Edward Amsden, Black River Software, LLC. Guerric Chupin, University of Nottingham. Heinrich Apfelmus. Jonathan Thaler, University of Applied Sciences Vorarlberg. Louis Mandel, IBM Research. Manuel Bärenz, sonnen eServices GmbH. Marc Pouzet, Université Pierre et Marie Curie. Mark Santolucito, University of Yale. Neil Sculthorpe, University of Nottingham Trent. Noemi Rodriguez, Pontifícia Universidade Católica do Rio de Janeiro Oleksandra Bulgakova, Sukhomlynsky Mykolaiv National University Patrick Bahr, University of Copenhagen Takuo Watanabe, Tokyo Institute of Technology Tetsuo Kamina, Oita University Tom Van Cutsem, Nokia Bell Labs Yoshiki Ohshima, HARC / Y Combinator Research STEERING COMMITTEE Guido Salvaneschi, TU Darmstadt, Germany Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium Patrick Eugster, Universita della Svizzera Italiana, Switzerland Francisco Sant'Anna, Rio de Janeiro State University, Brazil Lukasz Ziarek, SUNY Buffalo, United States For any questions, please use the form on the website or contact the Chair at ivan.perezdominguez(a)nasa.gov

1 0

[ANN] base64-bytestring-1.2.0.0
by Emily Pillmore 13 Aug '20

13 Aug '20

Hi everyone! I’m pleased to announce base64-bytestring-1.2.0.0. In this release, we cleared out the backlog of outstanding feature requests, correctness, and security fixes to present a new stable release. This constituted a major version bump due to the fact that the fixes changed the semantics of the decode function for some inputs, making the decoding process more correct than it was previously. To illustrate one of the changes to correctness, here’s a quick quiz: ``` What are the correct results of Base64-decoding the strings "ZK==“, "Zm9vYE==“, or "Zm9vYmD=" ? ``` The answer is: the decoding should fail. Why? Even though the above strings may look like externally valid Base64 strings, they are technically impossible to construct such string via Base64-encoding from any binary data in the first place. Previously (and historically in every version up until this release), they would pass decoding, but fail to roundtrip: ``` П> decode "ZK==" Right "d" П> encode "d" "ZA==" П> decode "Zm9vYE==" Right "foo`" П> encode "foo`" "Zm9vYA==" П> decode "Zm9vYmD=" Right "foob`" П> encode "foob`" "Zm9vYmA=" ``` This was the result of leaking bits when decoding the final quanta of the bytestring. I caught this, and provided a fix. Now here’s an interesting point: there are very few libraries out there that actually address this problem! In fact, there was only one other library out there that I was able to find that was fully correct-per-RFC-spec, which was the Java Amazon SDK. So I guess we can be proud of Haskell in that sense now? I’ve implemented the same in my `base64` library on hackage using the same bitmasking verification techniques, so that one is up to date as well. Anyway, cheers and happy hacking, Emily

1 0

Is it a thunk?
by David Feuer 13 Aug '20

13 Aug '20

For testing purposes, I'd like to distinguish between thunks and non-thunks, to make sure that everything I require to be forced is. (I'd also like to know that nothing that's supposed to be lazy is forced, but that seems too hard to test in context.) Is there some magic I can use to check?

3 4

Fwd: Call for participation: Code generation tutorial on ICFP2020
by Michal J Gajda 13 Aug '20

13 Aug '20

Hello, I organize tutorial on code generation for ICFP2020. https://icfp20.sigplan.org/details/icfp-2020-tutorials/4/Best-Practices-in-… We invite participants interested in large scale code generation, including but not limited to: * large API bindings projects like Amazonka, * transpilers and compilers, * parser and data binding generation. We provide instruction and exercise templates in Haskell, but users of any functional programming language are welcome. After completing this tutorial, participants will be familiar with best current practices: * propagating source positions to final error messages. * useful monad transformers stacks, * tagging code for unidirectional or bidirectional code generation, * making code readable and debuggable by the end-user, * policy on releasing new versions, * techniques for automatic generation of changelogs, * managing version migrations, * reusing parsers for AST construction, * avoiding common issues with generated code. I encourage attendees to register their interests and requirements in advance: https://forms.gle/ETAhPxAprLHFWqyU6 Hope to see you there! -- Cheers Michał -- Pozdrawiam Michał

1 0