July 2018 - Haskell-Cafe

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

14 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 14 Jul '18

14 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 14 Jul '18

14 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

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

14 Jul '18

Dear Simon, I was always impressed by Haskell, but my "aha" moment was when I realised how great it is as a scripting language. How cool is the fact that you can glue together a bunch of small programs and make a bigger program out of it without toil? Haskell helps you get mundane tasks done while being a pleasure to write (in relative terms)! There are much better examples online—I love Gabriel Gonzalez' turtle library—but I find the following compelling enough, and anybody can understand more or less what is going on with some explanation: #!/usr/bin/env stack -- stack script --resolver lts-10.1 --install-ghc {-# LANGUAGE TypeApplications #-} import Data.Maybe (mapMaybe) import Text.Read (readMaybe) main :: IO () main = interact ( show @Double . sum . mapMaybe readMaybe . words ) -- Adapted from a script by Taylor Fausak: https://gist.github.com/tfausak/fcd11dfcec616622033dfb64eb2378e1 Good luck with the presentation! Best, Vilem

3 2

Taking over unicode-show
by Yuji Yamamoto 14 Jul '18

14 Jul '18

Hello Haskellers, I'm trying to take over the unicode-show <http://hackage.haskell.org/package/unicode-show> package, whose author Takayuki Muranushi died about a year ago [1]. We Japanese (and perhaps non-alphabet writers) are often annoyed by the result of the show function, which converts various characters into non-human-readable strings. The unicode-show package solves the problem, and I'm going to introduce the package in an educational content I'm creating to help Japanese Haskell newbies. Thanks to the simple structure, there is nothing to maintain (unfortunately except hard one). It works even on GHC 8.4. [1]: (In Japanese) http://www.asj.or.jp/tennet/archives/msg07622.html -- 山本悠滋 twitter: @igrep GitHub: https://github.com/igrep GitLab: https://gitlab.com/igrep Facebook: http://www.facebook.com/igrep Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep

1 0

Lifetime control of webserver
by ☂Josh Chia (謝任中) 13 Jul '18

13 Jul '18

Hi, My application is not a webserver but needs to run a webserver for part but not all of its lifetime. Particularly, there's a part that does some complex computation and I want a webserver to expose its internal state/progress through HTTP. It seems that the typical and expected way to use a webserver is to designate the entire app itself as a webserver, so that functions like the following are basically infinite loops that serve HTTP: Web.Scotty.scotty: http://hackage.haskell.org/package/scotty-0.11.2/docs/Web-Scotty.html#v:sco… Network.Wai.Handler.Warp.run: http://hackage.haskell.org/package/warp-3.2.22/docs/Network-Wai-Handler-War… Can I run a webserver with explicit control of its lifetime? Particularly, I want to be able to kill it without killing the app or explicitly serve one request at a time. I'm not restricted to scotty or warp. Josh

3 4

Re: [Haskell-cafe] Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?)
by Paul 13 Jul '18

13 Jul '18

