July 2020 - Haskell-Cafe

Re: [Haskell-cafe] Question about zippers on trees
by Olaf Klinke 22 Jul '20

22 Jul '20

> A direct implementation without using a library is interesting, thank > you. I > refrained from doing that, because I thought that Control.Zipper > would actually > do this for me. Actually, I was pretty successful with using > Control.Zipper to > change node labels, but failed doing more complicated stuff. > Isn't that a strong indicator that zippers are an improper abstraction for your purpose? Perhaps after rolling your own implementation you can more easily discover how to represent the algrorithm as a zipper. Olaf

2 1

ghc profiling
by Mika Pöhls 22 Jul '20

22 Jul '20

Hello everyone, I have a question regarding ghc profiling. The .hp file, created during profiling, displays the memory usage until a certain point, which seems to be the end of the execution of the program (based on the exectuion time the program usually takes), as exprected. But after that an extra sample is created, that contains no data (no cost centers, it is just begin sample followed by end sample). This sample is also created out of the 0.1 second gaps used before. For example the last "correct" sample is at 17s and the empty sample is at 40s. When plotting the data, this results in an monotonous increasing graph (for all centers), that has its maximum at the last correct sample (17s) followed by a straight line to zero (40s). Does anyone know, what leads to this behavior and how it can be prevented? Thanks in advance Mika

2 1

Fwd: Judge for programming language contest?
by Michal J Gajda 22 Jul '20

22 Jul '20

Hi, I just noticed that in the age of cambrian explosion among new programming languages we also have programming language jam organized this August: https://blog.repl.it/langjam Given that there are many prolific programming language designers and implementors here -- I wonder if we get a Haskell judge so that advanced type systems can get a fair ruling? (In case you got another round of reviews from traditional PL conferences that described your paper as "badly typeset" and "wrong formatting was intentional", "repetitive" and "hard to understand", or even rude "expect a boring talk".) -- Cheers Michał

1 0

Haskell Love Conference (the 31st of July & 1st of August, 2020)
by Ida Bzowska 20 Jul '20

20 Jul '20

Hi There! We are organizing the online event on Haskell language https://haskell.love, free to attend. The CFP for the event has started (ends on the 1st of July, 2020), please consider joining https://konfy.care/cfp Tickets (free) will be available soon, follow us on twitter https://twitter.com/_haskellove for the updates and feel free to hop on our slack http://tinyurl.com/haskelloveslack λCheers Ida Bzowska

3 7

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.8.4 is now available
by Gregory Guthrie 19 Jul '20

19 Jul '20

I don't see any windows binaries listed; are they there, elsewhere? Lots of Linux (=0.7% desktop market share) versions, but Windows (=78%) only source?. ---------------------------------------------------------------- -----Original Message----- From: Haskell-Cafe <haskell-cafe-bounces(a)haskell.org> On Behalf Of haskell-cafe- On Wed, Jul 15, 2020 at 07:38:31PM -0400, Ben Gamari wrote: > The GHC team is proud to announce the release of GHC 8.8.4. The source > distribution, binary distributions, and documentation are available at > > https://downloads.haskell.org/~ghc/8.8.4

3 5

What causes this "Ambiguous type variable" message (involving an existential type)?
by James Cook 18 Jul '20

18 Jul '20

Hi haskell-cafe, I've run into a strange error. It's easy for me to work around, but I still would like to know what causes it. Here's a minimal example. {-# LANGUAGE Rank2Types #-} module Example where data T = T (forall n . (Show n) => n) d :: a -> Int d = undefined f :: T -> Int f (T t) = d t when I try to compile it (ghc Example.hs) I see the following error: Example.hs:11:13: error: • Ambiguous type variable ‘a0’ arising from a use of ‘t’ prevents the constraint ‘(Show a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’ ...plus 22 others ...plus 12 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the first argument of ‘d’, namely ‘t’ In the expression: d t In an equation for ‘f’: f (T t) = d t | 11 | f (T t) = d t | ^ My question: what causes this error? This seems backward to me. The way I see it, I've told the compiler that any value of type T is guaranteed to contain a value of a type implementing Show, so there should be no question about solving a constraint involving Show. Moreover, the function "d" doesn't even require its input to implement Show. I'm guessing there's some basic rule about existential types that I'm violating here, but I'm not sure where to look if I want to read about that. I've skimmed https://wiki.haskell.org/Existential_type and didn't find anything, but maybe I skimmed too quickly. (Note: if I use Num or Fractional instead of Show, I don't get the error. I guess it's because of defaulting rules for numeric type classes.) If you're interested in how I ran into this, here's a summary. I have this type Scene g with two record fields. Notice the gl_camera_info field doesn't mention the type parameter g. data Scene g where Scene :: RandomGenD g => { part_ :: Part g , gl_camera_info :: GLCameraInfo } -> Scene g Then later I have an existentially quantified scene passed to the VScene constructor here... data BaseVal = VIint Int | VS String | VScene (forall g . (RandomGenD g) => Scene g) | VIO (ShellState -> IO ShellState) | VError String data Val = Val { val_f :: Val -> Val , val_base :: BaseVal } and later (somewhere inside a "where" clause): f (Val _ (VScene scene)) = base_val (VIO (fork_render (gl_camera_info scene) (RLS.muts scene 5e-2 1e-1))) (I don't think the definitions of base_val or RLS.muts matter here.) The use of gl_camera_info seems to cause the problem in this case. I see Shell.hs:137:79: error: • Ambiguous type variable ‘g0’ arising from a use of ‘scene’ prevents the constraint ‘(RandomGenD g0)’ from being solved. Probable fix: use a type annotation to specify what ‘g0’ should be. These potential instances exist: instance [safe] RandomGenD g => RandomGenD (RList g) -- Defined in ‘RList’ instance [safe] RandomGenD StdGen -- Defined in ‘Rand’ • In the first argument of ‘gl_camera_info’, namely ‘scene’ In the first argument of ‘fork_render’, namely ‘(gl_camera_info scene)’ In the first argument of ‘VIO’, namely ‘(fork_render (gl_camera_info scene) (RLS.muts scene 5e-2 1e-1))’ | 137 | f (Val _ (VScene scene)) = base_val (VIO (fork_render (gl_camera_info scene) (RLS.muts scene 5e-2 1e-1))) | ^^^^^ My planned solution is simply to not use an existential type here. I can just make g a parameter of the BaseVal type. But I'm still curious to understand what went wrong. -- James

