- Haskell-Cafe - Haskell.org

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 15 Aug '20

15 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 14 Aug '20

14 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

New package: compact-sequences
by David Feuer 12 Aug '20

12 Aug '20

I've gotten the code I wrote for my Haskell Love talk into (just barely) good enough shape to make an initial release. So far, I have implemented stacks and queues that take n + O(log n) space, and whose basic operations take O(log n) time. I hope to add deques soon. More urgently, I need to write a test suite. Furthermore, I have written only "simple" versions, that directly use the mechanism described in my talk. To get decent performance, it will probably be necessary to add a layer on top of that. The package can be found at http://hackage.haskell.org/package/compact-sequences-0.1.0.0 David Feuer

1 0

Third call for draft papers for IFL 2020 (Implementation and Application of Functional Languages)
by Jurriaan Hage 11 Aug '20

11 Aug '20

Hello, Please, find below the third call for draft papers for IFL 2020. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ================================================================================ IFL 2020 32nd Symposium on Implementation and Application of Functional Languages venue: online 2nd - 4th September 2020 https://www.cs.kent.ac.uk/events/2020/ifl20/ ================================================================================ ### 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 2020 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 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 - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Post-symposium peer-review Following IFL tradition, IFL 2020 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 chair 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. ### Important dates Submission deadline of draft papers: 17 August 2020 Notification of acceptance for presentation: 19 August 2020 Registration deadline: 31 August 2020 IFL Symposium: 2-4 September 2020 Submission of papers for proceedings: 7 December 2020 Notification of acceptance: 3 February 2021 Camera-ready version: 15 March 2021 ### 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 ### 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. ### Programme committee Kenichi Asai, Ochanomizu University, Japan Olaf Chitil, University of Kent, United Kingdom (chair) Martin Erwig, Oregon State University,United States Daniel Horpacsi, Eotvos Lorand University, Hungary Zhenjiang Hu, Peking University, China Hans-Wolfgang Loidl, Heriot-Watt University, United Kingdom Neil Mitchell, Facebook, UK Marco T. Morazan, Seton Hall University, United States Rinus Plasmeijer, Radboud University, Netherlands Colin Runciman, University of York, United Kingdom Mary Sheeran, Chalmers University of Technology, Sweden Josep Silva, Universitat Politecnica de Valencia, Spain Jurrien Stutterheim, Standard Chartered, Singapore Josef Svenningsson, Facebook, UK Peter Thiemann, University of Freiburg, Germany Kanae Tsushima, National Institute of Informatics, Japan. Marcos Viera, Universidad de la Republica, Montevideo, Uruguay Janis Voigtlander, University of Duisburg-Essen, Germany ### Virtual symposium Because of the Covid-19 pandemic, this year IFL 2020 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here.

1 0

[ANN] Darcs 2.14.5 release
by Ben Franksen 08 Aug '20

08 Aug '20

Hi all, on behalf of the Darcs team, I would like to announce the release of Darcs 2.14.5: https://hackage.haskell.org/package/darcs-2.14.5 This is a bug-fix release and will be the latest release in the 2.14 series. In no way does it reflect the state of our development branch; instead it contains only a very small amount of changes needed to fix an ugly bug we recently discovered and which affects all previous versions in the 2.12 and 2.14 series. Upgrading is advised to avoid future incompatibilities. See the CHANGELOG for details. We will soon release 2.16.1 which will contain the large amount of work that has gone into darcs since the release of 2.14.0 more than two years ago. Cheers Ben

1 0

Where does the name "Algebraic data types" come from?
by Li-yao Xia 07 Aug '20

07 Aug '20

Dear Café, What makes "algebraic data types" algebraic? There are at least two common explanations in use: 1. Algebraic data types are defined using sums and products of types, by analogy with, well, concepts from algebra. 2. Algebraic data types are initial algebras. There are numerous blogs online explaining "algebraic data types" that way, with a large majority adopting the more approachable explanation (1). The question is, how did the appellation "algebraic" come about historically? Did it start with one or both of the meanings above? The language feature, independently of the name, seems attributed to the HOPE language[1] (see for instance A History of Haskell: Being Lazy with Class[2]). However, the paper introducing HOPE does not use the word "algebraic" anywhere. Other papers on the topic do not discuss the origins of the word. I am curious about citations regarding the history of the name "algebraic data types" itself. Regards, Li-yao [1]: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.8135 [2]: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history…

3 2