- Haskell-Cafe - Haskell.org

Help with package/module naming
by David Feuer 15 May '23

15 May '23

I'm currently putting the finishing touches on the first version of a new priority queue package. It implements amortized-optimal priority queues and is intended to compete with the heaps package with a simpler, more compact, and hopefully faster implementation†. The main types are key-only and key-value priority queues, which I'm naming based on the conventions of the pqueue package: data MinQueue k data MinPQueue k a data MaxQueue k data MaxPQueue k a Additionally, the implementation uses underlying types with constant time insertion, logarithmic-time union, logarithmic time peekMin, and logarithmic time deleteMin: -- Key-value priority queues that are strict in both the key and the -- value. data MinPQueue k a -- Similar to the above, but associating -- two values with each key. The @a@ -- value is stored strictly and the @b@ value -- is stored lazily. data MinPQueue2 k a b So I have a few questions: 1. What should I name this package? 2. What should I name the modules containing the bootstrapped queues? 3. What should I name the modules containing the underlying oddly-strict queues? I don't know how many people will want to use them, but I figure they're probably just what's needed from time to time and it's better to let them loose than keep them under wraps. Finally, there is the question of how to expose internals. In addition to the queues above, with are all reasonable things for public consumption, there are modules implementing those, as well as a couple modules implementing helper types and such. I'm really no good at figuring out how to "lay out" modules in a package, so any advice would be greatly appreciated. † The heaps package uses bootstrapped skew binomial heaps (Brodal and Okasaki), achieving worst case constant-time union and peekMin and worst case logarithmic time deleteMin. The package I'm working on uses the same bootstrapping technique, but with a space-saving modification of Louis Wasserman's realization of Okasaki lazy binomial heap as the base priority queue. It achieves the same bounds, but union is only constant time in the (persistently) amortized sense; it degrades to logarithmic time in the worst case. In practice, this theoretical degradation likely doesn't matter, both because it's small and because GHC's garbage collection imposes occasional delays regardless.

2 3

QuickCheck update
by David Feuer 15 May '23

15 May '23

The latest QuickCheck release was uploaded to Hackage on 2020-11-14. There have been multiple commits to the master branch since then. konsumlamm opened an issue on 2023-03-10* requesting a new release. You responded positively, but there has been no visible progress towards that goal. Does QuickCheck need additional maintainers? * https://github.com/nick8325/quickcheck/issues/351

1 0

Is anybody on 9.6.1 having problems profiling on a Mac?
by George Colpitts 15 May '23

15 May '23

Is anybody on 9.6.1 having problems profiling on a Mac? As I reported in https://gitlab.haskell.org/ghc/ghc/-/issues/23211 ghc -prof -fprof-auto hello.hs where the file hello.hs consists of the line: main = print "hello" gets the error: Could not find module ‘Prelude’ Perhaps you haven't installed the "p_dyn" libraries for package ‘base-4.18.0.0’? It seems to me like a regression of the closed bug https://gitlab.haskell.org/ghc/ghc/-/issues/20707. Thanks George

3 10

ICFP 2023: Call for Tutorial, Panel, and Discussion Proposals
by ICFP Publicity 15 May '23

15 May '23

