- Haskell-Cafe - Haskell.org

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

18 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 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 08 Aug '20

08 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

Call for Tutorial Participation: ICFP 2020
by Sam Tobin-Hochstadt 07 Aug '20

07 Aug '20

CALL FOR TUTORIAL PARTICIPATION ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 23 - 28, 2020 Virtual https://icfp20.sigplan.org/ Early Registration ends August 8! The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 23-28, 2020. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. This year, ICFP features a wide variety of tutorials on topics related to functional programming, including design, education, tools, and more. Tutorials are available to all ICFP participants with registration. Tutorials occur before or after ICFP, co-located with the associated workshops, on August 23 or August 27-28. The schedule of ICFP Tutorials can be found at: https://icfp20.sigplan.org/track/icfp-2020-tutorials#program ICFP Early Registration ends on August 8th, and is available at: https://icfp20.sigplan.org/attending/Registration

1 0

Core optimizations affected by package provenance
by Li-yao Xia 07 Aug '20

07 Aug '20

Hello Café, I've been testing properties of some optimized Core using the inspection-testing library. Some functions appear to be optimized differently depending on whether one of the package dependencies comes from Hackage or elsewhere. As far as I can tell, the source code is identical, and the only difference is whether or not I add the path to the local package in my cabal.project. Why would a dependency be compiled differently depending on where it comes from? Any suggestions on how to troubleshoot this? To be more concrete, the relevant packages are generic-random and splitmix. The following commands should reproduce the issue: git clone https://github.com/Lysxia/generic-random git clone https://github.com/phadej/splitmix cd generic-random # With local splitmix echo "packages: . ../splitmix" > cabal.project cabal test --flags="enable-inspect" # PASS # With remote splitmix echo "packages: ." > cabal.project cabal test --flags="enable-inspect" # FAIL It would be useful to know whether anyone can reproduce this behavior or not. Cheers, Li-yao PS, link to Github issue: https://github.com/Lysxia/generic-random/issues/22

1 1

ANN: network 3.1.2.0
by Evan Borden 07 Aug '20

07 Aug '20

I'm happy to announce the release of network 3.1.2.0. https://hackage.haskell.org/package/network-3.1.2.0 This version of network includes many improvements that allow more extensibility, portability, and greater test coverage. See the log below for more information. As well version 3.1.1.0 and 3.1.1.1 have been deprecated as they contain a bug in graceful close, more details below. - Added -f devel for test cases that are known to fail. #471 <https://github.com/haskell/network/pull/471> - Improved precedence-compliant Read/Show instances. Verified via QuickCheck. #465 <https://github.com/haskell/network/pull/465> #466 <https://github.com/haskell/network/pull/466> - Removed the racing graceful close implementation to avoid issues with CLOSE_WAIT. #460 <https://github.com/haskell/network/pull/438> - Gracefully handle binding of UNIX domain sockets. #460 <https://github.com/haskell/network/pull/460> - Replace Socket type and family with extensible CInt pattern and synonyms. #459 <https://github.com/haskell/network/pull/459> - Fixed race conditions in tests. #458 <https://github.com/haskell/network/pull/458> - Removed many legacy uses of undefined. #456 <https://github.com/haskell/network/pull/456> - Defined extensible CustomSockOpt via ViewPatterns. #455 <https://github.com/haskell/network/pull/455> - Defined openSocket in terms of AddrInfo. 5b0987197fe2ed7beddd7b2096522d624e71151e <https://github.com/haskell/network/commit/5b0987197fe2ed7beddd7b2096522d624…> - Improved FreeBSD portability for Control Messages and tests #452 <https://github.com/haskell/network/pull/452> - Support sendMsg and recvMsg #433 <https://github.com/haskell/network/pull/433> #445 <https://github.com/haskell/network/pull/445> #451 <https://github.com/haskell/network/pull/451> - Added sendMsg and recvMsg APIs - Redefined SocketOption as pattern synonym - Implement total Show functions for SockAddr #441 <https://github.com/haskell/network/pull/441> - Improve portability changing u_int32_t to uint32_t. #442 <https://github.com/haskell/network/pull/442> - Removed obsolete CPP statements. d1f4ee60ce6a4a85abb79532f64d4a4e71e2b1ce <https://github.com/haskell/network/commit/d1f4ee60ce6a4a85abb79532f64d4a4e7…> - Loads of improved test coverage. cbd67cc50a37770432eb978ac8b8eb6da3664817 <https://github.com/haskell/network/commit/cbd67cc50a37770432eb978ac8b8eb6da…> fcc2d86d53a6bec793f6a979a9e8fdf7fe3f4c22 <https://github.com/haskell/network/commit/fcc2d86d53a6bec793f6a979a9e8fdf7f…> 6db96969b3e8974abbfd50a7f073baa57376fd5e <https://github.com/haskell/network/commit/6db96969b3e8974abbfd50a7f073baa57…> As always, thank you to network's contributors!

1 0

Second Call for Participation: ICFP 2020
by Sam Tobin-Hochstadt 07 Aug '20

07 Aug '20

===================================================================== Second 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/ Early Registration ends August 8! ==================================================================== 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 Early Registration ends August 8th! Registration for students with an ACM or SIGPLAN membership is free, and anyone can apply for a fee waiver at: https://icfp20.sigplan.org/attending/Registration This year, the conference will be a virtual event. All activities will take place online. 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 * 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) ### 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

stack: pandoc fails to build as dependency
by Olaf Klinke 06 Aug '20

06 Aug '20