1 1

[ANNOUNCE] GHC 8.8.4 is now available
by Ben Gamari 17 Jul '20

17 Jul '20

Hello everyone, The GHC team is proud to announce the release of GHC 8.8.4. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.4 Release notes are also available [1]. This release fixes a handful of issues affecting 8.8.3: - Fixes a bug in process creation on Windows (#17926). Due to this fix we strongly encourage all Windows users to upgrade immediately. - Works around a Linux kernel bug in the implementation of timerfd (#18033) - Fixes a few linking issues affecting ARM - Fixes "missing interface file" error triggered by some uses of Data.Ord.Ordering (#18185) - Fixes an integer overflow in the compact-normal-form import implementation (#16992) - `configure` now accepts a `--enable-numa` flag to enable/disable `numactl` support on Linux. - Fixes potentially lost sharing due to the desugaring of left operator sections (#18151). - Fixes a build-system bug resulting in potential miscompilation by unregisteised compilers (#18024) As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.4/docs/html/users_guide/8.8.4-notes.h…

2 1

Final Call for Tutorials, Discussions, and Social Events: ICFP 2020
by Sam Tobin-Hochstadt 16 Jul '20

16 Jul '20

FINAL CALL FOR TUTORIAL, DISCUSSION, AND SOCIAL EVENT PROPOSALS ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 23 - 28, 2020 Virtual https://icfp20.sigplan.org/ The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 23-28, 2020. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". To increase social interaction on the first ICFP virtual conference, this year we invite proposals for social events on topics of broader interest to the PL community. Such events can be panels and discussions (in the lines of the successful #ShutDownPL event), focused discussions (e.g., problem identifications, retrospective analysis, technical demos), social activities (e.g., treasure hunt, bingo, problem solving, artistic challenges). The typical duration of such events ranges from 30 minutes to one hour, but can be of any length. Tutorials may occur before or after ICFP, co-located with the associated workshops, on August 23 or August 27-28. Social events may be scheduled throughout the week. ---------------------------------------------------------------------- Submission details Deadline for submission: July 17th, 2020 Notification of acceptance: July 22nd, 2020 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2020 workshop co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020(a)googlegroups.com by July 17th, 2020. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by July 22nd, 2020. The proposal form is available at: http://www.icfpconference.org/icfp2020-files/icfp20-panel-form.txt http://www.icfpconference.org/icfp2020-files/icfp20-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2020 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Leonidas Lampropoulos (University of Maryland) General Chair: Stephanie Weirich (University of Pennsylvania) Program Chair: Adam Chlipala (MIT) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020(a)googlegroups.com

1 0

How does the RTS "know" about ExitCode
by Georgi Lyubenov 15 Jul '20

15 Jul '20

Hi! I'm wondering how values stored in ExitCode "get to" the RTS (i.e. actually make the program exit with the given number). As far as I can tell ExitCode is used as an everyday normal-looking exception (which are defined entirely in "library code", by using the raise#/catch# primitives), without any direct link to the RTS. What am I missing? ====== Georgi

2 2

setting ISO-8859-1 encoding on Raspbian for GHC
by Henning Thielemann 15 Jul '20

15 Jul '20

On Raspbian Buster I get: pi@raspberrypi:~ $ LANG=de_DE ghc -e 'print System.IO.localeEncoding' UTF-8 pi@raspberrypi:~ $ LANG=de_DE.iso88591 ghc -e 'print System.IO.localeEncoding' UTF-8 pi@raspberrypi:~ $ LANG=de_DE@euro ghc -e 'print System.IO.localeEncoding' UTF-8 Which is not, what I want. On Debian Buster it is correct: $ LANG=de_DE ghc -e 'print System.IO.localeEncoding' ISO-8859-1 How can I check whether this is a GHC problem and has anyone an idea how to fix it?

3 4