- Haskell-Cafe - Haskell.org

Call for participation: FARM (early reg ends today)
by Mark Santolucito 04 Aug '17

04 Aug '17

5th ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Oxford, UK September 9, 2017 (co-located with ICFP 2017) http://functional-art.org/2017 The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. This year FARM presents paper and demo sessions during the day, as well as a performance in the evening. The evening performance feature computer music performances of artists integrating functional programming techniques into their work. To register for FARM, visit the ICFP registration page - early registration ends August 4. Some funding support is available for the main ICFP conference and related workshops like FARM. This information can be found on the travel support page. Registration ------------ You can register via the ICFP 2017 registration:http://icfp17.sigplan.org/attending/registration Early registration deadline is August 4. Program --------------- 9:00 - 9:10 Welcome Michael Sperber, Jean Bresson 09:10 - 10:00 A Categorial Grammar for Music and Its Use in Automatic Melody Generation Halley Young Demo - Representation of Musical Notation in Haskell Edward Lilley 10:30 - 11:30 Demo - The Arpeggigon: A Functional Reactive Musical Automaton Henrik Nilsson Demo - Vivid: Sound Synthesis with Haskell and SuperCollider Tom Murphy Demo - African Polyphony and Polyrhythm Chris Ford 12:00 - 12:30 Modelling the Way Mathematics Is Actually Done Joe Corneli, Ursula Martin, Dave Murray-Rust, Alison Pease, Raymond Puzio, Gabriela Rino Nesin 14:00 - 15:00 FAUST Tutorial for Functional Programmers Yann Orlarey, Stéphane Letz, Dominique Fober, Romain Michon 15:30 - 16:20 GALE: A Functional Graphic Adventure Library and Engine Ivan Perez Demo - Ait: A Concatenative Language for Creative Programming Stian Veum Mollersen 16:50 - 17:40 Unified Media Programming: An Algebraic Approach Simon Archipoff, David Janin Demo - Octopus: A High-Level Fast 3D Animation Language Simon Archipoff, David Janin Performances 19:30-22:00 @ Old Fire Station Workshop Organisation --------------------- - Workshop Chair: Mike Sperber, Active Group GmbH - Program Chair: Jean Bresson, UMR STMS IRCAM/CNRS/UPMC Sorbonne UniversitÃ©s - Publicity Chair: Mark Santolucito, Yale University - Performance Chair: Alex McLean, Deutsches Museum, Munich Program Committee: --------------------- - Renick Bell, Tama Art University, Tokyo - Beatrice Berard, LIP6, Universite Pierre et Marie Curie - Jean Bresson, UMR STMS IRCAM/CNRS/UPMC Sorbonne Universités - Richard Gabriel, IBM Research - Jean-Louis Giavitto, UMR STMS IRCAM/CNRS/UPMC Sorbonne Universités - Stéphane Letz, Grame - José Pedro Magalhães, Standard Chartered Bank - Ivan Perez Dominguez, University of Nottingham - Donya Quick, Southern Methodist University - Christophe Rhodes, Goldsmiths, University of London - Andrew Sorensen, Australian National University - Michael Sperber, Active Group GmbH - Charlotte Truchet, LINA, UMR 6241, Université de Nantes

1 0

[ANN] brittany - haskell source code formatting tool - hackage release
by lennart spitzner 04 Aug '17

04 Aug '17