Dear cafe, I am baffled to learn that stack does not provide builds as reproducible as advertised. I have a project that depends on pandoc. It builds fine on my Debian 9 machine. Then I check out the project on a Debian 8 machine. Downloading and building pandoc-2.7.3 with the latest stack-2.1.3 on the Debian 8 machine runs fine. Now I create a new project, using the same stack.yaml as in the pandoc-2.7.3 package, except now pandoc-2.7.3 is an extra-dep. The project's only module contains nothing but: module Test where import Text.Pandoc Building this project with the same stack results in a linker error: pandoc > Preprocessing executable 'pandoc' for pandoc-2.7.3.. pandoc > Building executable 'pandoc' for pandoc-2.7.3.. pandoc > [1 of 2] Compiling Main pandoc > [2 of 2] Compiling Paths_pandoc pandoc > Linking .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/pandoc/pandoc ... pandoc > collect2: error: ld returned 1 exit status pandoc > `gcc' failed in phase `Linker'. (Exit code: 1) This seems to be independent of the LTS version (the stack.yaml in pandoc-2.7.3 says lts-13.17 although lts-13.17 contains pandoc-2.5 and pandoc-2.7.3 is available only in 14.9). Can somebody hint what I am doing wrong? Should I file a bug report? Thanks Olaf

3 3

dates...
by Gregory Guthrie 06 Aug '20

06 Aug '20

I don't understand why the Julian conversion are given relative to 2019, instead of 2020, and don't seem to actually show the date index. Must be misreading the library specs? toJulianYearAndDay :: Day<https://hackage.haskell.org/package/time-1.6/docs/Data-Time-Calendar.html#t…> -> (Integer<https://hackage.haskell.org/package/base-4.8.1.0/docs/Prelude.html#t:Integer>, Int<https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Int.html#t:Int>) convert to proleptic Julian year and day format. First element of result is year (proleptic Julian calendar), second is the day of the year, with 1 for Jan 1, and 365 toJulian :: Day<https://hackage.haskell.org/package/time-1.6/docs/Data-Time-Calendar.html#t…> -> (Integer<https://hackage.haskell.org/package/base-4.8.1.0/docs/Prelude.html#t:Integer>, Int<https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Int.html#t:Int>, Int<https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Int.html#t:Int>) Source<https://hackage.haskell.org/package/time-1.6/docs/src/Data-Time-Calendar-Ju…> convert to proleptic Julian calendar. First element of result is year, second month number (1-12), third day (1-31). ---------------------------------------------------------------------------------- ds = "1/8/2020" day = parseTimeOrError True defaultTimeLocale "%-m/%-d/%Y" ds :: UTCTime getDay = toGregorian . utctDay getDayOfYear = toJulian . utctDay getDayYear = toJulianYearAndDay. utctDay main = do print day print $ getDay day print $ getDayYear day print $ getDayOfYear day 2020-01-08 00:00:00 UTC (2020,1,8) (2019,360) (2019,12,26) And; 2020-02-08 00:00:00 UTC (2020,2,8) (2020,26) (2020,1,26) Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

2 2

Best ways to achieve throughput, for large M:N ratio of STM threads, with hot TVar updates?
by YueCompl 06 Aug '20

06 Aug '20

Hello Cafe, I'm working on an in-memory database, in Client/Server mode I just let each connected client submit remote procedure call running in its dedicated lightweight thread, modifying TVars in RAM per its business needs, then in case many clients connected concurrently and trying to insert new data, if they are triggering global index (some TVar) update, the throughput would drop drastically. I reduced the shared state to a simple int counter by TVar, got same symptom. While the parallelism feels okay when there's no hot TVar conflicting, or M is not much greater than N. As an empirical test workload, I have a `+RTS -N10` server process, it handles 10 concurrent clients okay, got ~5x of single thread throughput; but in handling 20 concurrent clients, each of the 10 CPUs can only be driven to ~10% utilization, the throughput seems even worse than single thread. More clients can even drive it thrashing without much progressing. I can understand that pure STM doesn't scale well after reading [1], and I see it suggested [7] attractive and planned future work toward that direction. But I can't find certain libraries or frameworks addressing large M over small N scenarios, [1] experimented with designated N parallelism, and [7] is rather theoretical to my empirical needs. Can you direct me to some available library implementing the methodology proposed in [7] or other ways tackling this problem? I think the most difficult one is that a transaction should commit with global indices (with possibly unique constraints) atomically updated, and rollback with any violation of constraints, i.e. transactions have to cover global states like indices. Other problems seem more trivial than this. Specifically, [7] states: > It must be emphasized that all of the mechanisms we deploy originate, in one form or another, in the database literature from the 70s and 80s. Our contribution is to adapt these techniques to software transactional memory, providing more effective solutions to important STM problems than prior proposals. I wonder any STM based library has simplified those techniques to be composed right away? I don't really want to implement those mechanisms by myself, rebuilding many wheels from scratch. Best regards, Compl [1] Comparing the performance of concurrent linked-list implementations in Haskell https://simonmar.github.io/bib/papers/concurrent-data.pdf <https://simonmar.github.io/bib/papers/concurrent-data.pdf> [7] M. Herlihy and E. Koskinen. Transactional boosting: a methodology for highly-concurrent transactional objects. In Proc. of PPoPP ’08, pages 207–216. ACM Press, 2008. https://www.cs.stevens.edu/~ejk/papers/boosting-ppopp08.pdf <https://www.cs.stevens.edu/~ejk/papers/boosting-ppopp08.pdf>

9 28

ANN: stack-2.3.3
by Emanuel Borsboom 06 Aug '20

06 Aug '20

See https://haskellstack.org/ for installation and upgrade instructions. Changes since v2.3.1 Other enhancements: * Add the stack-developer-mode flag Bug fixes: * When using the STACK_YAML env var with Docker, make the path absolute. * Fix the problem of stack repl foo:test:bar failing without a project build before that. See #5213<https://github.com/commercialhaskell/stack/issues/5213> * Fix stack sdist introducing unneded sublibrary syntax when using pvp-bounds. See #5289<https://github.com/commercialhaskell/stack/issues/5289> Thanks to all our contributors for this release: * coord.e * Dmitry Dzhus * Emanuel Borsboom * Kirill Zaborsky * Michael Snoyman

1 0

[ANN] isbn - ISBN Validation and Manipulation
by Christian Charukiewicz 31 Jul '20

31 Jul '20

Hello Haskell Cafe, I wanted to share my first ever Haskell package: isbn https://hackage.haskell.org/package/isbn The package is motivated by my need to validate ISBNs (the unique identifier associated with every book published since 1970) in a Haskell application I am building. I published isbn as a back in May but yesterday I made some improvements the API and I think it is now ready to share as v1.1.0.0. I have been using Haskell commercially for a few years, and have made several contributions to various packages, but as mentioned, this is my first time authoring and publishing a package. If anyone has any feedback, I would be happy to hear it. Thank you, Christian Charukiewicz

2 2

Re: [Haskell-cafe] STM friendly TreeMap (or similar with range scan api) ? WAS: Best ways to achieve throughput, for large M:N ratio of STM threads, with hot TVar updates?
by Peter Robinson 30 Jul '20

30 Jul '20

Hi Compl, > >+ This package provides a proof-of-concept implementation of a skip list >> in STM >> >> This has to mean something but I can't figure out yet. >> >> Dear Peter Robinson, I hope you can see this message and get in the loop >> of discussion. >> > The reason for adding this sentence was that tskiplist hasn't been optimized for production use. Later on, I wrote an implementation of a concurrent skip list with atomic operations that performs significantly better, but it's operations work in the IO monad. I'm surprised to hear that you're getting poor performance even when using the stm-container package, which I believe was meant to be used in production. A while ago, I ran some benchmarks comparing concurrent dictionary data structures (such as stm-container) under various workloads. While STMContainers.Map wasn't as fast as the concurrent-hashtable package, the results indicate that the performance doesn't degrade too much under larger workloads. You can find these benchmark results here (10^6 randomly generated insertion/deletion/lookup requests distributed among 32 threads): https://lowerbound.io/blog/bench2-32.html And some explanations about the benchmarks are here: https://lowerbound.io/blog/2019-10-24_concurrent_hash_table_performance.html One issue that I came across when implementing the tskiplist package was this: If a thread wants to insert some item into the skip list, it needs to search for the entry point by performing readTVar operations starting at the list head. So, on average, a thread will read O(log n) TVars (assuming a skip list of n items) and, if any of these O(log n) TVars are modified by a simultaneously running thread, the STM runtime will observe a (false) conflict and rerun the transaction. It's not clear to me how to resolve this issue without access to something like unreadTVar (see [1]). Best, Peter [1] UnreadTVar: Extending Haskell Software Transactional Memory for Performance (2007) by Nehir Sonmez , Cristian Perfumo , Srdjan Stipic , Adrian Cristal , Osman S. Unsal , Mateo Valero.

3 3

Subtyping CoC
by james faure 29 Jul '20

29 Jul '20

Hello, I am working on a subtyping calculus of constructions: https://github.com/jfaure/Nimzo, based on Algebraic Subtyping [1] The goal is to leverage the synthesis of subtyping with the CoC for general purpose programming, both for the usual correctness guarantees, but additionally exceptional type inference and powerful optimizations by using subtyping relations on dependent types. I spent the last year researching the theory and practice for this, and with the compiler at now just over 3000 lines of Haskell, I feel like I am no longer advancing as quickly as I would like, so if anyone is interested in helping create this language of the future, please get in touch ! [1]: https://www.cs.tufts.edu/~nr/cs257/archive/stephen-dolan/thesis.pdf James Faure (Discord: J4#0303)

2 1

Job: Medical Solutions with Haskell in Freiburg (German speaker required)
by David Leuschner 28 Jul '20

28 Jul '20

Dear Haskellers, our team is very happily and successfully using Haskell in production for over 10 years. We're currently hiring german-speaking/learning, full-time, on-site Haskell developers to work on user-friendly web- and mobile applications for doctors, nurses, patients and all other people involved. We have a very experienced team and we're looking for new-comers that are eager to learn as well as we're looking for experienced Haskell developers. We'd love to hear from you! Please look at our full announcement on Reddit: https://www.reddit.com/r/haskell/comments/hy8tuv/medical_solutions_with_has… Kind regards, David -- David Leuschner Entwicklungsleitung Lohmann & Birkner Software Solutions GmbH Alt-Reinickendorf 25 13407 Berlin Email: leuschner(a)cp-med.com Web: http://www.checkpad.de Lohmann und Birkner Software Solutions GmbH Geschaeftsfuehrer: Dr. Ruediger Lohmann Handelsregister: Amtsgericht Berlin-Charlottenburg HRB 130806 B

1 0

How to understand the 320-byte heap footprint of UUID ?
by YueCompl 28 Jul '20

28 Jul '20

Hello Cafe, I'm about to introduce UUID into my code, and see https://github.com/haskell-hvr/uuid/issues/24 <https://github.com/haskell-hvr/uuid/issues/24> stating: > Currently, UUID is represented as data UUID = UUID {-# UNPACK #-} !Word32 {-# UNPACK #-} !Word32 {-# UNPACK #-} !Word32 {-# UNPACK #-} !Word32 > However, this suboptimal for 64bit archs (where GHC currently stores this a 320-byte Heap object); ... According to https://wiki.haskell.org/GHC/Memory_Footprint <https://wiki.haskell.org/GHC/Memory_Footprint> I can understand each evaluated `Word32` on 64-bit hardware can take 2 words - 16 bytes, and given they are unpacked and strict, I think one whole UUID record should just take 64 bytes plus a few words, which is far less than 320 bytes. So how comes the 320 bytes? Thanks with regards, Compl

3 2

how to get live info on thread scheduling?
by Johannes Waldmann 25 Jul '20

25 Jul '20

Dear Cafe, With Control.Concurrent, I would want to know, for a ThreadId, the total (up to now) (wallclock) time it was running/paused by the RTS scheduler. I guess that the scheduler's actions can be written to the eventlog for later analysis. Can I access them from inside a running program? I guess this is https://gitlab.haskell.org/ghc/ghc/-/wikis/event-log/live-monitoring , what is the status? - J.

1 0

GADT/Typeable/existential behaviour that I don't understand
by Tom Ellis 24 Jul '20

24 Jul '20

I can define the following import Data.Typeable data Foo where Foo :: Typeable x => x -> Foo eq = (\a b -> eqT) :: (Typeable a, Typeable b) => a -> b -> Maybe (a :~: b) and then these expressions work as expected > case Foo "Hello" of Foo x1 -> case eq x1 "" of { Nothing -> "It was not a string"; Just Refl -> "It was a string" } "It was a string" > case Foo 1 of Foo x1 -> case eq x1 "" of { Nothing -> "It was not a string"; Just Refl -> "It was a string" } "It was not a string" But if I omit the 'Nothing' branch (as below) I get "Couldn't match expected type ‘p’ with actual type ‘[Char]’ ‘p’ is untouchable". Can anyone explain why this happens? > case Foo "Hello" of Foo x1 -> case eq x1 "" of { Just Refl -> "It was not a string" } > case Foo 1 of Foo x1 -> case eq x1 "" of { Just Refl -> "It was not a string" }

3 5

Question about zippers on trees
by Dominik Schrempf 24 Jul '20

24 Jul '20

Hello Cafe! I am trying to modify a large 'Data.Tree.Tree'. I managed to modify node labels with specific indices in the form of @[Int]@ as they are defined in, for example, 'Control.Lens.At.Ixed' or 'Lens.Micro.GHC'. However, I also need to 1. modify the node label using information from nearby nodes (e.g., the children); 2. modify the tree structure itself; for example, I may want to change the sub-forest. Basically, I need a lens that focuses not on the node label, but on the node itself. I perceived that this is more difficult. I tried to use 'Control.Zipper'. I can use zippers to achieve point 1, albeit in a complicated way: (1) I need to go downwards to focus the specific node; (2) I need to traverse the children to collect data and save the data somewhere (how? in let bindings?); (3) I then go back upwards and change the node label using the collected data. Even so, I do not really manage to change the actual structure of the tree. I also briefly had a look at plates, but do not manage to use them in a proper way, maybe because the depth of my structures may be several hundred levels. Did you encounter similar problems in the past or could you point me to resources discussing these issues? Thank you! Dominik

5 7

Re: [Haskell-cafe] Question about zippers on trees
by Olaf Klinke 23 Jul '20

23 Jul '20

> A direct implementation without using a library is interesting, thank > you. I > refrained from doing that, because I thought that Control.Zipper > would actually > do this for me. Actually, I was pretty successful with using > Control.Zipper to > change node labels, but failed doing more complicated stuff. > Isn't that a strong indicator that zippers are an improper abstraction for your purpose? Perhaps after rolling your own implementation you can more easily discover how to represent the algrorithm as a zipper. Olaf

2 1

ghc profiling
by Mika Pöhls 22 Jul '20

22 Jul '20

Hello everyone, I have a question regarding ghc profiling. The .hp file, created during profiling, displays the memory usage until a certain point, which seems to be the end of the execution of the program (based on the exectuion time the program usually takes), as exprected. But after that an extra sample is created, that contains no data (no cost centers, it is just begin sample followed by end sample). This sample is also created out of the 0.1 second gaps used before. For example the last "correct" sample is at 17s and the empty sample is at 40s. When plotting the data, this results in an monotonous increasing graph (for all centers), that has its maximum at the last correct sample (17s) followed by a straight line to zero (40s). Does anyone know, what leads to this behavior and how it can be prevented? Thanks in advance Mika

2 1

Fwd: Judge for programming language contest?
by Michal J Gajda 22 Jul '20

22 Jul '20

Hi, I just noticed that in the age of cambrian explosion among new programming languages we also have programming language jam organized this August: https://blog.repl.it/langjam Given that there are many prolific programming language designers and implementors here -- I wonder if we get a Haskell judge so that advanced type systems can get a fair ruling? (In case you got another round of reviews from traditional PL conferences that described your paper as "badly typeset" and "wrong formatting was intentional", "repetitive" and "hard to understand", or even rude "expect a boring talk".) -- Cheers Michał

1 0

Haskell Love Conference (the 31st of July & 1st of August, 2020)
by Ida Bzowska 20 Jul '20

20 Jul '20

Hi There! We are organizing the online event on Haskell language https://haskell.love, free to attend. The CFP for the event has started (ends on the 1st of July, 2020), please consider joining https://konfy.care/cfp Tickets (free) will be available soon, follow us on twitter https://twitter.com/_haskellove for the updates and feel free to hop on our slack http://tinyurl.com/haskelloveslack λCheers Ida Bzowska

3 7

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.8.4 is now available
by Gregory Guthrie 19 Jul '20

19 Jul '20

I don't see any windows binaries listed; are they there, elsewhere? Lots of Linux (=0.7% desktop market share) versions, but Windows (=78%) only source?. ---------------------------------------------------------------- -----Original Message----- From: Haskell-Cafe <haskell-cafe-bounces(a)haskell.org> On Behalf Of haskell-cafe- On Wed, Jul 15, 2020 at 07:38:31PM -0400, Ben Gamari wrote: > The GHC team is proud to announce the release of GHC 8.8.4. The source > distribution, binary distributions, and documentation are available at > > https://downloads.haskell.org/~ghc/8.8.4

3 5

What causes this "Ambiguous type variable" message (involving an existential type)?
by James Cook 18 Jul '20

18 Jul '20

Hi haskell-cafe, I've run into a strange error. It's easy for me to work around, but I still would like to know what causes it. Here's a minimal example. {-# LANGUAGE Rank2Types #-} module Example where data T = T (forall n . (Show n) => n) d :: a -> Int d = undefined f :: T -> Int f (T t) = d t when I try to compile it (ghc Example.hs) I see the following error: Example.hs:11:13: error: • Ambiguous type variable ‘a0’ arising from a use of ‘t’ prevents the constraint ‘(Show a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’ ...plus 22 others ...plus 12 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the first argument of ‘d’, namely ‘t’ In the expression: d t In an equation for ‘f’: f (T t) = d t | 11 | f (T t) = d t | ^ My question: what causes this error? This seems backward to me. The way I see it, I've told the compiler that any value of type T is guaranteed to contain a value of a type implementing Show, so there should be no question about solving a constraint involving Show. Moreover, the function "d" doesn't even require its input to implement Show. I'm guessing there's some basic rule about existential types that I'm violating here, but I'm not sure where to look if I want to read about that. I've skimmed https://wiki.haskell.org/Existential_type and didn't find anything, but maybe I skimmed too quickly. (Note: if I use Num or Fractional instead of Show, I don't get the error. I guess it's because of defaulting rules for numeric type classes.) If you're interested in how I ran into this, here's a summary. I have this type Scene g with two record fields. Notice the gl_camera_info field doesn't mention the type parameter g. data Scene g where Scene :: RandomGenD g => { part_ :: Part g , gl_camera_info :: GLCameraInfo } -> Scene g Then later I have an existentially quantified scene passed to the VScene constructor here... data BaseVal = VIint Int | VS String | VScene (forall g . (RandomGenD g) => Scene g) | VIO (ShellState -> IO ShellState) | VError String data Val = Val { val_f :: Val -> Val , val_base :: BaseVal } and later (somewhere inside a "where" clause): f (Val _ (VScene scene)) = base_val (VIO (fork_render (gl_camera_info scene) (RLS.muts scene 5e-2 1e-1))) (I don't think the definitions of base_val or RLS.muts matter here.) The use of gl_camera_info seems to cause the problem in this case. I see Shell.hs:137:79: error: • Ambiguous type variable ‘g0’ arising from a use of ‘scene’ prevents the constraint ‘(RandomGenD g0)’ from being solved. Probable fix: use a type annotation to specify what ‘g0’ should be. These potential instances exist: instance [safe] RandomGenD g => RandomGenD (RList g) -- Defined in ‘RList’ instance [safe] RandomGenD StdGen -- Defined in ‘Rand’ • In the first argument of ‘gl_camera_info’, namely ‘scene’ In the first argument of ‘fork_render’, namely ‘(gl_camera_info scene)’ In the first argument of ‘VIO’, namely ‘(fork_render (gl_camera_info scene) (RLS.muts scene 5e-2 1e-1))’ | 137 | f (Val _ (VScene scene)) = base_val (VIO (fork_render (gl_camera_info scene) (RLS.muts scene 5e-2 1e-1))) | ^^^^^ My planned solution is simply to not use an existential type here. I can just make g a parameter of the BaseVal type. But I'm still curious to understand what went wrong. -- James

1 1

[ANNOUNCE] GHC 8.8.4 is now available
by Ben Gamari 17 Jul '20

17 Jul '20

Hello everyone, The GHC team is proud to announce the release of GHC 8.8.4. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.4 Release notes are also available [1]. This release fixes a handful of issues affecting 8.8.3: - Fixes a bug in process creation on Windows (#17926). Due to this fix we strongly encourage all Windows users to upgrade immediately. - Works around a Linux kernel bug in the implementation of timerfd (#18033) - Fixes a few linking issues affecting ARM - Fixes "missing interface file" error triggered by some uses of Data.Ord.Ordering (#18185) - Fixes an integer overflow in the compact-normal-form import implementation (#16992) - `configure` now accepts a `--enable-numa` flag to enable/disable `numactl` support on Linux. - Fixes potentially lost sharing due to the desugaring of left operator sections (#18151). - Fixes a build-system bug resulting in potential miscompilation by unregisteised compilers (#18024) As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.4/docs/html/users_guide/8.8.4-notes.h…

2 1

Final Call for Tutorials, Discussions, and Social Events: ICFP 2020
by Sam Tobin-Hochstadt 16 Jul '20

16 Jul '20

FINAL CALL FOR TUTORIAL, DISCUSSION, AND SOCIAL EVENT PROPOSALS ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 23 - 28, 2020 Virtual https://icfp20.sigplan.org/ The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 23-28, 2020. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". To increase social interaction on the first ICFP virtual conference, this year we invite proposals for social events on topics of broader interest to the PL community. Such events can be panels and discussions (in the lines of the successful #ShutDownPL event), focused discussions (e.g., problem identifications, retrospective analysis, technical demos), social activities (e.g., treasure hunt, bingo, problem solving, artistic challenges). The typical duration of such events ranges from 30 minutes to one hour, but can be of any length. Tutorials may occur before or after ICFP, co-located with the associated workshops, on August 23 or August 27-28. Social events may be scheduled throughout the week. ---------------------------------------------------------------------- Submission details Deadline for submission: July 17th, 2020 Notification of acceptance: July 22nd, 2020 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2020 workshop co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020(a)googlegroups.com by July 17th, 2020. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by July 22nd, 2020. The proposal form is available at: http://www.icfpconference.org/icfp2020-files/icfp20-panel-form.txt http://www.icfpconference.org/icfp2020-files/icfp20-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2020 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Leonidas Lampropoulos (University of Maryland) General Chair: Stephanie Weirich (University of Pennsylvania) Program Chair: Adam Chlipala (MIT) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020(a)googlegroups.com

1 0

How does the RTS "know" about ExitCode
by Georgi Lyubenov 16 Jul '20

16 Jul '20

Hi! I'm wondering how values stored in ExitCode "get to" the RTS (i.e. actually make the program exit with the given number). As far as I can tell ExitCode is used as an everyday normal-looking exception (which are defined entirely in "library code", by using the raise#/catch# primitives), without any direct link to the RTS. What am I missing? ====== Georgi

2 2

setting ISO-8859-1 encoding on Raspbian for GHC
by Henning Thielemann 15 Jul '20

15 Jul '20

On Raspbian Buster I get: pi@raspberrypi:~ $ LANG=de_DE ghc -e 'print System.IO.localeEncoding' UTF-8 pi@raspberrypi:~ $ LANG=de_DE.iso88591 ghc -e 'print System.IO.localeEncoding' UTF-8 pi@raspberrypi:~ $ LANG=de_DE@euro ghc -e 'print System.IO.localeEncoding' UTF-8 Which is not, what I want. On Debian Buster it is correct: $ LANG=de_DE ghc -e 'print System.IO.localeEncoding' ISO-8859-1 How can I check whether this is a GHC problem and has anyone an idea how to fix it?

3 4

Second call for draft papers for IFL 2020 (Implementation and Application of Functional Languages)
by Jurriaan Hage 15 Jul '20

15 Jul '20

Hello, Please, find below the second 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

containers-0.6.3.1
by David Feuer 15 Jul '20

15 Jul '20

At long last, we have released containers-0.6.3.1. The most important changes in this release are bug fixes for IntMap traversals: * Fix traverse and traverseWithKey for IntMap, which would previously produce invalid IntMaps when the input contained negative keys (Thanks, Felix Paulusma). * Fix the traversal order of various functions for Data.IntMap: traverseWithKey, traverseMaybeWithKey, filterWithKeyA, minimum, maximum, mapAccum, mapAccumWithKey, mapAccumL, mapAccumRWithKey, mergeA (Thanks, Felix Paulusma, Simon Jakobi). These now traverse in key order; previously they would traverse non-negative keys before negative keys. If you traverse any IntMaps, please take note of these changes. We also have several additions to the API: * Add compose for Map and IntMap (Thanks, Alexandre Esteves). * Add alterF for Set and IntSet (Thanks, Simon Jakobi). * Add Data.IntSet.mapMonotonic (Thanks, Javran Cheng). * Add instance Bifoldable Map (Thanks, Joseph C. Sible). Performance improvements of note: * Make (<*) for Data.Sequence incrementally asymptotically optimal (Thanks, David Feuer). This finally completes the task, begun in December 2014, of making all the Applicative methods for sequences asymptotically optimal even when their results are consumed incrementally. Many thanks to Li-Yao Xia and Bertram Felgenhauer for helping to clean up and begin to document this rather tricky code. * Speed up fromList and related functions in Data.IntSet, Data.IntMap and Data.IntMap.Strict (Thanks, Bertram Felgenhauer). * Use count{Leading,Trailing}Zeros in Data.IntSet internals (Thanks, Alex Biehl). There are also numerous documentation improvements and packaging updates. Please see the changelog for full details. Thanks to all the contributors, The containers team

2 1

Call for Participation: ICFP 2020
by Sam Tobin-Hochstadt 14 Jul '20

14 Jul '20

===================================================================== 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/ Early Registration until August 8! The ICFP Programming Contest starts on July 17! ===================================================================== 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. This year, the conference will be a virtual event. All activities will take place online. The ICFP Programming competition will be July 17th through 20th, 2020! 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’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 * 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/ The Programming Contest begins July 17th! * Student Research Competition: https://icfp20.sigplan.org/track/icfp-2020-Student-Research-Competition * 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) ### 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] Caching functions compiled with llvm-hs
by Tom Westerhout 12 Jul '20

12 Jul '20

On 11/07/2020, Georgi Lyubenov <godzbanebane(a)gmail.com> wrote: > Is there something wrong with your idea? (other than ideological issues > with unsafePerformIO - I guess then the standard approach would be to use > some State holding your compiled functions or a Reader over an MVar holding > your compiled functions) The part that feels wrong here is that one has to create a new Module for every single function. I always thought of LLVM Modules as kind of compilation units. Or is this an okay-ish approach? > > The only thing you should make sure to do is add a NOINLINE to wherever the > unsafePerformIO is, so that it doesn't get inlined and executed more than > once. Oh I totally forgot! Thank you for reminding! Cheers, Tom

2 2

Caching functions compiled with llvm-hs
by Tom Westerhout 12 Jul '20

12 Jul '20

Hello, Suppose I've written some function f :: Foo -> Bar using LLVM IR. Now I'd like to compile it on first invocation with llvm-hs and cache the obtained function pointer. Basically something like this f :: Foo -> Bar f x = fImpl x where fImpl = unsafePerformIO $ flag <- isAlreadyCompiled -- check the cache if flag fetchFunc -- get the compiled code from cache else compileWithLLVM -- build LLVM IR, compile it, and update the cache A very primitive JIT compiler. What is the best way to do this with llvm-hs? All standard examples using LLVM.OrcJIT or LLVM.ExecutionEngine show how to compile a function and then immediately execute it. I can't quite figure out a safe way to keep the FunPtr... Big code bases like Accelerate or JuliaLang do achieve this somehow, but are quite difficult to understand for the uninitiated. Any advice is highly appreciated! Cheers, Tom

2 2

Re: [Haskell-cafe] Test on identity?
by Olaf Klinke 11 Jul '20

11 Jul '20

> Am 09.07.20 um 20:26 schrieb Olaf Klinke: > > Joachim Durchholz wrote: > >> This "identity is equality under change" definition captures not > >> just > >> two objects at identical addresses, but also proxies, network > >> objects, > >> files, and whatever there is. > >> > >> Step 3: Realize that if you have an immutable object, there is no > >> relevant difference between equality and identity anymore. (You > can > >> make > >> various formal statements about this.) > > > > Is that what is called "extensional equality"? Values a,b :: A are > > extensionally equal if they behave the same in all contexts. > > To fully treat this, you have to explore some pretty interesting > waters. > > First, "all contexts" can mean pretty different things. > E.g. in Haskell (without unsafe* and similar), everything is > immutable, > so you have contexts that exist in languages with mutability but not > in > Haskell, and you'd have to define what "all contexts" means for a > general term like "extensional equality". > > Second, "behave the same" means that for all functions, the result it > equal. > That's a recursive definition. You need fixed-point theory to turn > that > statement into an actual definition. > And that's surprisingly tricky. > > One fixed point is to say "the largest set of equal objects", which > means everything is equal to everything - fits the above definition > (applying any function to anything will trivially return results > that > are equal under this definition), but is obviously not what we > wanted. > > Another one would be to have what we'd intuitively define as > equality. > Say, in Haskell, the minimum set of equalities that makes different > constructor calls unequal. (Plus a handful of clerical definitions > to > catch special cases like integers.) > > Another one would be to have what we'd intuitively define as > identity. > > Plus various other fixed points. > > For example, consider proxies - say, an object that talks to a > remote > machine to produce its function results. > Now if you assume a proxy for integer values, is the proxy equal to > an > arbitrary integer you may have locally? > Again, this depends on what fixed point you choose for your equality > definition. You can define that as an exception, you consider two > objects equal if their functions return equal results, except for > those > that inspect the proxy-specific state; then proxy and local value > are > equal. Or you don't make an exception, then the two are not equal. > From a mathematical standpoint, either fixed point will satisfy the > above recursive definition (definition template, if you will). From > a > computing standpoint, you'll find that depending on context, you > want > one or the other! > > There are different types of proxy objects, and you can have > different > kinds of equality depending on how you treat them. > > That multitude of equality functions is pretty useless in a > programming > context; nobody wants to mentally deal with a gazillion of subtly > different equalities! > So I belive what one should do in practice is to have converter > functions. E.g. one that turns an Int proxy into an Int, merely by > stripping the proxy-specific functions. > That keeps the special cases to the place where they belong - all > those > types that have funky special kinds of equality. > Mutable data is another case of this. The equality of a mutable > object > can be defined as identity, and a converter function returns an > immutable copy so that equality is what's usually considered "value > equality" (equals() in Java). > (Languages that do not cleanly separate mutable and immutable types > will > still have to deal with two equalities, value equality and > identity... > well, the above is type and language design theory, practical > languages > are always a set of trade-offs, restricted by the limited knowledge > and > experience of the language designer. I guess that's why we have so > many > programming languages.) > I find it easier to intuitively define what extensional inequality means: As a domain theorist I declare two values unequal if there is an open set (a semi-decidable property) containing one but not the other value. For pure types t (not involving IO) that means there is a function semidecide :: t -> () that returns () for the one value and bottom for the other. I can not say how this would extend to impure types and I tend to agree with you that the notion of equality then depends on the intended semantics. Below the semidecision would have type t -> I0 () However, using StableName (thanks, Zemyla and Viktor!) indeed one is able to detect sharing. It works only after forcing the values, though. Apparently StableName does not work on thunks. Olaf ghci> import System.Mem.StableName ghci> import Control.Applicative ghci> data Ex = Val Int | Add Ex Ex deriving (Show) ghci> a = Add (Val 1) (Val 1) ghci> b = let v = Val 1 in Add v v ghci> show a "Add (Val 1) (Val 1)" ghci> show b "Add (Val 1) (Val 1)" ghci> let f :: Ex -> IO Bool; f (Val _) = return False; f (Add x y) = liftA2 eqStableName (makeStableName x) (makeStableName y) ghci> f a False ghci> f b True

1 0

Re: [Haskell-cafe] Test on identity?
by Johannes Waldmann 10 Jul '20

10 Jul '20

> Stable names are great! ... > I think they’re also used in eds ersatz package sortah. Yes. This is the package https://hackage.haskell.org/package/ersatz This is where they are used https://github.com/ekmett/ersatz/blob/master/src/Ersatz/Problem.hs#L149 - J.W.

1 0

Re: [Haskell-cafe] Test on identity?
by Olaf Klinke 10 Jul '20

10 Jul '20

Joachim Durchholz wrote: > This "identity is equality under change" definition captures not > just > two objects at identical addresses, but also proxies, network > objects, > files, and whatever there is. > > Step 3: Realize that if you have an immutable object, there is no > relevant difference between equality and identity anymore. (You can > make > various formal statements about this.) Is that what is called "extensional equality"? Values a,b :: A are extensionally equal if they behave the same in all contexts. That is, there is no type X and no function f :: A -> X such that f a can be observed to be different from f b, e.g. f a throws an exception and f b does not, or X is in Eq and f a /= f b. Can one write a function (even using reallyUnsafePtrEquality#) that distinguishes the following? a = Add (Val 1) (Val 1) b = let v = Val 1 in Add v v I tried: import GHC.Exts peq :: a -> a -> Bool peq x y = I# (reallyUnsafePtrEquality# x y) == 1 f :: Ex -> Bool f (Val _) = False f (Add x y) = peq x y But I get (even when I make the fields of Add strict): peq a a == True f a == False f b == False Olaf

5 4

Linking + zstd on FreeBSD
by Vanessa McHale 10 Jul '20

10 Jul '20

I tried linking against zstd within a Vagrant simulating FreeBSD. I get the following: ld: error: duplicate symbol: XXH64 >>> defined at xxhash.c >>> xxhash.o:(XXH64) in archive /home/vagrant/.cabal/store/ghc-8.8.3/zstd-0.1.2.0-c8ee757c8e8a7307779ab3cfbc91f3445940e16bbf8f9916f4c90432a0ac499e/lib/libHSzstd-0.1.2.0-c8ee757c8e8a7307779ab3cfbc91f3445940e16bbf8f9916f4c90432a0ac499e.a >>> defined at xxhash.c:693 (/wrkdirs/usr/ports/lang/ghc/work/ghc-8.8.3/rts/xxhash.c:693) >>> RTS.o:(.text.XXH64+0x0) in archive /usr/local/lib/ghc-8.8.3/rts/libHSrts.a ... I am using GHC version 8.8.3_1 and cabal-install 3.0 installed by 'sudo pkg install ...' (I was trying to run cabal install language-dickinson) Cheers, Vanessa McHale

4 6

Re: [Haskell-cafe] Test on identity?
by Olaf Klinke 09 Jul '20

09 Jul '20

> Dear Café, > > I'm trying to build a DAG from a binary tree. I don't think there's a > big trouble. > Nevertheless, I do even some transformations. Thus, I would like to > know it is still a > DAG, not adding, accidentally, a node. > > Is there any way, if I have data like > > data Ex > = Val Int > | Add Ex Ex > > so that I can test that some value Val i === Val i ? I mean, the > pointers go to the > same data box? I could do that via some IORefs, AFAIK, but I don't > think it is > feasible. Maybe to tune the algorithm... > > Best regards, > > Dusan So the binary tree is a value e :: Ex, right? And the DAG (directed acyclic graph) is an explicit representation of the internal pointer structure in e? Did I understand you right? This sounds like you should represent Ex as a fixed point and then invoke some fixed point magic like catamorphisms. Your transformation might have to be re-written as a cata/ana/hylomorphism, too. Below is a recipe to turn any element of any fixed point type into a graph, that is, into a list of nodes and edges. Of course this will loop if your data was not a finite DAG, e.g. due to self-reference. -- make type recursion for your type Ex explicit data ExF x = Val Int | Add x x deriving (Show) instance Functor ExF where fmap f (Val i) = Val i fmap f (Add x y) = Add (f x) (f y) instance Foldable ExF where foldMap _ (Val _) = mempty foldMap f (Add x y) = f x <> f y instance Traversable ExF where traverse f (Val i) = pure (Val i) traverse f (Add x y) = Add <$> (f x) <*> (f y) -- represent Ex via the general -- Fix :: (* -> *) -> * -- See e.g. package data-fix or recursion-schemes -- cataM below taken from the data-fix package type Ex = Fix ExF -- = Fix {unFix :: ExF (Fix ExF)} -- Add () () tells you the node is internal type ExNode = ExF () data GraphElem f = Node Int (f ()) | Edge Int Int instance Show (GraphElem ExF) where show (Node n (Val i)) = show n ++ ":Val " ++ show i show (Node n (Add _ _)) = show n ++ ":Add" show (Edge i j) = show i ++ " -> " ++ show j type Graph = [GraphElem ExF] type GraphM = StateT Int (Writer Graph) structure :: (Traversable f, MonadState Int m, MonadWriter [GraphElem f] m) => f Int -> m Int structure fi = do this <- get tell [Node this (void fi)] traverse (\child -> tell [Edge this child]) fi put (this+1) return this -- depth-first traversal. More generally dag has type -- (Traversable f) => Fix f -> [GraphElem f] -- and the Traversable instance determines the order -- of the traversal. dag :: Ex -> Graph dag = snd . runWriter . flip evalStateT 0 . cataM structure -- Cheers, Olaf

1 0

Test on identity?
by Dušan Kolář 08 Jul '20

08 Jul '20

Dear Café, I'm trying to build a DAG from a binary tree. I don't think there's a big trouble. Nevertheless, I do even some transformations. Thus, I would like to know it is still a DAG, not adding, accidentally, a node. Is there any way, if I have data like data Ex = Val Int | Add Ex Ex so that I can test that some value Val i === Val i ? I mean, the pointers go to the same data box? I could do that via some IORefs, AFAIK, but I don't think it is feasible. Maybe to tune the algorithm... Best regards, Dusan

4 4