- Haskell-Cafe - Haskell.org

Final Call for Talks -- Haskell Implementors' Workshop
by Joachim Breitner 17 Jul '18

17 Jul '18

Call for Contributions ACM SIGPLAN Haskell Implementors’ Workshop https://icfp18.sigplan.org/track/hiw-2018-papers Co-located with ICFP 2018 St. Louis, Missouri, US https://conf.researchr.org/home/icfp-2018 Important dates --------------- Proposal Deadline: Friday, 20 July, 2018 Notification: Friday, 3 August, 2018 Workshop: Sunday, 23 September, 2018 Keynote speaker --------------- This year, the Haskell Implementors’ Workshop is proud to present Rahul Muttineni as the keynote speaker. Rahul brough the joys of Haskell to the realm of Java by creating the Eta programming language. Title: Let's Go Mainstream with Eta! Eta is a fork of GHC that focuses on three core principles: user experience, performance, and safety. We'll discuss how we used these principles to guide the re-implementation of the GHC runtime and code generator on the JVM. Moreover, will also cover the inner workings of the FFI and the typechecker support we added for subtyping to make it smooth to interact with Java libraries. Finally, we'll round out with a look at where Eta is headed and how Eta and GHC can collaborate in the future. About the Haskell Implementors’ Workshop ---------------------------------------- The 10th Haskell Implementors’ Workshop is to be held alongside ICFP 2018 this year in St. Louis. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience ------------------------- It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2018. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw18.hotcrp.com/ until July 20th (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Edwin Brady (University of St. Andrews, UK) * Joachim Breitner – chair (University of Pennsylvania) * Ben Gamari (Well-Typed LLP) * Michael Hanus (Kiel University) * Roman Leshchinsky (Facebook) * Niki Vazou (University of Maryland) Contact ------- * Joachim Breitner <joachim(a)cis.upenn.edu> -- Joachim Breitner Post-Doctoral researcher http://cis.upenn.edu/~joachim

1 0

Deadline Extension: Workshop in OCL and Textual Modeling (OCL 2018)
by Achim D. Brucker 17 Jul '18

17 Jul '18

(Apologies for duplicates) ********************************************************** ** Deadline Extension: new deadline 24th of July 2018 * ********************************************************** CALL FOR PAPERS 18th International Workshop on OCL and Textual Modeling Co-located with MODELS 2018: ACM/IEEE 21th International Conference on Model Driven Engineering Languages and System, October 14, 2018, Copenhagen, Denmark http://oclworkshop.github.io Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but they have weaknesses: for example, detailed visual representations bear the risk of becoming overcrowded faster than textual models and some of the visual features lack the level of precision required to create complete and unambiguous specifications. These weaknesses of graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual modeling languages have their roots in formal language paradigms like logic, programming and databases. The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. ## Topics of interest Topics of interest include (but are not limited to): - Mappings between textual modeling languages and other languages/formalisms - Mathematical models and/or formal semantics for textual modeling languages - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for: - validation, verification, and testing, - model transformation and code generation, - meta-modeling and DSLs, and - query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Model-driven security using textual modeling languages - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports: - usage of textual modeling languages and tools in complex domains, - usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks We particularly encourage submissions describing applications and case studies of textual modeling as well as test suites and benchmark collections for evaluating textual modeling tools. ## Venue This workshop will be organized as a part of MODELS 2018 Conference in Copenhagen, Denmark. Similar to its predecessors, the workshop addresses both people from academia and industry. The aim is to provide a forum for addressing integration of OCL and other textual modeling languages, as well as tools for textual modeling, and for disseminating good practice and discussing the new requirements for textual modeling. ## Workshop Format The workshop will include short (about 15 min) presentations, parallel sessions of working groups, and sum-up discussions. ## Submissions Two types of papers will be considered: * Short contributions (between 5 and 7 pages) describing new ideas, innovative tools or position papers. * Full papers (between 10 and 14 pages). in LNCS format. Submissions should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2018). The program committee will review the submissions (minimum 2 reviews per paper, usually 3 reviews) and select papers according to their relevance and interest for discussions that will take place at the workshop. Accepted papers will be published online, as part of the MODELS workshop proceedings, in [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: July 24, 2018 (extended) - Notification: August 17, 2018 - Workshop date: October 14, 2018 -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

DSLDI 2018: First Call for Talk Proposals
by Sam Tobin-Hochstadt 17 Jul '18

17 Jul '18