Greetings, I am happy to (finally) announce the first hackage release of brittany, a configurable haskell source code formatter based on ghc-exactprint [2]. https://hackage.haskell.org/package/brittany https://github.com/lspitzner/brittany *Introduction* Brittany aims to nicely layout the code and retain empty lines and comments as they appear in the input. For that it uses a fundamentally different approach (see [7]/theory) than other formatters. The project is not finished, yet it already is usable and produces better results than other formatters in many cases. Of course these words come from its creator, so see for yourself: I have included some examples at the bottom of this mail; see [3] and [4] for some more. I wish to stress that this project will only progress at a very slow speed barring support from the community. I hereby offer to work on this and ask for funding. See the "future" paragraph below. *Changelog* Since the "alpha-release" announced previously [5] the most important changes are: - Release under the AGPL-v3; - Release on hackage; - Make horizontal alignment less aggressive by default (see example [6]); - Add high-level documentation (see [7]). This might be of interest to anyone considering to write a formatter (haskell or even otherwise); - Improve testsuite setup; - Improve layouting in many many cases and fix various bugs; - Add a library interface (this integrates with haskell-ide-engine [8]); Brittany still.. - does not touch anything other than top-level type signatures and bindings (imports, classes, instances, data decls, .. are not modified); - contains some bugs (but it checks its own output for validity and aborts); - does not handle many "uncommon" syntactic constructs/extentions (e.g. arrow notation); In preparation of this release the `butcher` and `czipwith` packages were published on hackage as well. I will cover those in separate announcements. *Building* Brittany currently requires ghc-8.0 (no support for previous ghc versions is planned, but 8.2 will be). Now that this package is on hackage, cabal users should be able to install it directly; stack users will currently have to clone and go from there (a stack.yaml is provided). Detailed building guides for cabal, cabal-new and stack are in the project README. Inclusion in stackage is coming as soon as all dependencies are included. *Known issues* - Bad performance for large inputs (really noticeable at >1k loc). The cause is already determined - quadratic instead of linear complexity in one specific function (see issue #34 [9]). Should be fixable and has high priority. - The config (file) lacks documentation. - Comments are not always reproduced exactly when reformatting. There is a lack of testcases for comments in the testsuite. There is the known case of comments in List/MonadComprehensions that currently breaks idempotency (the comments move further left each roundtrip through brittany) where a solution will most likely involve some non-trivial changes in ghc-exactprint (see [10]). - As mentioned above: only certain module elements are transformed, and not all syntactical constructs are supported. re-layouting of imports, data decls, classes and instances are on the radar, but all require a good amount of work. - CPP is not officially supported. This is mostly a WONTFIX. One can enable it by force, and it works to a degree, but it is relatively easy to find cases where it will break (conditional code not being reformatted, leading to syntax errors and theoretically also to change semantics)). - No fine-grained (per file or even per-function) control/configuration, e.g. it is not yet possible to add some pragma/comment to disable reformatting this one carefully layouted-by-hand function that brittany messes up. - No adaption to ghc-8.2 yet. *Future/Outlook* As far as I can tell brittany already works rather well - I use it all the time, even though I still run into issues from time to time. Still, brittany is not finished (these projects never really are, are they?). Up on my list are ghc-8.2 adaption, fixing the performance bug mentioned above, layouting of data decls, layouting of instances, and controlling behaviour/config via flags in the source (as comments). But implementing new functionality costs a lot of time, even with the DSL used internally: One has to understand the GHC AST (which is not always documented), think of all possible interactions ("do users really use record syntax when having more than one constructor?" "are GADT records a thing?"), write the layouting transformation and test it. I have already invested a good amount of my free time into this project but its scope is too large and I decided to put a limit on my personal investment. This means that barring some form of support from the community I don't see new features being implemented at any certain pace. This leaves the following paths: 1) This project is supported monetarily: I hereby offer to (part-time) work on this provided appropriate funding. I am not sure who exactly might be interested in providing this kind of support - I am no student anymore so GSoC is out of the question. Feel free to contact me on- or off-list if interested. 2) (More) Contributors add tests, report (and maybe fix) bugs and most importantly implement new functionality (layouting for any syntactic constructs of the haskell language not yet supported, etc.) I realize that this is not a trivial project to dive into, and there is a good amount of stuff one has to get familiar with before one can start making use of the abstractions (the DSL) provided. On the other hand, I _think_ that the project source code is relatively well-structured (although in-source comments are really sparse, admittedly) and the high-level (markdown) documentation <strike>will scare everyone away due to their length</strike> will allow understanding the project relatively quickly. 3) The project will progress only rather slowly. Regardless I plan to continue maintaining this project, fix bugs as they come up and also work on expanding functionality when I find the time. *Contributing* In ascending order of involvement, you can contribute by: - Reporting issues, especially instances of bad layouting (especially when it is not a pure matter of opinion); - Add to the testsuite, specifically to the `tests.blt` file of the `littests` test. It contains a large number of tests already, but the coverage is not very good. - If you want to really help implementing more stuff, the high-level docs [7] are the right place to get a rough overview, especially the theory document [11]. I have not documented how to write new layouters yet, so for now I recommend looking at the existing ones, e.g. in `Expr.hs`. -- lennart [1] https://hackage.haskell.org/package/brittany https://github.com/lspitzner/brittany/ [2] https://mpickering.github.io/posts/2015-07-23-ghc-exactprint.html https://hackage.haskell.org/package/ghc-exactprint [3] https://github.com/lspitzner/brittany/blob/da692a4341399390018fb03773e15865… [4] https://github.com/lspitzner/brittany/tree/master/doc/showcases [5] https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124793.html [6] https://github.com/lspitzner/brittany/blob/da692a4341399390018fb03773e15865… [7] https://github.com/lspitzner/brittany/blob/master/doc/implementation/index.… [8] https://github.com/haskell/haskell-ide-engine [9] https://github.com/lspitzner/brittany/issues/34 [10] https://github.com/alanz/ghc-exactprint/issues/53 [11] https://github.com/lspitzner/brittany/blob/master/doc/implementation/theory… -- some layouting examples - would be (re)produced in exactly this way by brittany: > main = do > > now <- getCurrentTime > let (_, _, week) = toWeekDate . utctDay $ now > putStrLn $ ("it's "++) $ case week of > 6 -> "the weekend" > 7 -> "the weekend" > _ -> "a weekday" > > localtime <- utcToLocalZonedTime now > let hr = todHour . localTimeOfDay . zonedTimeToLocalTime $ localtime > case hr of > _ | hr < 12 -> putStrLn "it's before noon" > | otherwise -> putStrLn "it's after noon" > -- Newlines are used sparingly: Only after "do" and when the > -- `liftBaseOpDiscard` application would lead to overflowing 80 columns. > main :: IO () > main = do > pool <- createPostgresqlPool (toS databaseConnectionString) 10 > initiate $ \chan -> forever $ do > flip runDbConn pool $ do > makeSureQueueIsFull chan > void $ liftBaseOpDiscard (consumeMsgs chan responseQueue Ack) > (uncurry processMsg) > threadDelay 1000000 > -- Alignment of patterns > go [] "" = True > go [WildCard ] "" = True > go (WildCard :rest) (c:cs) = go rest (c : cs) || go (WildCard : rest) cs > go (Union globs:rest) cs = any (\glob -> go (glob ++ rest) cs) globs > go [] (_:_) = False > go (_:_) "" = False