Wooow! Yes!! But today there is serious competition (Smalltalk, Python; I planned Scratch – but it’s for children of 7-9 years). I thing you are good teacher 😊 Btw, what do you think: what is better – textual programming or visual programming for children? For me, Labview/G was insight in 90s 😊 Today there is Luna language – it’s visual too. IMHO visual programming better illustrates ideas/concepts, or? From: Chris Smith Sent: 12 июля 2018 г. 21:00 To: aquagnu(a)gmail.com Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?) Perhaps you mean something fun and visual like this? https://code.world/#PhFFj32Bx0FcpQvvoVJW0xw Or this? https://code.world/#PO1BKCj-kA9ztKKnE7rOueA These are written in the simplified variant of Haskell that I teach, which uses a custom Prelude that skips type classes and other advanced features, uses rebindable syntax to simplify types (for example, you'll see Number instead of Int, Double, etc.), and automatically provides graphics functions that work in the browser. On Thu, Jul 12, 2018 at 1:54 PM Paul <aquagnu(a)gmail.com> wrote: Hmm, Chris, thanks for answer. Interesting. I was surprised when I first learned that someone somewhere is teaching the children to Haskell, but if you say so – then it’s possible and may be it’s good! 😊 Sometimes children don’t like right things, but like fun. So, I though that more preferable to show them some bright demo: UI, graphics, some simple games, databases, to rise the interest, you know – this feeling of first code. First “wooow! It works!!!” 😊 Haskell, for me, looks pedantic, not for fun. May be I’m not right, I have not such experience. From: Chris Smith Sent: 12 июля 2018 г. 19:59 To: aquagnu(a)gmail.com Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavourite Haskell "aha" moment?) I'll answer this, since I have been teaching Haskell to children for six years or so. :) I think it's important to distinguish between Haskell AS USED in most of the community, and Haskell as it COULD be used. I agree that you don't want to teach the first of those to children. But Haskell is still a great teaching choice, mainly because GHC is so configurable that you can create the environment you want, and just build it with a Haskell compiler. With GHC plugins, this is becoming even more true, but it already arises from a combination of (a) very lightweight and intuitive core syntax in the first place, (b) great support for custom preludes, and (c) the RebindableSyntax extension, and the fact that so much syntax is defined in terms of desugaring. If you're seriously talking about teaching children, then your concerns about web frameworks and such are a bit silly. (Unless by "children" you meant mid to late teens and after, in which case this becomes relevant.) "Advanced" type features are also not particularly relevant (though there's some fuzziness about what counts as "advanced"; for instance, I've recently decided it's better to teach GADT syntax as the only option for defining algebraic data types, even though I never expect most students to take advantage of the extra power of GADTs.) The main concern I have with F#, though, is that the semantics are far too complex. It has all the power of a functional language, but none of the semantic simplicity. If students already struggle with compositional programming (and they do), they struggle even more when the simplest way to understand what's going on -- namely, substitution -- is taken away from them. If you're going to teach a computational model based on sequencing actions on a global state (the state being the screen, network, etc.), then you might as well include mutable variables in that global state, and you might as well teach Python, which will at least be more intuitive, if not simpler. On Thu, Jul 12, 2018 at 7:46 AM PY <aquagnu(a)gmail.com> wrote: I am afraid that it can lead to flame again, but F# has super-capacity: you can check measuring units, type providers, computation expressions, active patterns, static/dynamic types constraints, constraints on existing method, etc... It's clean, borrows some ideas from Haskell, some are original and Haskell borrows them (but with worse implementation). IMHO for children teaching to FP F# is the best. Even more, currently C# also has a lot of FP features (https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arit… -- is not it super easy and beauty?). Rust is more low level: you should think about memory "management", OOP has some problems... And serious argument for children teaching: salary trends (joke sure) :-) But you can compare salary in F# and Haskell, for example - people often choice language after check current salaries in the market. Also F# is more focused on realistic tasks and business value. It lacks performance, UWP yet (but in progress)... To feel how F# is sexy compare Web application written in Websharper and in any Haskell framework. Haskell is beauty but I'm afraid its fate unfortunately will be the same as one of Common Lisp, NetBSD, etc - it's ground for ideas and experiments and has disputable design. Also it's more-more difficult to teach children to Haskell than to F#... IMHO is general to teach FP is more easy than to teach OOP if FP is not Haskell (some language which targets more eager/efficient/dynamic/real goals instead of abstract types playing). 12.07.2018 13:28, Vanessa McHale wrote: I wouldn't say Rust has a large capacity for FP. I am not familiar with F#. The thing that makes FP infeasible in Rust is not the lack of purity but rather the fact that affine types make it difficult to treat functions as first-class values. On 07/12/2018 01:40 AM, Brett Gilio wrote: Tony, I am curious on your attitude towards multi-paradigm and ML-like languages. I agree that functional programming is easily the better of the bundle in many forms of application logic and elegance (which is why I have come to love Scheme and Haskell), but do you see any room for those languages like F# or Rust which have large capacities for FP but are either functional-first (but not pure) or a hybrid? Brett Gilio On 07/12/2018 01:35 AM, Tony Morris wrote: I used to teach undergrad OOP nonsense. I have been teaching FP for 15 years. [^1] The latter is *way* easier. Existing programmers are more difficult than children, but still way easier to teach FP than all the other stuff. [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/ On 07/12/2018 04:23 PM, Joachim Durchholz wrote: Am 11.07.2018 um 16:36 schrieb Damian Nadales: I speak only from my own narrow perspective. I'd say programming is hard, but functional programming is harder. Actually it's pretty much the opposite, I hear from teachers. Maybe that's why Java replaced Haskell in some universities curricula The considerations are marketable skills. A considerable fraction of students is looking at the curriculum and at job offers, and if they find that the lists don't match, they will go to another university. Also, industry keeps lobbying for teaching skills that they can use. Industry can give money to universities so this gives them influence on the curriculum (and only if they get time to talk the topic over with the dean). This aspect can vary considerably between countries, depending on how much money the universities tend to acquire from industry. https://chrisdone.com/posts/dijkstra-haskell-java. For some reason most programmers I know are not scared of learning OO, but they fear functional programming. Programmers were *very* scared of OO in the nineties. It took roughly a decade or two (depending on where you put the starting point) to get comfortable with OO. I think the reason might be that OO concepts like inheritance and passing messages between objects are a bit more concrete and easier to grasp (when you present toy examples at least). OO is about how to deal with having to pack everything into its own class (and how to arrange stuff into classes). Functional is about how to deal with the inability to update. Here, the functional camp actually has the easier job, because you can just tell people to just write code that creates new data objects and get over with it. Performance concerns can be handwaved away by saying that the compiler is hyper-aggressive, and "you can look at the intermediate code if you suspect the compiler is the issue". (Functional is a bit similar to SQL here, but the SQL optimizers are much less competent than GHC at detecting optimization opportunities.) Then you have design patterns, which have intuitive names and give some very general guidelines that one can try after reading them (and add his/her own personal twist). I doubt people can read the Monad laws and make any sense out of them at the first try. That's true, but much of the misconceptions around monads from the first days have been cleared up. But yes the monad laws are too hard to read. OTOH you won't be able to read the Tree code in the JDK without the explanations either. _______________________________________________ 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. _______________________________________________ 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. _______________________________________________ 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. _______________________________________________ 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. _______________________________________________ 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.

