- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Add newtype for Alternative using QuantifiedConstraints in base-4.13
by Ruben Astudillo 18 Feb '19

18 Feb '19

I wonder if it is useful at all. If `f a` already has a Monoid instance, you can use `(<>)` already instead of (<|>) with pretty much the same laws. Plus you don't have to import `(<>)` as it comes from the Prelude where `(<|>)` doesn't. Does this have an use case or is just for aesthetic completeness? -- -- Ruben -- pgp: 4EE9 28F7 932E F4AD

1 0

Updating the dom-lt package
by Andreas Klebinger 18 Feb '19

18 Feb '19

I would like to have a updated version of dom-lt ( http://hackage.haskell.org/package/dom-lt ) on hackage. Matt Morrow uploaded the last version in 2009 and it has since become incompatible with current container versions. I'm posting here to make it known that I plan to take over the package to upload an update if I fail to reach him and he doesn't respond. (Which seems likely since the the domain is expired). Cheers Andreas Klebinger

2 1

Call For Presentations: Compose NYC, June 24-25, 2019
by MightyByte 17 Feb '19

17 Feb '19

Compose is a conference focused specifically on strongly typed functional programming languages. It will be held in New York on Monday and Tuesday, June 24 -25, 2019. Registration will be open shortly. http://www.composeconference.org/201 ( http://www.composeconference.org/2017 ) 9 To get a sense of Compose, you can check out the great talks from past conferences: https://www.youtube.com/channel/UC0pEknZxL7Q1j0Ok8qImWdQ ( https://www.youtube.com/channel/UC0pEknZxL7Q1j0Ok8qImWdQ ) Below is our call for presentations. http://www.composeconference.org/2019/cfp/ ( http://www.composeconference.org/2016/cfp/ ) In past years, we have also hosted an unconference over the weekend adjacent to the conference. The unconference details this year have not been finalized yet, but if you’re interested you may want to keep that in mind when making travel plans. *** Compose Conference NYC 2019 Call for Presentations June 24 -25, 2019 New York City The audience for Compose is people using Haskell, PureScript, OCaml, F#, SML, and other strongly typed functional programming languages who are looking to increase their skills or learn new technologies and libraries. Presentations should be aimed at teaching or introducing new ideas or tools. We are also interested in presentations aiming at taking complex concepts, such as program derivation, and putting them into productive use. However presentations on anything that you suspect our audience may find interesting are welcome. The following are some of the types of talks we would welcome: *Library/Tool Talks* — Exploring the uses of a powerful toolkit or library, be it for parsing, testing, data access and analysis, or anything else. *Production Systems* — Experience reports on deploying functional techniques in real systems; insights revealed, mistakes made, lessons learned. *Theory made Practical* — Just because it’s locked away in papers doesn’t mean it’s hard! Accessible lectures on classic results and why they matter to us today. Such talks can include simply introducing the principles of a field of research so as to help the audience read up on it in the future; from abstract machines to program derivation to branch-and-bound algorithms, the sky’s the limit. Check out the Compose YouTube channel ( https://www.youtube.com/playlist?list=PLNoHgLVTxtaoolkQo4hLy4ZsA1prUJ51m ) to see videos of talks we've had previously and get an idea of the kinds of topics we usually feature. We also welcome presentations for more formal tutorials. Tutorials should be aimed at a smaller audience of beginner-to-novice understanding, and ideally include hands-on exercises. The due date for submissions is *April 23, 2019*. We will send out notice of acceptance by *April 30th*. We prefer that submissions be via the EasyChair website ( https://easychair.org/conferences/?conf=compose2019 ( https://easychair.org/conferences/?conf=compose2019 ) ). Please suggest a title, and describe the topic you intend to speak on. Talks can be either 30 or 45 minutes, please indicate how much time you would prefer to take. You may submit multiple talks if you have several ideas and are unsure which would be the most likely to be accepted. Accepted talks will be asked to submit slides for review prior to the conference. Feel free to include any additional information on both your expertise and interesting elements of your topic that would be appropriate for inclusion in the public abstract. Furthermore, if your abstract doesn't feel "final"—don't worry! We'll work with you to polish it up. If you want to discuss your presentation(s) before submitting, or to further nail down what you intend to speak on, please feel free to contact us at nyc(a)composeconference.org ( nyc(a)composeconference.org ). We're happy to work with you, even if you are a new or inexperienced speaker, to help your talk be great. Diversity We would like to put an emphasis on soliciting a diverse set of speakers - anything you can do to distribute information about this CFP and encourage submissions from under-represented groups would be greatly appreciated. We welcome your contributions and encourage you to apply! Best, Doug Sent via Superhuman ( https://sprh.mn/?vip=mightybyte@gmail.com )

1 0

[ANN] stdio-0.1.0.0 - A simple and high performance IO toolkit for Haskell
by 寒东 17 Feb '19

17 Feb '19

Dear Haskellers! We're pleased to announce the first public version of stdio, a simple and high performance IO toolkit for Haskell. This package provides a simple and high performance IO toolkit for Haskell, including packed vectors, unicode texts, socket, file system, timers and more! The Hackage link is http://hackage.haskell.org/package/stdio-0.1.0.0. This project started as an experiment of combining libuv with GHC runtime, the result is recorded in our Haskell 2018 paper A High-Performance Multicore IO Manager Based on libuv (Experience Report) <https://github.com/haskell-stdio/stdio/blob/master/docs/A%20High-Performanc…> , which is pretty good comparing to the old IO manager in base. The IO manager part is stable and fast now. The package also provides new vector and new text type based on ByteArray# primitive, which is not limited to pinned memory. As GHC 8.6 release have added unaligned access primitives to ByteArray#, We think it's a good to release our work. The new vector and text (internal using UTF-8 encoding)'s performance is comparative to bytestring and text ones, and we strive to provide the similiar API. Some unicode processing such as normalization and casefolding is also provide, based on a C unicode library utf8rewind <https://bitbucket.org/knight666/utf8rewind>. To make our package more useful, we rebuild Builder and Parser type from groud, add TCP socket and filesystem support, so that user can start using it to do some simple task, such as parsing a CSV file or starting a TCP server and communicate in protocols. We also provide high performance timer and logger module, which is useful in practical engineering tasks. For installation guide and examples, please see the project's README. As we (I and Tao He) both are not native english speakers, the document quality is not as satisfying as it can be, please help! If you meet issues with installing, bugs, questions, please fill an issue on github: https://github.com/haskell-stdio/stdio. Happy hacking as always! Dong Han, Tao He Feb 16. 2019

4 3

Fwd: [ANN] stdio-0.1.0.0 - A simple and high performance IO toolkit for Haskell
by Dong Han 17 Feb '19

17 Feb '19

> In particular, I'd avoid utf8rewind because the author believes that deviating from a standard improves security. The length function is indeed problematic, so we roll our own, but the rest part of utf8rewind comply with Unicode 8.0 AFAICT, the code quality seems good too, but like you said, we're not going to commit to a specific UTF-8 implementation. As for now un8rewind seems a pretty good choice. > You should split the library, into stuff that does fast byte shoving, and into stuff that does fast byte processing. That way, things can start to improve and evolve independently. I just haven't got that much energy to do that, if we got lots of users some day, and people think spliting is better, then we can do that of course ; ) Cheers Dong On Sat, Feb 16, 2019 at 10:30 PM Joachim Durchholz <jo(a)durchholz.org> wrote: > Am 16.02.19 um 13:23 schrieb 寒东: > > Some unicode processing such as normalization and casefolding is also > provide, based on a C unicode libraryutf8rewind < > https://bitbucket.org/knight666/utf8rewind>. > > FWIW the rest looks fine, but committing to a specific UTF-8 > implementation is risky. Unicode is a large and complicated standard, > and constantly evolving; I am sceptical that a one-man library like > utf8rewind can keep up with that, and I'd wrap a mature Unicode library > (such as ICU) rather than place my bet on a one-man show like utf8rewind. > > In particular, I'd avoid utf8rewind because the author believes that > deviating from a standard improves security. > (See his comment in > > https://bitbucket.org/knight666/utf8rewind/issues/8/length-function-should-… > .) > I do not think that's a well-considered policy, and certainly does not > make me think that his code is well-audited. Including such a thing in > such a basic library as stdio seems unwise to me. > > > To make our package more useful, we rebuild Builder and Parser type from > groud, add TCP socket and filesystem support, so that user can start using > it to do some simple task, such as parsing a CSV file or starting a TCP > server and communicate in protocols. We also provide high performance timer > and logger module, which is useful in practical engineering tasks. > > You should split the library, into stuff that does fast byte shoving, > and into stuff that does fast byte processing. > That way, things can start to improve and evolve independently. > > > For installation guide and examples, please see the project's README. As > we (I and Tao He) both are not native english speakers, the document > quality is not as satisfying as it can be, please help! > > Judging from this message, your English seems pretty good actually :-) > > Regards, > Jo > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0

Does bytestring need help with maintenance?
by theindigamer 16 Feb '19

16 Feb '19

I noticed that there are bunch of issues and PRs, which have been open for a while without a response. I understand that the maintainers might not have the time to work on review/patches, is there a way in which I can help out? [Not sure if this is on-topic or if I should've posted it to the Libraries list.]

1 0

CFP: Haskell Symposium 2019
by Richard Eisenberg 15 Feb '19

15 Feb '19

================================================================================ ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2019 Berlin, Germany 22--23 August, 2019 http://www.haskell.org/haskell-symposium/2019/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2019 will be co-located with the 2019 International Conference on Functional Programming (ICFP). **NEW THIS YEAR**: We will be using a lightweight double-blind reviewing process. See further information below. The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * System Demonstrations, based on running software rather than novel research results. Regular 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 functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. Submission Details ================== Early and Regular Track ----------------------- The Haskell Symposium uses a two-track submission process so that some papers can gain early feedback. Strong papers submitted to the early track are accepted outright, and the others will be given their reviews and invited to resubmit to the regular track. Papers accepted via the early and regular tracks are considered of equal value and will not be distinguished in the proceedings. Although all papers may be submitted to the early track, authors of functional pearls and experience reports are particularly encouraged to use this mechanism. The success of these papers depends heavily on the way they are presented, and submitting early will give the program committee a chance to provide feedback and help draw out the key ideas. Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2019 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors’ own related work should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Early track: Submission deadline: 15 March 2019 (Fri) Notification: 19 April 2019 (Fri) Regular track and demos: Submission deadline: 10 May 2019 (Fri) Notification: 21 June 2019 (Fri) Camera-ready deadline for accepted papers: 30 June 2019 (Thu) Deadlines are valid anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/) and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism) The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell19.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors are free to upload both anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: Authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the principal editor will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Travel Support ============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC program, see its web page (http://pac.sigplan.org) Proceedings =========== Accepted papers will be included in the ACM Digital Library. Authors must grant ACM publication rights upon acceptance (http://authors.acm.org/main.html) Authors are encouraged to publish auxiliary material with their paper (source code, test data, etc.); they retain copyright of auxiliary material. Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. All accepted papers and proposals will be posted on the conference website one week before the meeting. Publication date: The official publication date of accepted papers is the date the proceedings 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 Committee ================= Ki-Yung Ahn Hannam University Christiaan Baaij QBayLogic B.V. José Manuel Calderón Trilla Galois, Inc Benjamin Delaware Purdue University Richard Eisenberg (chair) Bryn Mawr College Jennifer Hackett University of Nottingham Kazutaka Matsuda Tohoku University Trevor McDonnell Utrecht University Ivan Perez NIA / NASA Formal Methods Nadia Polikarpova University of California, San Diego Norman Ramsey Tufts University Christine Rizkallah University of New South Wales Eric Seidel Bloomberg LP Alejandro Serrano Mena Utrecht University John Wiegley Dfinity Foundation Thomas Winant Well-Typed LLP Ningning Xie University of Hong Kong If you have questions, please contact the chair at: rae(a)cs.brynmawr.edu ================================================================================

1 0

Extension and parameterized classes
by Pierre_van_der_Laar (Functional Account) 15 Feb '19

15 Feb '19

Dear Haskell experts, I working on a large Haskell project on Model Based Testing (see https://github.com/TorXakis/TorXakis) and I would like to get feedback on a design issue I have related to extension and parameterized classes. I will describe a small simplified example to illustrate the issue and I appreciate any feedback. I have a class that extends another class as follows: class Base a => Extend a where -- | Constructor from Base fromBase :: Base b => b -> a I can define an instance of Extend that hides the Base implementation as follows: {-# LANGUAGE ExistentialQuantification #-} data BaseHidden = forall a . Base a => BaseHidden { _base :: a , ... -- additional extension info } instance Extend BaseHidden where fromBase b = BaseHidden b ... -- additional extension initialization I can define a parameterized data class of which the parameter is the type of the Base class as follows: data BaseExpose a = BaseExpose { _base :: a , ... -- additional extension info } With this parameterized data class, I can make the following fromBase' function fromBase' :: Base a => a -> BaseExpose a fromBase' a = BaseExpose a ... -- additional extension initialization My question is can I make BaseExpose an instance of Extend? I am aware that the signature of fromBase states that for all 'b' of Base an Extend of type 'a' must be able to be made. Yet, in my case 'a' is a parameterized class 'BaseExpose x' and since the type of Extend is provided (it is a constructor) I think it is acceptable that 'BaseExpose b' is returned as type. I have looked at some extensions, such as InstanceSigs, yet I found no solution. Does anybody on this mailing list have an answer or solution for me? Also experience in a large project related to maintenance for the two alternatives (hiding or exposing types) is appreciated! Thanks in advance, Pierre van de Laar ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

3 2

Source code comprehension - Looking for ideas
by Németh Boldizsár 14 Feb '19

14 Feb '19

Dear Haskellers, I'm involved in extending the CodeCompass (https://github.com/Ericsson/CodeCompass) source code comprehension tool with a Haskell plugin. I'm looking for ideas on views or searches (both graphical and textual) that can help programmers to understand complex Haskell programs (using compile-time information). The basic examples that I will implement is finding the definition of a name and finding usages of a name. I'm also interested in similar tools or libraries if there is any. BR, Boldizsár

2 1

Call for Submissions: ICFP Student Research Competition
by Sam Tobin-Hochstadt 14 Feb '19

14 Feb '19

ICFP 2019 Student Research Competition Call for Submissions ICFP invites students to participate in the Student Research Competition in order to present their research and get feedback from prominent members of the programming language research community. Please submit your extended abstracts through the submission website. ### Important dates Submissions due: 14 Jun 2019 (Friday) https://icfp19src.hotcrp.com Notification: 28 Jun 2019 (Friday) Conference: 18 August (Sunday) - 23 August (Friday) Each submission (referred to as "abstract" below) should include the student author’s name and e-mail address; institutional affiliation; research advisor’s name; ACM student member number; category (undergraduate or graduate); research title; and an extended abstract addressing the following: * Problem and Motivation: Clearly state the problem being addressed and explain the reasons for seeking a solution to this problem. * Background and Related Work: Describe the specialized (but pertinent) background necessary to appreciate the work in the context of ICFP areas of interest. Include references to the literature where appropriate, and briefly explain where your work departs from that done by others. * Approach and Uniqueness: Describe your approach in addressing the problem and clearly state how your approach is novel. * Results and Contributions: Clearly show how the results of your work contribute to programming language design and implementation in particular and to computer science in general; explain the significance of those results. * Submissions must be original research that is not already published at ICFP or another conference or journal. One of the goals of the SRC is to give students feedback on ongoing, unpublished work. Furthermore, the abstract must be authored solely by the student. If the work is collaborative with others and*or part of a larger group project, the abstract should make clear what the student’s role was and should focus on that portion of the work. * Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from https://www.acm.org/publications/authors/submissions. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from http://sigplan.org/Resources/Author/#acmart-format. The submission must not exceed 3 pages in PDF format. Reference lists do not count towards the 3-page limit. Further information is available at the ICFP SRC website: https://icfp19.sigplan.org/track/icfp-2019-Student-Research-Competition ICFP Student Research Competition Chair: William J. Bowman (University of British Columbia)

1 0