1 0

Running ghci in a Cabal sandbox
by Emil Axelsson 04 Aug '17

04 Aug '17

Hi! I have a small file Test.hs alone in a directory: {-# LANGUAGE DeriveGeneric #-} module Test where import Data.Hashable import Data.Scientific import GHC.Generics data Sc = Sc Scientific deriving (Generic) instance Hashable Sc To be able to load this file, I set up a Cabal sandbox: $ ghc --numeric-version 8.0.2 $ cabal --numeric-version 1.24.0.2 $ cabal sandbox init ... $ cabal install hashable-1.2.6.0 scientific ... (Note: not the latest version of hashable.) Now, if I try to run GHCi and point it to the sandbox' package database I get this error: $ ghci -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) Test.hs:12:14: error: • No instance for (Hashable Scientific) arising from a use of ‘hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt’ • In the expression: hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc In an equation for ‘hashWithSalt’: hashWithSalt = hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc In the instance declaration for ‘Hashable Sc’ Somehow it mixes in version 1.2.6.1 of hashable, even though this package isn't installed (neither in the sandbox nor the global database). It turns out that wrapping the command in `cabal exec` fixes the problem: $ cabal exec -- ghci -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) Ok, modules loaded: Test. *Test> Any idea what's going on? / Emil

1 0

Question?
by Casey Newsome 04 Aug '17

04 Aug '17

Hello, I am a new user of Haskell. I was wondering if this is where I can ask a question on a program I am attempting to write. If this is the wrong place. I apologize. Sorry if there was an inconvenience, Casey :D

4 3

Low-level idea: Aligned tagged ByteArray#
by Zemyla 03 Aug '17

03 Aug '17

I had an idea for a way to attach small-but-necessary amounts of information to a ByteArray# or MutableByteArray# (and potentially also to Array# and ArrayArray#). The type would look something like "TaggedByteArray# 8#". This, for instance, would represent the address of a primitive array of bytes, with an alignment of 8, and with the last 3 bits having a number between 0 and 7 in them. Code to access the elements of the ByteArray# would disregard the last bits, and the garbage collector would simply ensure that the tag was retained after collection passes. "ByteArray#" itself would simply become an alias for "TaggedByteArray# 1#", and the existing functions would have their types changed to work with the new TaggedByteArray#s. The primary potential problems I see are how to have a KnownNat-style typeclass before Integer is defined, and how to store both the array and the tag in an ArrayArray#.

1 0

Haskell in Leipzig 2017: submission deadline shifted by two weeks
by Wolfgang Jeltsch 02 Aug '17

02 Aug '17

Hi! We have shifted the submission deadline for Haskell in Leipzig 2017 by two weeks. The new deadline is at 18 August 2017. Looking forward to your contribution. 😉 Event: Haskell in Leipzig 2017 Time: October 26–28, 2017 Place: HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About ===== Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Contributions ============= Everything related to Haskell is on topic, whether it is about current research, practical applications, interesting ideas off the beaten track, education, or art, and topics may extend to functional programming in general and its connections to other programming paradigms. Contributions can take the form of * talks (about 30 minutes), * tutorials (about 90 minutes), * demonstrations, artistic performances, or other extraordinary things. Please submit an abstract that describes the content and form of your presentation, the intended audience, and required previous knowledge. We recommend a length of 2 pages, so that the program committee and the audience get a good idea of your contribution, but this is not a hard requirement. Please submit your abstract as a PDF document at https://easychair.org/conferences/?conf=hal2017 until Friday, August 18, 2017. You will be notified by Friday, September 8, 2017. Hacking Projects ================ Projects for the hackathon can be presented during the workshop. A prior submission is not needed for this. Invited Speaker =============== * Ivan Perez, University of Nottingham, UK Invited Performer ================= * Lennart Melzer, Robert-Schumann-Hochschule Düsseldorf, Germany Program Committee ================= * Edward Amsden, Plow Technologies, USA * Heinrich Apfelmus, Germany * Jurriaan Hage, Utrecht University, The Netherlands * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair) * Andres Löh, Well-Typed LLP, Germany * Keiko Nakata, SAP SE, Germany * Henrik Nilsson, University of Nottingham, UK * Ertuğrul Söylemez, Intelego GmbH, Germany * Henning Thielemann, Germany * Niki Vazou, University of Maryland, USA * Johannes Waldmann, HTWK Leipzig, Germany Questions ========= If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang-it(a)jeltsch.info.

1 0

What code is generated for binary functions of data types with multiple constructors?
by Clinton Mead 02 Aug '17

02 Aug '17

Assume the following: 1. We have a type T with multiple constructors, but lets assume we're on a 64 bit machine and have at least 4 but no more than 7 constructors so we can still use pointer tagging. 2. And a function "f :: T -> T -> T" 3. Each combination of constructors (16 in the 4 constructor case, 49 in the 7 constructor case) has an implementation (naturally many of these will call helper functions). There's no wildcard matches. How will GHC generate the code for "f"? Will pushing through LLVM make any difference? Do we take the number of the first constructor, and then multiply the number of the second constructor by say 7, and then do one jump via a jump table? Is there a bunch of nested jump tables, each with 7 options? Is there a fall through if statement? Something else? I understand this probably a complex answer and perhaps doesn't have a simple answer, but I just wanted to get some sort of idea in my head of how GHC attempts to resolve code like this.

2 1

What can be UNPACK'ed?
by Tom Ellis 02 Aug '17

02 Aug '17

What types can be UNPACK'ed? From my vague understanding of what UNPACK does, it can only be types whose size is bounded by a known value, so whilst data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int is fine, presumably data Foo = Foo {-# UNPACK #-} ![Float] is not fine. Or is it? Technically it could be possible to reserve enough space in Foo to store either a [] or a (:) Float [Float]. And if that is possible could we also UNPACK polymorphic fields? data Storable a => Foo a = Foo {-# UNPACK #-} a or data Foo a where Foo :: Storable a => {-# UNPACK #-} a -> Foo a if either DatatypeContexts worked or my imaginary GADT UNPACK syntax worked (I'm not sure if either does). What are the limits of what we could reasonably get to UNPACK in GHC? Thanks, Tom