ICFP 2023 CALL FOR TUTORIAL, PANEL, AND DISCUSSION PROPOSALS 28th ACM SIGPLAN International Conference on Functional Programming September 4 - 9, 2023 Seattle, WA, USA https://icfp23.sigplan.org/ The 28th ACM SIGPLAN International Conference on Functional Programming will be held in Seattle, WA, USA on September 4 - 9, 2023, with the option of virtual participation. 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. The tutorials may target an audience who is interested in commercial uses of functional programming, 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". Just like last year, following the success of the #ShutDownPL event, we are also inviting proposals for panels and discussions on topics of broader interest to the PL community. Tutorials, panels, and discussions may occur before or after ICFP, co-located with the associated workshops, on September 4 or September 8-9. ---------------------------------------------------------------------- Submission details Deadline for submission: May 23rd, 2023 Notification of acceptance: May 26th, 2023 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2023 workshop co-chairs (Arthur Azevedo de Amorim and Yannick Forster), via email to icfp-workshops-2023 AT googlegroups.com by May 23rd, 2023. Please note that this is a firm deadline. The proposal form is available at: http://www.icfpconference.org/icfp2023-files/icfp23-panel-form.txt http://www.icfpconference.org/icfp2023-files/icfp23-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2023 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Arthur Azevedo de Amorim (Boston University) Workshop Co-Chair: Yannick Forster (Inria Nantes) General Chair: Nikhil Swamy (Microsoft Research) Program Chair: Sam Lindley (University of Edinburgh) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Arthur Azevedo de Amorim and Yannick Forster), via email to icfp-workshops-2023 AT googlegroups.com

1 0

Contributing packages?
by Dominick Samperi 13 May '23

13 May '23

I just tried to upload a new Haskell package and ran into some difficulties. If I just try to upload, it fails and says I need to contact somebody in the trustees group to be added to the Uploaders group. If I try to upload a package candidate instead, it says Forbidden, No access for this resource. The Uploading packages help page is not very helpful. Also, I have a Hackage account and I can get to the account management page, and generate an auth key, but I don't know what I can do with that. It seems the package candidate feature is the way to go, since direct uploads are irreversible and more difficult to manage. Any tips would be appreciated. Thanks, Dominick

4 7

Call for Papers: Functional Software Architecture - FP in the Large
by Graham Hutton 10 May '23

10 May '23