5 4

Re: [Haskell-cafe] Investing in languages (Was: What is your favourite Haskell "aha" moment?)
by Chris Smith 12 Jul '18

12 Jul '18

Oops, readding the mailing list. On Thu, Jul 12, 2018 at 12:59 PM Chris Smith <cdsmith(a)gmail.com> wrote: > I'll answer this, since I have been teaching Haskell to children for six > years or so. :) > > I think it's important to distinguish between Haskell AS USED in most of > the community, and Haskell as it COULD be used. I agree that you don't > want to teach the first of those to children. But Haskell is still a great > teaching choice, mainly because GHC is so configurable that you can create > the environment you want, and just build it with a Haskell compiler. With > GHC plugins, this is becoming even more true, but it already arises from a > combination of (a) very lightweight and intuitive core syntax in the first > place, (b) great support for custom preludes, and (c) the RebindableSyntax > extension, and the fact that so much syntax is defined in terms of > desugaring. > > If you're seriously talking about teaching children, then your concerns > about web frameworks and such are a bit silly. (Unless by "children" you > meant mid to late teens and after, in which case this becomes relevant.) > "Advanced" type features are also not particularly relevant (though there's > some fuzziness about what counts as "advanced"; for instance, I've recently > decided it's better to teach GADT syntax as the only option for defining > algebraic data types, even though I never expect most students to take > advantage of the extra power of GADTs.) > > The main concern I have with F#, though, is that the semantics are far too > complex. It has all the power of a functional language, but none of the > semantic simplicity. If students already struggle with compositional > programming (and they do), they struggle even more when the simplest way to > understand what's going on -- namely, substitution -- is taken away from > them. If you're going to teach a computational model based on sequencing > actions on a global state (the state being the screen, network, etc.), then > you might as well include mutable variables in that global state, and you > might as well teach Python, which will at least be more intuitive, if not > simpler. > > On Thu, Jul 12, 2018 at 7:46 AM PY <aquagnu(a)gmail.com> wrote: > >> I am afraid that it can lead to flame again, but F# has super-capacity: >> you can check measuring units, type providers, computation expressions, >> active patterns, static/dynamic types constraints, constraints on existing >> method, etc... It's clean, borrows some ideas from Haskell, some are >> original and Haskell borrows them (but with worse implementation). IMHO for >> children teaching to FP F# is the best. Even more, currently C# also has a >> lot of FP features ( >> https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arit… >> -- is not it super easy and beauty?). Rust is more low level: you should >> think about memory "management", OOP has some problems... And serious >> argument for children teaching: salary trends (joke sure) :-) But you can >> compare salary in F# and Haskell, for example - people often choice >> language after check current salaries in the market. Also F# is more >> focused on realistic tasks and business value. It lacks performance, UWP >> yet (but in progress)... To feel how F# is sexy compare Web application >> written in Websharper and in any Haskell framework. Haskell is beauty but >> I'm afraid its fate unfortunately will be the same as one of Common Lisp, >> NetBSD, etc - it's ground for ideas and experiments and has disputable >> design. Also it's more-more difficult to teach children to Haskell than to >> F#... >> IMHO is general to teach FP is more easy than to teach OOP if FP is not >> Haskell (some language which targets more eager/efficient/dynamic/real >> goals instead of abstract types playing). >> >> 12.07.2018 13:28, Vanessa McHale wrote: >> >> I wouldn't say Rust has a large capacity for FP. I am not familiar with >> F#. The thing that makes FP infeasible in Rust is not the lack of purity >> but rather the fact that affine types make it difficult to treat >> functions as first-class values. >> >> >> On 07/12/2018 01:40 AM, Brett Gilio wrote: >> >> Tony, >> >> I am curious on your attitude towards multi-paradigm and ML-like >> languages. I agree that functional programming is easily the better of >> the bundle in many forms of application logic and elegance (which is >> why I have come to love Scheme and Haskell), but do you see any room >> for those languages like F# or Rust which have large capacities for FP >> but are either functional-first (but not pure) or a hybrid? >> >> Brett Gilio >> >> On 07/12/2018 01:35 AM, Tony Morris wrote: >> >> I used to teach undergrad OOP nonsense. I have been teaching FP for 15 >> years. [^1] >> >> The latter is *way* easier. Existing programmers are more difficult than >> children, but still way easier to teach FP than all the other stuff. >> >> [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/ >> >> >> On 07/12/2018 04:23 PM, Joachim Durchholz wrote: >> >> Am 11.07.2018 um 16:36 schrieb Damian Nadales: >> >> >> I speak only from my own narrow perspective. I'd say programming is >> hard, but functional programming is harder. >> >> >> Actually it's pretty much the opposite, I hear from teachers. >> >> >> Maybe that's why Java replaced Haskell in some universities >> curricula >> >> The considerations are marketable skills. >> A considerable fraction of students is looking at the curriculum and >> at job offers, and if they find that the lists don't match, they will >> go to another university. >> Also, industry keeps lobbying for teaching skills that they can use. >> Industry can give money to universities so this gives them influence >> on the curriculum (and only if they get time to talk the topic over >> with the dean). This aspect can vary considerably between countries, >> depending on how much money the universities tend to acquire from >> industry. >> >> >> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason >> most programmers I know are not scared of learning OO, but they fear >> functional programming. >> >> >> Programmers were *very* scared of OO in the nineties. It took roughly >> a decade or two (depending on where you put the starting point) to get >> comfortable with OO. >> >> >> I think the reason might be that OO concepts >> >> like inheritance and passing messages between objects are a bit more >> concrete and easier to grasp (when you present toy examples at least). >> >> >> OO is about how to deal with having to pack everything into its own >> class (and how to arrange stuff into classes). >> Functional is about how to deal with the inability to update. Here, >> the functional camp actually has the easier job, because you can just >> tell people to just write code that creates new data objects and get >> over with it. Performance concerns can be handwaved away by saying >> that the compiler is hyper-aggressive, and "you can look at the >> intermediate code if you suspect the compiler is the issue". >> (Functional is a bit similar to SQL here, but the SQL optimizers are >> much less competent than GHC at detecting optimization opportunities.) >> >> >> Then you have design patterns, which have intuitive names and give >> some very general guidelines that one can try after reading them (and >> add his/her own personal twist). I doubt people can read the Monad >> laws and make any sense out of them at the first try. >> >> >> That's true, but much of the misconceptions around monads from the >> first days have been cleared up. >> But yes the monad laws are too hard to read. OTOH you won't be able to >> read the Tree code in the JDK without the explanations either. >> _______________________________________________ >> 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. >> >> >> >> >> >> _______________________________________________ >> 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. >> >> >> _______________________________________________ >> 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. >> >> >> >> _______________________________________________ >> 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. >> >> >> _______________________________________________ >> 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

LAST CALL for draft papers for presentation at IFL 2018 (deadline this week)
by Jurriaan Hage 12 Jul '18

12 Jul '18

Hello, Please, find below the last call for draft papers for presentation for IFL 2018. 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 --- Call for Draft papers for presentations ============================================================ ==================== IFL 2018 30th Symposium on Implementation and Application of Functional Languages University of Massachusetts Lowell, MA, USA September 5th-7th, 2018 http://iflconference.org ============================================================ ==================== ### 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 2018 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 specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - 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 ### Keynote Speakers * Adam Chlipala, Massachusetts Institute of Technology CSAIL * Arjun Guha, University of Massachusetts Amherst ### Submissions and peer-review Differently from previous editions of IFL, IFL 2018 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2018. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal post-proceedings. 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. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication ### Important dates Submission of regular papers: May 25, 2018 [PASSED!] Submission of draft papers: July 17, 2018 [UPCOMING!] Regular and draft papers notification: July 20, 2018 Deadline for early registration: August 8, 2018 Submission of pre-proceedings version: August 29, 2018 IFL Symposium: September 5-7, 2018 Submission of papers for post-proceedings: November 7, 2018 Notification of acceptance: December 22, 2018 Camera-ready version: February 10, 2019 ### 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 Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2018 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored 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. ### Organization and Program committee Chairs: Jay McCarthy & Matteo Cimini, University of Massachusetts Lowell, USA Program Committee: * Arthur Chargueraud, Inria, FR * Ben Delaware, Purdue University, USA * Christos Dimoulas, Northwestern University, USA * David Darais, University of Vermont, USA * Dominic Orchard, University of Kent, UK * Ekaterina Komendantskaya, Heriot-Watt University, UK * Garrett Morris, University of Kansas, USA * Heather Miller, EPFL & Northeastern University, CH & USA * Jeremy Yallop, University of Cambridge, UK * Keiko Nakata, SAP Innovation Center Potsdam, DE * Laura Castro, University of A Coruna, ESP * Magnus Myreen, Chalmers University of Technology, SWE * Natalia Chechina, Bournemouth University, UK * Peter Achten, Radboud Universiteit Nijmegen, NL * Peter-Michael Osera, Grinnell College, USA * Richard Eisenberg, Bryn Mawr College, USA * Trevor McDonell, University of New South Wales, AUS * Yukiyoshi Kameyama, University of Tsukuba, JAP ### Venue The 30th IFL is organized by the University of Massachusetts Lowell. The City of Lowell is located at the heart of the Merrimack Valley just 30 miles northwest of Boston. Lowell can be easily reached by train or taxi. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2018 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences.

1 0

higher kind in parametric type
by Olaf Klinke 11 Jul '18

11 Jul '18

Dear cafe, I am writing a library for parsing higher-kinded data, based on the czipwith package [1]. I ran into the following problem. I have a type class class Config p f | f -> p where f :: (* -> *) -> * is the higher-kinded data and p :: * -> * is the associated parser type. I want to add a class member that does not mention f in its type, e.g. heading :: p String Naturally, this would lead to ambiguity checks to fail, as the usage of heading does not tell which Config instance to use. My usual workaround would be to wrap `heading` in a phantom type, e.g. data Heading f p = Heading (p String) and give `heading` the type Heading f p. However, ghc-8.0.2 complains about f not being a type: • Expecting one more argument to ‘f’ Expected a type, but ‘f’ has kind ‘(* -> *) -> *’ • In the first argument of ‘Heading’, namely ‘f’ In the type signature: heading :: Heading f p In the class declaration for ‘Config’ Is there a restriction of the kinds that can be used in parametric types? Cheers, Olaf [1] http://hackage.haskell.org/package/czipwith

4 4