5 9

Problems with Type family and Typeable
by Kai Zhang 01 Aug '17

01 Aug '17

I got an error when compiling the following codes: {-# LANGUAGE TypeOperators #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} import Data.Type.Bool import Data.Type.Equality import Data.Tagged (Tagged(..)) import Data.Typeable type family Elem x xs :: Bool where Elem _ '[] = 'False Elem a (x ': xs) = a == x || Elem a xs elemTag :: forall a s t ts . Proxy s -> Tagged (t ': ts) a -> Bool elemTag _ _ = if typeOf (Proxy :: Proxy (Elem s (t ': ts))) == typeOf (Proxy :: Proxy 'True) then True else False GHC says: • No instance for (Typeable (Data.Type.Equality.EqStar s t || Elem s ts)) arising from a use of ‘typeOf’ • In the first argument of ‘(==)’, namely ‘typeOf (Proxy :: Proxy (Elem s (t : ts)))’ In the expression: typeOf (Proxy :: Proxy (Elem s (t : ts))) == typeOf (Proxy :: Proxy True) In the expression: if typeOf (Proxy :: Proxy (Elem s (t : ts))) == typeOf (Proxy :: Proxy True) then True else False My question: why is ghc unable to deduce that "Data.Type.Equality.EqStar s t || Elem s ts" resolves to "Bool" which should be an instance of Typeable? How to fix this?

3 6

Many packages blocked on Stackage nightly for GHC 8.2.1
by Dan Burton 01 Aug '17

01 Aug '17

Please be advised that many packages were dropped from the Stackage nightly build plan in order to arrive at a successful build with the new ghc. (Note that this does not affect the build plans for LTS 9.) This is to be expected whenever ghc gets a major version bump. For details, see: https://github.com/fpco/stackage/blob/master/MAINTAINERS.md We have attempted to contact package authors whose packages were dropped. However, comprehensive notification is not fully automated, and there may be many who have not been directly contacted. You can check your section of build-constraints.yaml, as well as stackage.org/nightly, to see which of your packages are currently absent from the build plan. You may restore your packages to the nightly build plan (once they are buildable with ghc 8.2.1) in the same way they were added: by opening a PR, uncommenting your packages in build-constraints.yaml. Thank you for your efforts to keep the Haskell ecosystem up to date.

2 1