Dear all, The first workshop on "Functional Software Architecture - FP in the Large” will be held in Seattle in Sept 2023, co-located with the ICFP conference. Please share, and submit your best papers, experience reports, and architectural pearls on large-scale functional programming! The submission deadline 1st June 2023. Best wishes, Mike Sperber and Graham Hutton Program Chairs, FUNARCH 2023 ====================================================================== *** FUNARCH 2023 -- CALL FOR PAPERS *** The First ACM SIGPLAN Workshop on Functional Software Architecture - FP in the Large 8th September 2023, Seattle, Washington, USA Co-located with ICFP 2023 https://tinyurl.com/FUNARCH-23 ====================================================================== TIMELINE: Paper submission 1st June 2023 Author notification 28th June 2023 Camera ready copy 18th July 2023 Workshop 8th Sept 2023 BACKGROUND: "Functional Software Architecture" refers to methods of construction and structure of large and long-lived software projects that are implemented in functional languages and released to real users, typically in industry. The goals for the workshop are: - To assemble a community interested in software architecture techniques and technologies specific to functional programming; - To identify, categorize, and document topics relevant to the field of functional software architecture; - To connect the functional programming community to the software architecture community to cross-pollinate between the two. The workshop follows on from the Functional Software Architecture open space that was held at ICFP 2022 in Slovenia. SCOPE: The workshop seeks submissions in a range of categories: - You're a member of the FP community and have thought about how to support programming in the large, for example by framing functional ideas in architectural terms or vice verse, comparing different languages in terms of their architectural capabilities, clarifying architectural roles played by formal methods, proof assistants and DSLs, or observing how functional concepts are used in other language and architecture communities. Great, submit a research paper! - You're a member of the architecture community, and have thought about how your discipline might help functional programmers, for example by applying domain-driven design, implementing hexagonal architecture, or designing self-contained systems. Excellent, submit a research paper! - You've worked on a large project using functional programming, and it's worked out well, or terribly, or a mix of both; bonus points for deriving architectural principles from your experience. Wonderful, submit an experience report! - You know a neat architectural idiom or pattern that may be useful to others developing large functional software systems. Fabulous, submit an architectural pearl! - You have something that doesn't fit the above categories, but that still relates to functional software architecture, such as something that can be written up, or that could be part of the workshop format like a panel debate or a fishbowl. Superb, submit to the open category! Research papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and architectural pearls need not necessarily report original research results. The key criterion for such papers is that they make a contribution from which others can benefit. It is not enough simply to describe a large software system, or to present ideas that are specific to a particular system. Open category submissions that are not intended for publication are not required to follow the formatting guidelines, and can submit in PDF, word or plain text format as preferred. If you are unsure whether your contribution is suitable, or if you need any kind of help with your submission, please email the program chairs at <funarch2023(a)easychair.org>. SUBMISSION: Papers must be submitted by 1st June 2023 using EasyChair, via the following link: https://tinyurl.com/FUNARCH23-submit Formatting: submissions intended for publication must be in PDF format and follow the ACM SIGPLAN style guidelines, using the acmart format and the sigplan sub-format. Please use the review option, as this enables line numbers for easy reference in reviews. For further details, see: https://tinyurl.com/sigplan-acmart If your submission is not a research paper, please mark this using a subtitle (Experience Report, Architectural Pearl, Open Category). Length: submissions must adhere to the limits specified below. However, there is no requirement or expectation that all pages are used, and authors are encouraged to strive for brevity. Research papers 5 to 12+ pages Architectural pearls 5 to 12 pages Experience reports 3 to 6 pages Open category 1 to 6 pages Publication: The proceedings of FUNARCH 2023 will be published in the ACM Digital Library, and authors of accepted papers are required to agree to one of the standard ACM licensing options. Accepted papers must be presented at the workshop by one of the authors, but in special cases we may consider remote presentation. The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. PROGRAM CHAIRS: Mike Sperber Active Group, Germany Graham Hutton University of Nottingham, UK PROGRAM COMMITTEE: Joachim Breitner Germany Manuel Chakravarty Tweag & IOG, The Netherlands Ron Garcia University of British Columbia, Canada Debasish Ghosh LeadIQ, India Lars Hupel Giesecke+Devrient, Germany Andy Keep Meta, USA Shriram Krishnamurthi Brown University, USA Andres Löh Well-Typed, Germany Anil Madhavapeddy University of Cambridge, UK José Pedro Magalhães Standard Chartered, UK Simon Marlow Meta, UK Hannes Mehnert Robur, Germany Erik Meijer USA Ivan Perez KBR / NASA Ames Research Center, USA Stefanie Schirmer DuckDuckGo, Germany Perdita Stevens University of Edinburgh, UK Stefan Wehr Hochschule Offenburg, Germany Scott Wlaschin FPbridge, UK WORKSHOP VENUE: The workshop will be co-located with the ICFP 2023 conference at The Westin Seattle Hotel, Seattle, Washington, United States. ====================================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 1

Re: [Haskell-cafe] [Haskell] The Point of this List
by Anthony Clayden 05 May '23

05 May '23

Thanks Henning, I agree. o.p. Dominic on Haskell list > I have been subscribed to this list for over 20 years ... Well, yes 20+ years ago, Haskellers were a much smaller community; 'haskell' was the only list. If you want to understand the discussions around the 1998 standard for example, that's the place to look. 'haskell-cafe' has been going for at least most of that 20 years, and is the place for more free-flowing discussion. Increasingly, 'haskell' is restricted to low-volume announcements/not discussion. I'm surprised you hadn't noticed. AntC

1 0

pretty-printing with fixed indentation increase per sub-structure
by Johannes Waldmann 04 May '23

04 May '23

