April 2020 - Haskell-Cafe

Targeting old Windows versions
by Andreas Klebinger 08 Apr '20

08 Apr '20

Hello devs, GHC is planning to use the Large Address Space mode of allocation for future releases on windows. See https://gitlab.haskell.org/ghc/ghc/issues/12576 This is a significant optimization for the GC and well tested as we use it on Linux already. However it will regress memory useage on versions of windows *older* than Windows 8.1/Sever 2012. Please let us know if you are targeting older versions than that either by responding to the mailing list, commenting on the ticket or contacting me directly if you have privacy concerns. Depending on how many people are affected by this change we might consider measures to reduce the impact. Cheers, Andreas

1 0

Uppercase OverloadedLabels
by Alejandro Serrano Mena 07 Apr '20

07 Apr '20

Dear Haskell-Café / GHC devs, Is there any reason why the `OverloadedHaskell` extension does not work with labels starting with an uppercase letter? Kind regards, Alejandro

2 1

New stack.yaml.lock file to master source repo?
by David Banas 06 Apr '20

06 Apr '20

What’s the general consensus on whether or not the new stack.yaml.lock file should be stored in the master source repo.? Thanks, -db

2 1

Looking for a library for DerivingVia idioms
by Jack Kelly 06 Apr '20

06 Apr '20