********************************************************************* FIRST CALL FOR TALK PROPOSALS DSLDI 2018 Sixth Workshop on Domain-Specific Language Design and Implementation November 6th, 2018 Boston, USA Co-located with SPLASH http://2018.splashcon.org/track/dsldi-2018-talks https://twitter.com/wsdsldi ********************************************************************* Deadline for talk proposals: 17th of August, 2018 Well-designed and implemented domain-specific languages (DSLs) can achieve both usability and performance benefits over general-purpose programming languages. By raising the level of abstraction and exploiting domain knowledge, DSLs can make programming more accessible, increase programmer productivity, and support domain-specific optimizations. ## Workshop Goal Domain-Specific Language Design and Implementation (DSLDI) is a workshop intended to bring together researchers and practitioners interested in discussing how DSLs should be designed, implemented, supported by tools, and applied in realistic contexts. The focus of the workshop is on all aspects of this process, from soliciting domain knowledge from experts, through the design and implementation of the language, to evaluating whether and how a DSL is successful. More generally, we are interested in continuing to build a community that can drive forward the development of modern DSLs. ## Workshop Format DSLDI is a single-day workshop and will consist of an invited speaker followed by moderated audience discussions structured around a series of short talks. The role of the talks is to facilitate interesting and substantive discussion. Therefore, we welcome and encourage talks that express strong opinions, describe open problems, propose new research directions, and report on early research in progress. Proposed talks should be on topics within DSLDI’s area of interest, which include but are not limited to: * solicitation and representation of domain knowledge * DSL design principles and processes * DSL implementation techniques and language workbenches * domain-specific optimizations * human factors of DSLs * tool support for DSL users * community and educational support for DSL users * applications of DSLs to existing and emerging domains * studies of usability, performance, or other benefits of DSLs * experience reports of DSLs deployed in practice ## Call for Talk Proposals We solicit talk proposals in the form of short abstracts (max. 2 pages). A good talk proposal describes an interesting position, open problem, demonstration, or early achievement. The submissions will be reviewed on relevance and clarity, and used to plan the mostly interactive sessions of the workshop day. Publication of accepted abstracts and slides on the website is voluntary. * Deadline for talk proposals: August 17th, 2018 * Notification: September 17th, 2018 * Workshop: November 6th, 2018 * Submission website: https://dsldi18.hotcrp.com/ ## Workshop Organization Co-chairs: * Sam Tobin-Hochstadt (samth(a)indiana.edu) Indiana University * Lindsey Kuper (lindsey(a)composition.al) University of California, Santa Cruz Follow us on Twitter at https://twitter.com/wsdsldi Program committee: * Eric Van Wyk (University of Minnesota) * Katherine Ye (Carnegie Mellon University) * Nate Foster (Cornell University) * Spencer Florence (Northwestern University) * Phitchaya Mangpo Phothilimthana (University of California, Berkeley) * Jeremy Gibbons (University of Oxford) * Edwin Brady (University of St. Andrews)

1 0

BlockedIndefinitelyOnMVar
by Massimo Zaniboni 16 Jul '18

16 Jul '18

Hi, I have a code like this ``` producer :: Int -> MVar Int -> IO () producer c mvar = case c > 10 of True -> throwIO HighNumberException False -> do putMVar mvar (c + 1) producer (c + 1) mvar consumer :: MVar Int -> IO () consumer mvar = do _ <- takeMVar mvar consumer mvar coordinator :: MVar Int -> IO () coordinator mvar = do withAsync (producer 0 mvar) $ \p -> withAsync (consumer mvar) $ \c -> do wait c wait p main :: IO () main = do mvar <- newEmptyMVar withAsync (coordinator mvar) (wait) putStrLn "done" ``` The producer send the informative exception HighNumberException, but the coordinator job receives a generic BlockedIndefinitelyOnMVar, because the producer stop working. How can I discard the generic exception, and re-throw/catch only HighNumberException? In case the complete source code is on https://github.com/massimo-zaniboni/blocked-on-mvar Thanks in any case, Massimo

1 2

Package takeover: bencoding
by Sergey Vinokurov 16 Jul '18

16 Jul '18

I'd like to take over maintainership of the bencoding package [1]. The package was not updated to work with ghc 8.0 and will likely require more fixes to work with ghc 8.4 and some work to make a Stackage release. There's a PR open for GHC 8.0, but it's still open for a year and a half [2]. I've tried to ask the author in the PR thread to make me a maintainer in January but it still hasn't happened. Cheers, Sergey [1]: http://hackage.haskell.org/package/bencoding [2]: https://github.com/pxqr/bencoding/pull/7

1 0

[ANNOUNCE] GHC 8.6.1-alpha2 available
by Ben Gamari 16 Jul '18

16 Jul '18

The GHC development team is pleased to announce the second alpha release leading up to GHC 8.6.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-alpha2 This alpha fixes many of the bugs reported in the first alpha and brings many of the core libraries to their (hopefully) final release versions. Unfortunately, the documentation troubles affecting the first alpha haven't quite been resolved in this release. Consequently you will again find there is no documentation uploaded. However, let us know if anything else is amiss. Thanks for your help! Cheers, - Ben

1 0

Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?
by Vilem-Benjamin Liepelt 15 Jul '18