Dear Cafe, I was looking for a way to pretty-print Haskell literals (with lists, tuples, records with named and positional notation) like this example ( Leftist { tree = Branch { left = Branch { left = Leaf, key = 4, right = Leaf } , key = 3 , right = Leaf } , refs = listToFM [ ( Ref 13, [ 0 ] ), ( Ref 17, [ ] ) ] } , [ Any, Any ] ) for each sub-structure, the indentation level (for the following lines) should increase - by a _fixed_ amount. in the above example: line break after "tree = Branch". But (missing from this example), line break _before_ the list starts in "{ foo = [ 42 , ... ] ... }". I found this impossible to do with wl-pprint but perhaps I did not try hard enough. Instead, I "invented" combinators `nest` and `skip` and made this prototypical implementation https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/blob/master/todoc/src/Te… (it has some explanatory text at the top) see also https://gitlab.imn.htwk-leipzig.de/autotool/all0/-/issues/960 but certainly this cannot be a new idea. While I do like the semantics (in the context of my application), I don't like the performance of my implementation. What am I doing wrong? It's just updating indentation level and current position, this should not take any time at all? Of course, it would be best if I don't need the implementation at all - if the effect could be achieved via some combinators in established libraries (that have optimized implementation). Any pointers appreciated. Best regards - J.

4 4

Re: [Haskell-cafe] [Haskell] The Point of this List
by Henning Thielemann 04 May '23

04 May '23

On Thu, 4 May 2023, James Flanagan wrote: > Thank you for this tip. Wasn't aware of Haskell-Cafe. > > Maybe this is the right place for conference announcements then, if it's > just for announcements in general. haskell(a)haskell.org is intended for announcements of all kind, both conferences and Haskell software. I do not see a point in moving conference announcements to haskell-cafe and leave haskell(a)haskell.org for Haskell-unrelated conference spam. Btw. I moved the discussion to Haskell Cafe, because haskell(a)haskell.org is really for announcements not for discussion.

1 0

"Hey! Monad! Leave my Pure alone!"
by Scott Michel 26 Apr '23

26 Apr '23

For a number of years, I've been hacking on a Z80 processor simulator, on and off. It's generally pure code that resembles and uses State, et. al. The design issue I've run into is adding devices to the memory system, unsurprisingly typed as MemorySystem. Devices like to do I/O, which potentially "pollutes" a design with Monads. So... I'm soliciting suggestions that allow me to isolate Monadic code in the middle of pure code (which might be Quixotic, but I'll accept that risk.) MemorySystem uses interval maps containing memory regions, and a memory region can be a RAMRegion, ROMRegion or DeviceRegion. The abbreviated data declarations are: type MemRegionMap addrType wordType = IM.IntervalMap addrType (MemoryRegion addrType wordType) data MemorySystem addrType wordType where MSys :: { _regions :: MemRegionMap addrType wordType } -> MemorySystem addrType wordType data MemoryRegion addrType wordType where EmptyRegion :: MemoryRegion addrType wordType RAMRegion :: {- ... -} ROMRegion :: {- ... -} DevRegion :: {- ... -} RAMRegion-s and ROMRegion-s are unboxed vector containers, which makes reading and writing to them pure State code, i.e., the last two function arguments to the reading function are "MemorySystem ... -> (Vector wordType, MemorySystem ...)", viz: type MemReadN addrType wordType = (Vector wordType, MemorySystem addrType wordType) mReadN :: addrType -- ^ Starting address -> Int -- ^ Number of words to read -> MemorySystem addrType wordType -- ^ The memory system from which to read -> MemReadN addrType wordType Supporting DevRegion-s gets more complicated, because I/O is involved (we like consoles on our machines, yes, we do.) I'd like to keep the reader signature without unnecessarily injecting a Monad or Monad Transformer into MemoryRegion and MemorySystem, thereby keeping the Monad or transformer isolated in DevRegion. For example, an internal device reader function would have a signature similar to "... -> Device m devType -> (Vector wordType, m devType)" instead of "... -> Device m devType -> m (Vector WordType, devType)", where "m" is the Monad or transformer. I know, it's hard to jailbreak things out of a Monad, which may be answering my own question. However, it seems to me that this kind of problem occurs in real world Haskell, and I haven't encountered the real world solution. Ideas? -scooter

2 1