Hello Cafe, Here is a problem a friend (CC'd - please include him in replies) and I wanted to solve using DerivingVia. We have a solution (below). I'm wondering whether a library for these newtypes exists, and if not, whether it should. This email is Literate Haskell. The problem: given two types `Foo` and `Bar`, and an injection `foo2bar :: Foo -> Bar`, use DerivingVia to derive instances for `Foo` in terms of `Bar`. > {-# LANGUAGE DerivingVia, MultiParamTypeClasses #-} > {-# LANGUAGE ScopedTypeVariables, TypeOperators #-} > > import Data.Function (on) > import Data.Coerce (coerce) > > data Foo = Foo deriving Eq via (Foo `InjectedInto` Bar) > data Bar = Bar deriving Eq > > foo2bar :: Foo -> Bar > foo2bar Foo = Bar Section 4.3 of the DerivingVia paper[1] shows how to use a newtype wrapper to derive instances for one type in terms of another, so long as their generic representation is the same. We can use the same technique. We need a newtype that's representationally equal to `a`, to pass to DerivingVia: > newtype InjectedInto a b = InjectedInto a We also need a class, so that we can find our injection given the type: > class Injective a b where > -- Law: to x = to y => x = y > to :: a -> b > > instance Injective Foo Bar where > to = foo2bar We need an instance that uses the InjectedInto newtype: > instance (Eq b, Injective a b) => Eq (a `InjectedInto` b) where > (==) = (==) `on` (to :: a -> b) . coerce The `deriving Eq via (Foo `InjectedInto` Bar)` above compiled successfully, so everything seems to work well. I'm wondering: 1. Is a library collecting useful DerivingVia wrappers? 2. If not, suppose I wanted to stand up such a library. Is there a canonical library providing classes like `Injection`? I found the `type-iso` package, which provides an `Injective` typeclass[2], but it has few revdeps and a dubious instance Default a => Injective (Maybe b) (Either a b). 3. What about DerivingVia for types not of kind `Type`? It might be possible to repeat this structure one level up for `Eq1` &c. Is it worth supporting `Eq1` etc in a world with QuantifiedConstraints? 4. Is there a better name than `InjectedInto`? It doesn't scan well. A type operator, perhaps? Thanks for reading. I look foward to your responses. -- Jack [1]: https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf [2]: https://hackage.haskell.org/package/type-iso-1.0.1.0/docs/Data-Types-Inject…

2 1

Two PhD positions in Utrecht
by Wouter Swierstra 06 Apr '20

06 Apr '20

============================================================== Two PhD positions in functional programming ============================================================== The Department of Information and Computing Sciences at Utrecht University is currently advertising two PhD positions in Functional Programming. The candidates will join the Intelligent Systems group, working with Johan Jeuring, Gabriele Keller, and Wouter Swierstra. Besides research, the successful candidate will be expected to help supervise MSc students and assist in the teaching of courses. The positions should be filled by September 2020, although the exact starting date is negotiable. --------------------------------- Research topics --------------------------------- These two positions are tied to two specific topics. * Programming tutors for Functional Languages (Johan Jeuring) The focus of the position is on designing new technologies to support students working in an intelligent tutoring system for functional programming. We expect to use techniques from dependently typed programming, refinement types, program synthesis, automated theorem proving, and more to analyse student programs, and to help students in taking the next step when developing a program. The candidate will investigate the design and use of multiple technologies for this purpose, add them to Ask-Elle, our intelligent tutoring system, perform experiments with the system, and improve the technologies based on the outcome of the experiments. * Compiler verification for a smart contract language (Wouter Swierstra & Gabriele Keller) This project aims to develop a certifying compiler for Plutus Tx, a subset of the purely functional language Haskell that is used to implement smart contracts for the Cardano blockchain. The Plutus smart contract framework is being developed by IOHK for Cardano and the present project is a joint effort of IOHK and Utrecht University. The Plutus Tx compiler is based on the GHC Haskell compiler and adds a translation step from GHC Core to a minimal lambda calculus. Programs in this lambda calculus are executed during transaction validation in a sandboxed execution environment in a manner that is crucial to the security of the blockchain. This project aims to formalise the semantics of the languages involved, to reason about the transformation and optimisation steps that the compiler performs, and finally, to generate a proof object certifying the correctness of the generated code together with that code. --------------------------------- What we are looking for --------------------------------- The ideal candidates should have a degree in Computer Science, be highly motivated, speak and write English well, and be proficient in producing scientific reports. Furthermore, candidates should be able to demonstrate experience with functional programming languages, such as Haskell, OCaml, ML, Agda, Idris, or Coq. --------------------------------- What we offer --------------------------------- The candidates are offered a full-time position for four or five years, depending on the teaching load. The gross salary ranges between €2,325 in the first year and €2,972 in the fourth year per month for full-time employment. A part-time position of at least 0.8 fte may also be possible. The salary is supplemented with a holiday bonus of 8% and an end-of-year bonus of 8.3% per year. The position also includes a generous allocation of fully-paid vacation days. In addition we offer: a pension scheme, partially paid parental leave, and flexible employment conditions. Conditions are based on the Collective Labour Agreement Dutch Universities. The research group will provide the candidate with necessary support on all aspects of the project. More information is available on the website: Terms and employment: http://bit.ly/1elqpM7 Utrecht is consistently ranked as one of the best places in the world to live. --------------------------------- How to apply --------------------------------- To apply please attach a letter of motivation, a curriculum vitae, and (email) addresses of two referees. Make sure to also include a transcript of the courses you have followed (at bachelor and master level), with the grades you obtained, and to include a sample of your scientific writing, such as your MSc or BSc thesis. It is possible to apply for this position if you are close to obtaining your undergraduate degree. In that case include a letter of your supervisor with an estimate of your progress, and do not forget to include at least a sample of your technical writing skills. The application deadline for the first position closes on April 29th. You can apply through the University's website: https://www.uu.nl/en/organisation/working-at-utrecht-university/jobs/5-year… The application for the second position is not yet open -- but feel free to contact me directly if you're interested. If you're still unsure about the topic, feel free to apply using the link above; we're happy to discuss which topic fits your interests best during the application process.

1 0

Call for participation: Utrecht AFP Summer School
by Wouter Swierstra 06 Apr '20

06 Apr '20

SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING Utrecht, the Netherlands, 06-10 July 2020 http://www.afp.school # Call for Participation ## About The Advanced Functional Programming summer school has been running for more than ten years. We aim to educate aspiring Haskell programmers beyond the basic material covered by many textbooks. We have decided to advertise the Summer School and accept new registrations for the moment, but we are monitoring the situation with COVID-19 carefully. All the Utrecht Summer Schools offer participants a full refund of their registration fee if they decide to cancel their registration. The lectures will cover several more advanced topics regarding the theory and practice of Haskell programming, including topics such as: * lambda calculus; * monads and monad transformers; * lazy evaluation; * generalized algebraic data types; * type families and type-level programming; * concurrency and parallelism. The summer school consists of a mix of lectures, labs, and a busy social program. ## Lecturers Utrecht staff: * Gabriele Keller * Trevor McDonell * Wouter Swierstra ## Prerequisites We expect students to have a basic familiarity with Haskell already. You should be able to write recursive functions over algebraic data types, such as lists and trees. There is a great deal of material readily available that covers this material. If you've already started learning Haskell and are looking to take your functional programming skills to the next level, this is the course for you. Soft registration deadline: 1 July, 2020 School: 06-10 July, 2020 ## Costs 1700 euro - Housing and registration 1500 euro - Registration only We offer a 1000 discount for students and staff members affiliated with a university or other non-profit organization. ## Scholarships If you're struggling to finance your trip to Utrecht, please let us know. We have a very limited number of scholarships or discounts available for students that would not be able to attend otherwise, especially for women and under-represented minorities. ## Further information Further information, including instructions on how to register, is available on our website: http://www.afp.school

1 0

Efficiency of passing function arguments
by KS 04 Apr '20

04 Apr '20

Hello everyone, I was coming from a C++ background and I always wondered if there is a distinction between pass-by-value and pass-by-reference in Haskell (or pass-by-thunk? since an argument might be partially evaluated due to laziness in Haskell). Is there a way to guarantee that an function argument is passed in an efficient manner? For example, if we have a data type data Document = Document { title :: Text , author :: Name , content :: Text -- and potentially many more } doc = Document {..} -- omitted and we want to pass doc to a function, we should ideally hope that doc is not getting duplicated when passing it as an argument. Another example might be the Reader monad, where we are passing possibly the same environment to multiple functions. In C++, we could either pass by a pointer or a reference, but I'm not sure what the best practices are in Haskell. The most relevant construct in Haskell seems to be IORef, though I'm not sure if this is the correct way to use it. For exmaple, if I want to pre-load a template document on disk as Text or ByteString into the memory when the program starts, should I put it in a IORef and pass it into (more than one) functions or should I pass it into the function directly? Should I worry about this at all? This question might be related to the implementation of the ghc compiler. It would be better if anyone could shed some lights on the implementation details. Thank you, Kram

5 5

How to safely and fast write repa array to a file?
by cyberfined 04 Apr '20

04 Apr '20

Hello, all. I decide to write parallel ray tracer on haskell with repa. Now, to save repa array to file I use dirty trick casting repa array ptr to bytestring with fromForeignPtr and then writing it to file with hPut. It looks something like that: import qualified Data.Array.Repa as R import qualified Data.Array.Repa.Repr.ForeignPtr as RF import qualified Data.ByteString as B import qualified Data.ByteString.Char8 as BC import qualified Data.ByteString.Internal as BI type Image = Array F DIM2 Pixel writeImage :: FilePath -> Image -> IO () writeImage path img = bracket (openFile path WriteMode) (hClose) $ \hdl -> B.hPut hdl header >> B.hPut hdl body where Z :. h :. w = R.extent img header = BC.pack $ "P6\n" ++ show w ++ ' ':show h ++ "\n255\n" body = BI.fromForeignPtr(castForeignPtr $ RF.toForeignPtr img) 0 (w*h*3) My question is: how to write repa array to file safely and fast?

3 2

ML Family Workshop 2020: Call for presentations
by Leo White 04 Apr '20

04 Apr '20

We are happy to invite submissions to the ML Family Workshop 2020, to be held during the ICFP conference week on Thursday, August 27th. The ML family workshop warmly welcomes submission touching on the programming languages traditionally seen as part of the "ML family" (Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml, etc.). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to exchange experience of further developing ML ideas. Currently, the workshop is still scheduled to go ahead as planned in Jersey City, however it is likely that the ML workshop will end up being a virtual workshop this year. Either way provisions will be made to allow speakers to present their work remotely. See our detailed CFP online on the ICFP website: https://icfp20.sigplan.org/home/mlfamilyworkshop-2020 Important dates --------------- - Friday 15th May (any time zone): Abstract submission deadline - Friday 26th June: Author notification - Thursday 27th August: ML Family Workshop Program committee ----------------- - Youyou Cong (Tokyo Institute of Technology) - Gowtham Kaki (Purdue University) - Neel Krishnaswami (University of Cambridge) - Daan Leijen (Microsoft Research) - Koko Muroya (Kyoto University) - Atsushi Ohori (Tohoku University) - Jonathan Protzenko (Microsoft Research) - Gabriel Radanne (INRIA) - Claudio Russo (Dfinity) - Leo White (Jane Street) (Chair) - Jeremy Yallop (University of Cambridge) Submission details ------------------ See the online CFP for the details on the expected submission format. Submissions must be uploaded to the workshop submission website https://ml2020.hotcrp.com/ before the submission deadline.

1 0

ANN: stack-2.3.0.1 release candidate
by Emanuel Borsboom 02 Apr '20

02 Apr '20

### First release candidate for v2.3 **Changes since v2.1.3** Release notes: Major changes: * `setup-info-locations` yaml configuration now allows overwriting the default locations of `stack-setup-2.yaml`. [#5031](https://github.com/commercialhaskell/stack/pull/5031) [#2983](https://github.com/commercialhaskell/stack/issues/2983) [#2913](https://github.com/commercialhaskell/stack/issues/2913) * The `setup-info` configuration key now allows overwriting parts of the default `setup-info` * The `--setup-info-yaml` command line flag now may be used in all stack commands such as `stack build`, and not only in `stack setup` * The `--setup-info-yaml` may specify multiple locations for `stack-setup.yaml` files. * The `stack upload` can read first reads environment Variable `$HACKAGE_USERNAME` and `$HACKAGE_PASSWORD` if they are missing only then asks for `username` or `password` * Fully remove GHCJS support. * Remove the `freeze` command. It has been replaced by lock files. Behavior changes: * Remove the deprecated `--stack-setup-yaml` command line argument in favor of `--setup-info-yaml` [#2647](https://github.com/commercialhaskell/stack/issues/2647) * We now recommend checking in generated cabal files for repos. When generating lock files for extra-deps that only include `package.yaml` files, a deprecation warning will be generated. Also, those packages will no longer be included in the generated lock files. See [#5210](https://github.com/commercialhaskell/stack/issues/5210). Other enhancements: * Add `build-output-timestamps` flag in yaml. Setting it to true prefixes each build log output line with a timestamp. * Show warning about `local-programs-path` with spaces on windows when running scripts. See [#5013](https://github.com/commercialhaskell/stack/pull/5013) * Add `ls dependencies json` which will print dependencies as JSON. `ls dependencies --tree` is now `ls dependencies tree`. See [#4424](https://github.com/commercialhaskell/stack/pull/4424) * Remove warning for using Stack with GHC 8.8 and Cabal 3.0. * Allow relative paths in `--setup-info-yaml` and tool paths [#3394](https://github.com/commercialhaskell/stack/issues/3394) Bug fixes: * Upgrade `pantry`: module mapping insertions into the database are now atomic. Previously, if you SIGTERMed at the wrong time while running a script, you could end up with an inconsistent database state. * `--resolver global` doesn't retrieve snapshots list from the internet beause doesn't need it. See [#5103](https://github.com/commercialhaskell/stack/issues/5103) * Fix using relative links in haddocks output. See [#4971](https://github.com/commercialhaskell/stack/issues/4971). * Do not include generated cabal file information in lock files. See [#5045](https://github.com/commercialhaskell/stack/issues/5045). * Use proper Hoogle executable path when installed automatically. See [#4905](https://github.com/commercialhaskell/stack/issues/4905) * Fix GHC version for batched package unregistration. See [#4951](https://github.com/commercialhaskell/stack/issues/4951) * Use Hoogle from the snapshot used and not the latest version. See [#4905](https://github.com/commercialhaskell/stack/issues/4905) * Resolve "'stty' is not recognized". See [#4901](https://github.com/commercialhaskell/stack/issues/4901) * Fix missing reconfigure check causing errors when a package gets used in multiple projects. See [#5147](https://github.com/commercialhaskell/stack/issues/5147)

1 1