15 Jul '18

Dear MarLinn, > Of course you need all that data because there's a ghc in that data, but > it should say so on the tin. So please never send a script with this > line to a "newbie" without big warnings so they can make an informed > decision. That is a very good point. I just happen to use some particular LTS because I have it cached, so it works instantly for all my scripts. Thank you for reminding me that I shouldn't carelessly just pass this on for others to use without mentioning the caveats you pointed to. > Also, while I do like the scripting possibilities, interact is possibly > the worst way to introduce a newcomer to it because you can't really > test it in ghci. Your concern about testability in GHCi is valid but minor; you can just make the string transformation function a top-level declaration like so: ``` main = interact sumCLI sumCLI :: String -> String sumCLI = show @Double . sum . mapMaybe readMaybe . words ``` IMO `interact` is the easiest way for newcomers to write a script that they can actually use, hence why I opted for this instead of `print . sumCLi =<< getContents`. Lastly, SPJ asked for our "aha" moments—this was mine. He always does a good job at serving information in a way that is digestible for the audience, so you need not worry that any lambs will be led astray. Best, Vilem > On 2018-07-14, at 13:00, <haskell-cafe-request(a)haskell.org> <haskell-cafe-request(a)haskell.org> wrote: > > [...] > > Message: 4 > Date: Sat, 14 Jul 2018 13:33:31 +0200 > From: MarLinn <monkleyon(a)gmail.com> > To: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] What is your favourite Haskell "aha" > moment? > Message-ID: <c7a00886-f32b-c4ae-617d-450394278b58(a)gmail.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Warning: I'll be overly harsh in this mail because I assume some people > that are new to Haskell might browse this thread now and in the future. > I don't mean my comments to be considered personal. On the contrary, I > think some of us can learn for their own teaching endeavours. > >> #!/usr/bin/env stack >> -- stack script --resolver lts-10.1 --install-ghc > > Imagine a "newbie" running this script just to see what it does. After > 15 minutes they'll be disappointed why your small demo took so long to > build. Only /then/ do they realize that, what is it today, about half a > gigabyte maybe, of their monthly "high speed" bandwidth and of their > precious space on the cheap but decade-old hard drive is gone. > > Of course you need all that data because there's a ghc in that data, but > it should say so on the tin. So please never send a script with this > line to a "newbie" without big warnings so they can make an informed > decision. Maybe they would want to install ghc at their uni to save on > that precious bandwidth at home or something similar. > > In fact don't even send scripts with this line to seasoned haskellers. > If your code is compatible with the ghc 8.2.1 on my system, why should > your script assume I want stack to install 8.2.2 right now? > > Of course this behaviour is ingrained in the DNA of stack – after all it > values convenience for the professional user more than convenience for > the unprivileged newcomer – but AFAIU it /can/ be persuaded to be more > inclusive. So especially here, we should maybe try to do that. > >> interact >> ( show @Double >> . sum >> . mapMaybe readMaybe >> . words >> ) > > Also, while I do like the scripting possibilities, interact is possibly > the worst way to introduce a newcomer to it because you can't really > test it in ghci. Apart from all the other shortcomings it has. It is > nice in that it hides IO, but… > > Again, not meant as an attack, but since we're talking about giving > newcomers a good experience, I thought these two points important. > > Cheers, > MarLinn >

1 0

[ANNOUNCE] GHC 8.4.3 released
by Ben Gamari 15 Jul '18

15 Jul '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.3. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.3 This release includes a few bug fixes including: * A code generation bug resulting in crashing of some programs using UnboxedSums has been fixed (#15038). * #14381, where Cabal and GHC would disagree about abi-depends, resulting in build failures, has been worked around. Note that the work-around patch has already been shipped by several distributions in previous releases, so this change may not be visible to you. * By popular demand, GHC now logs a message when it reads a package environment file, hopefully eliminating some of the confusion wrought by this feature. * GHC now emits assembler agreeable to newer versions of Gnu binutils, fixing #15068. * SmallArray#s can now be compacted into a compact region Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/TeamGHC Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Many GHC developers hang out on #haskell on IRC: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug

5 11

Package takeover: bencoding
by Sergey Vinokurov 15 Jul '18

15 Jul '18

I'd like to take over maintainership of the bencoding package [1]. The package was not updated to work with ghc 8.0 and will likely require more fixes to work with ghc 8.4 and some work to make a Stackage release. There's a PR open for GHC 8.0, but it's still open for a year and a half [2]. I've tried to ask the author in the PR thread to make me a maintainer in January but it still hasn't happened. Cheers, Sergey [1]: http://hackage.haskell.org/package/bencoding [2]: https://github.com/pxqr/bencoding/pull/7

1 0

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 15 Jul '18

15 Jul '18

Dear Haskell community, the GHC Steering committee is seeking nominations for a new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until July 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0