August 2015 - Haskell-Cafe

ANN: ghc-mod-5.3.0.0
by Daniel Gröber 17 Aug '15

17 Aug '15

I'm pleased to announce the long awaited release of ghc-mod 5.3.0.0! What is ghc-mod? ================ ghc-mod is both a backend program for enhancing editors and other kinds of development environments with support for Haskell and a library for abstracting the black magic incantations required to use the GHC API in various environments, especially Cabal projects. The library is used by ambitious projects like HaRe[1] and mote[2]. After a period of declining activity, development has been picking up pace again since I have taken over as maintainer. Most changes during versions 5.0.0 through 5.2.1.2 consisted only of fixes and internal cleanup work, but this release brings with it vastly improved Cabal support and support for GHC 7.10. ghc-mod now has intimate knowledge of the components in a Cabal project, this allows it to make much more informed decisions about which options to pass to GHC for any given module than previously possible. The largest complication for this work was the fact that ghc-mod must consult Cabal's internal configuration information (the file that `cabal configure` generates) which is bound to one specific version of Cabal (the library) while surviving users upgrading their cabal-install executables, which will link `cabal` (the executable) against a different version of Cabal (the library) thus breaking ghc-mod's ability to read the configuration information. Out of the frustration with this horrible state of affairs cabal-helper was born (https://github.com/DanielG/cabal-helper) which now isolates ghc-mod against any and all Cabal version related problems. Long story short this all is a major step forward in terms of how well ghc-mod's suggestions reflect what `cabal build` would report, and should also allow ghc-mod to work even in more complicated Cabal setups. How to contribute ================= Right now ghc-mod has only one core developer and only a handful of occasional drive-by contributors even though it's a non-insignificant part of the first-time Haskell experience, we regularly receive bug reports and support requests from people only just starting Haskell hacking. Unfortunately in the last 7 months this experience was not a very good one because we are sorely lacking active contributors willing to actually fix bugs. I think this is a very disappointing state of affairs since we're essentially driving people away to other languages for no good reason. The way forward --------------- Right now I'm working full time on ghc-mod as part of a summer internship at IIJ Innovation Institute in Japan and will continue to do so until the end of September. I would like to invite anyone who is interested in improving ghc-mod to come and talk to me in #ghc-mod on Freenode (I'm "dxld" there) or E-Mail me directly. During my internship I will be working on splitting ghc-mod into a frontend and backend package to make integration with external tools like HaRe and mote easier, rewriting the ghc-mod frontend tools to be based on a server-client architecture and if time allows adding proper interactive code execution to ghc-mod so it can be used as a ghci replacement in frontends. In the meantime my supervisor Kazu Yamamoto will also be hacking on ghc-mod, mostly improving the Emacs frontend and possibly merging it into haskell-mode[3]. The ghc-mod code base can be quite a beast for anyone looking at if for the first time, I've been trying to improve the situation since I joined the project but after a while you just loose this new pair of eyes and become blind to all the things that could be improved. While I'm still at IIJ-II I can offer anyone who wants to work on ghc-mod my support in getting started with the codebase. Getting ghc-mod =============== Github: https://github.com/kazu-yamamoto/ghc-mod Hackage: http://hackage.haskell.org/package/ghc-mod Frontends: - Emacs (native): https://github.com/kazu-yamamoto/ghc-mod https://github.com/iquiw/company-ghc - Vim: https://github.com/eagletmt/ghcmod-vim https://github.com/eagletmt/neco-ghc - Atom: https://github.com/atom-haskell/ide-haskell https://github.com/andyfriesen/Helium Known issues ============ The new and improved Cabal support required heavy use of caching and there seem to still be some cases of cache invalidation of the module graph not working properly. For now these can be fixed by deleting dist/setup-config.ghc-mod.* ghc-mod's `case`, `sig` and `refine` commands do not work properly with GHC 7.10 yet: https://github.com/kazu-yamamoto/ghc-mod/issues/438 If you do notice any other problems please report them: https://github.com/kazu-yamamoto/ghc-mod/issues ---- [1]: https://github.com/alanz/HaRe [2]: https://github.com/imeckler/mote [3]: https://github.com/kazu-yamamoto/ghc-mod/issues/454#issuecomment-127603458 https://github.com/kazu-yamamoto/ghc-mod/issues/544

1 0

How to model outer space for a MUD
by Michael Litchard 16 Aug '15

16 Aug '15

Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some planet. I'm curious as to how one might model this system that could simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. None of these? Ideas?

7 10

Swedish spin-off has openings for advanced functional programmers - Haskell, OCaml, Scala, and more, Functor, the Swedish Martin-Löf type theory spinoff, is in the midst of recruiting right now, interviewing beginning already — Is it for you?
by Johan Glimming 16 Aug '15

16 Aug '15

Hi, Do you want to be part of the journey as the Functor startup research spin-off innovates the future of software engineering? Do you want to make a difference? Do you want to devote your talents where it can have incredible impact on the entire software industry? Functor, Sweden, is again looking for brilliant minds, essentially co-founders as a generous equity program will after a certain threshold time make sure developers, building the company indeed, also own what they are building. Now, for what follows, hold on to your seats a bit, and remember we are a spinoff startup still, and have no marketing department though we do have expertise in human resources, the most important resource for any company at any given time, to nourish and breed a culture of excellence at any given time at Functor. Remote work initially is not a problem before we move those we can, though probably not all developers will be able to move, to great office space in Sweden. We have to recruit internationally for obvious reasons (read about our technology below). There are openings at Functor Group AB, and Functor AB, Functor Consulting AB, Sweden, including also remote work, except for Scala consultants who must immediately relocate. Feel free to forward this further, and jobs(a)functor.se can also be used according to the final paragraph in this posting, while we favour the LinkedIn job advertisement with as many of the appendices we hope for as possible (see https://goo.gl/4agSy6 <https://goo.gl/4agSy6>). We are in the midst of recruitment, and those who already applied please stay tuned, for others, check the following and the links further below. Note that we use both Haskell and OCaml in our development. Functor Scalor™ heavily uses Haskell in its top layers but the Martin-Löf type theory virtual machine is written in OCaml so we need you to master functional programming at large, since OCaml is at the moment faster and has for our purposes the right libraries for LLVM bindings etcetera. We do static analysis for embedded software with our product Functor Prevent™, and 95% of that software is written in C, just like Erlang/OTP, MySQL, IoT OSes and the Linux kernel, and numerous trending projects at GitHub, and OpenSSL where we have shown we would have prevented the Heartbleed bug and security vulnerability <http://www.bbc.co.uk/search?q=heartbleed> the worst bug in human history in the sense of numerous metrics, whilst damages are impossible to know (you did change all your passwords, we hope), and other bugs such as the sendmail bug whereby virtually all UNIX and Linux servers where open to attack some years ago and hopefully for the most part patched today … Apply to work at Functor as LinkedIn job applications are still accepted now but closing soon and interviews has begun. We might need you at Functor for our success and further growth: ■ Apply from LinkedIn <https://goo.gl/ZkdMQY>, see instructions below, https://goo.gl/ZkdMQY <https://www.facebook.com/l.php?u=https%3A%2F%2Fgoo.gl%2FZkdMQY&h=-AQGfp_6ZA…> ■ For instructions <https://goo.gl/4agSy6> read the last paragraph of the earlier LinkedIn posting: https://goo.gl/4agSy6 <https://www.facebook.com/l.php?u=https%3A%2F%2Fgoo.gl%2F4agSy6&h=NAQE9lGOoA…> <https://www.linkedin.com/pulse/functor-looks-strengthen-leadership-more-tal…> We use Haskell, OCaml, LLVM and our tools are closely tied to the C programming language and indeed to functional programming. Embedded software market is one target market, and skills in compiler design, type systems and operational semantics is key to our teams though we look for optimised teams as a whole, and your particular skill set may or may not include a PhD, but surely industrial experience. We have openings for Research Engineers and have some renown Research Engineers already. Research collaboration is key to our success and projects planned including a large EU project CONSTRUCTOR next year. We have strong industrial partners and some very high-profile customers internationally. The customer-driven journey is still at an early stage, while founded in 2011, and your contributions would be key to our success. Since last year, we use OCaml for key components in both Functor Prevent™ and Functor Scalor™ lower layers, including due to LLVM bindings and for performance (both tools are exceptionally efficient. The Functor Scalor™ with the new Score™ low-level type theory machine uses OCaml. Hence, the lowest lavel is indeed pure Martin-Löf type theory. Functor Scalor™ is amazingly ultimately solid Scandinavian operational semantics adapted for a meta programming language specifically. With this core developed and then in every detail overseen by Per Martin-Löf himself, we have a reliable and state-of-the-art virtual machine. Our research adds to this a defined W-type monad creating a category with the desirable properties. Hence, on top of the solid logic core, Scalor™ has facilities to perform as fast as C in critical components. The benchmarks speak for themselves, and yet Scalor™ is a new kind of meta programming platform, aligned with the domain-driven design movement, though we have aligned it with advances in software engineering, known as domain engineering, which is an emerging new methodology giving DDD a solid foundation, but at the same time not compromising in any way, in any product, the simplicity and elegance. Programmers are not mathematicians, but inside our products you will find some seriously exciting technology to make it all possible. See www.language-driven.org <http://l.facebook.com/l.php?u=http%3A%2F%2Fwww.language-driven.org%2F&h=DAQ…> and www.domain-specific.org. <http://l.facebook.com/l.php?u=http%3A%2F%2Fwww.domain-specific.org%2F&h=CAQ…> For this reason, we need additional brilliant OCaml developers to strengthen our teams, both for Functor Prevent™ and its program analysis with dependent types also based on solid operational semantics, and Functor Scalor™ with full-blown type theory, named the new constructive programming paradigm already back in 2012, unwittingly perhaps a name coined by Per Martin-Löf himself. Recent progress has made all this possible, and industrial productification has made it all usable in real-world applications, despite the advanced technology inside, which can be trusted, implies elegance, coherence, simplicity, and with close to zero-learning curve for Prevent™ and a lean one for Functor Scalor™. Scala consultants will be sent straight from the top down into projects at Ericsson for very challenging work. For these three consultants we require an exceptionally strong background with Scala projects as we team up with Typesafe and secure projects that can only be matched by exceptional Scala developers. Our Functor Scalor™ is oriented somewhat differently than Scala, see www.domainspecific.org <http://l.facebook.com/l.php?u=http%3A%2F%2Fwww.domainspecific.org%2F&h=KAQE…> for some initial information on that products that appeals to very large companies at this stage, while Functor Prevent™ is suitable for just about any software development projects, currently doing static analysis with dependent types and automatic testing for C code, such as the Erlang code base, Twitter’s MySQL branch or embedded software at large, see www.functorprevent.com <http://l.facebook.com/l.php?u=http%3A%2F%2Fwww.functorprevent.com%2F&h=WAQG…> or www.static-analysis.org <http://l.facebook.com/l.php?u=http%3A%2F%2Fwww.static-analysis.org%2F&h=MAQ…>, and also the standalone tool www.functor.se/prevent <http://l.facebook.com/l.php?u=http%3A%2F%2Fwww.functor.se%2Fprevent&h=MAQFr…> which secures systems including a project at a customer with a range of 100 MEUR/each equipment investments, all relying on the VxWorks C code where our Functor Prevent™ delivers its value to prevent up to 50% of the bugs in certain projects, already with its current R1 feature set! For instructions on how to best apply, what we recommend, read our pre-compaign LinkedIn posting: ■ Openings for functional programmers at Swedish startup <https://goo.gl/4agSy6>, https://goo.gl/4agSy6 <https://www.facebook.com/l.php?u=https%3A%2F%2Fgoo.gl%2F4agSy6&h=TAQFTHNkpA…> - see instructions on last paragraph! Read up with links above to our webpages (last link), and postings on LinkedIn and Facebook: ■ The Future of Software Engineering <https://goo.gl/mbd76F>, https://goo.gl/mbd76F <https://www.facebook.com/l.php?u=https%3A%2F%2Fgoo.gl%2Fmbd76F&h=DAQGprr1EA…> ■ Functor looks to strengthen leadership <https://goo.gl/rVtMLx>, https://goo.gl/rVtMLx <https://goo.gl/rVtMLx> See also recent news media coverage of Functor, and other LinkedIn postings: ■ Embedded Conference Scandinavia <https://goo.gl/1vN2Ij>, https://goo.gl/1vN2Ij <https://www.facebook.com/l.php?u=https%3A%2F%2Fgoo.gl%2F1vN2Ij&h=YAQFGOtBEA…> ■ Information for STHML TECH FEST <https://goo.gl/kANCT5>, https://goo.gl/kANCT5 <https://www.facebook.com/l.php?u=https%3A%2F%2Fgoo.gl%2FkANCT5&h=nAQE4-iyVA…> ■ STHML TECH FEST invitation <https://goo.gl/RzEI9H>, https://goo.gl/RzEI9H <https://www.facebook.com/l.php?u=https%3A%2F%2Fgoo.gl%2FRzEI9H&h=rAQHn7PN0A…> Older job campaign provides some useful further information — beware that it is not the current one: ■ Openings globally for Scala & Haskell developers, https://goo.gl/6is0xU <https://goo.gl/6is0xU>, now out-dated but can be good reading just the same for candidates! Some of our Facebook pages, like them and see occasional posts in your own news feed as a result: ■ Functor AB <http://www.facebook.com/functor>, www.facebook.com/functor <https://www.facebook.com/functor> ■ Functor Group AB <http://www.facebook.com/functorgroup>, www.facebook.com/functorgroup <http://www.facebook.com/functorgroup> Join some interesting groups on Facebook and contribute: ■ Software Bugs <https://www.facebook.com/groups/softwarebugs>, https://www.facebook.com/groups/softwarebugs <https://www.facebook.com/groups/softwarebugs> ■ High-Tech Startups in Sweden <https://www.facebook.com/groups/hightechsweden/>igh-Tech Startups in Sweden <https://www.facebook.com/groups/hightechsweden/>, with the allegedly richest woman in Sweden, the acting Wallenberg family are all men, serial entrepreneur in IT already a member in this new group that we manage, https://www.facebook.com/groups/hightechsweden/ <https://www.facebook.com/groups/hightechsweden/> ■ High-Tech Startup Jobs in Sweden <https://www.facebook.com/groups/swedentech>, https://www.facebook.com/groups/swedentech <https://www.facebook.com/groups/swedentech> We host a newly announced event sporting leaders of the largest entrepreneur networks in Sweden although just announced, welcome to join us at Hotellet in Stockholm, which is an amazing place for the kick-off. Special invites and keynote speaker, plus mingle and drinks of course, all professional in the spirit of the group description for High-Tech Startups in Sweden, which organises the event (viz. Functor AB, Functor Group AB), co-hosts to be announced: ■ High-Tech Startup Meetup Launch hosted by Functor Group AB <https://www.facebook.com/events/1631452680449642/?ref=1&action_history=%5B%…>, all welcome within this special interest community, it’s perhaps just an airplane away? <https://www.linkedin.com/pulse/openings-functional-programmers-swedish-star…> APPENDIX FOR SOME TECHNOLOGY INSIGHTS AND OUR VISION FRAMED ACTUALLY BY NO ONE ELSE BUT BJARNE STROUSTRUP IN HIS COMPUTER REVIEW PAPER OF THE YEAR (2012) CONTRIBUTION: Why dependent types then? You probably already understand this, and the reasons are numerous and far from just technical. You have surely read up on many papers such as “Why depdendent types matter?” and more. You might see why the timing is just right now, but let’s hear out what a very influential programming language contributors has to say about the problems we address and how they should be addressed: Stroustrup didn’t quite imagine going outside C++, at least not in his Computing Reviews "Best of 2012" paper (PDF via link below). His paper on Infrastructure Software (, though, makes the case for dependent type theory and our products very strongly. John Mitchell frames his contributions very well by writing " The main goal of C++ is to provide object-oriented features in a C-based language without compromising the efficiency of C … data abstraction and object-oriented features … better static type checking … efficiency of compiled code …” (book reference below). Functor Scalor™ has an object-based object model derived from the Timber projects (which came out of O’Haskell) and a novel component model on top of that for low-level performance with dependently typed interfaces. Added to the domain-driven design movement and augmenting it, meaning methodological advantages of a meta programming language, Functor Scalor™ is a direct solution to the problems pinpointed by Stroustrup in IEEE Computer, January, 2012: ■ Stroustrup’s “Software Development for Infrastructure” paper selected by CR Best of 2012 : Standard C++ <https://isocpp.org/blog/2013/05/stroustrups-software-development-for-infras…>, we advise strongly to skip those pages towards the end involving C++, for obvious reasons when the Constructive Programming Paradigm was coined to be the next programming paradigm in STEW 2012 co-autthored by Thorsten Altenkirch and Patrik Jansson (“What is the next programming paradigm?”, STEW 2012). Let’s also cite Löh, McBride and Swierstra in a paper that is probably familiar to all of you: "Most functional programmers are hesitant to program with dependent types. It is said that type checking becomes undecidable; the type checker will always loop; and that dependent types are just really, really, hard. The same programmers, however, are perfectly happy to program with a ghastly hodgepodge of complex type system extensions. Current Haskell implementations, for instance, support generalized algebraic data types, multi-parameter type classes with functional dependencies, associated types and type families, impredicative higher-ranked types, and there are even more extensions on the way. Programmers seem to be willing to go to great lengths just to avoid dependent types. One of the major barriers preventing the further proliferation of dependent types is a lack of understanding amongst the general functional programming community. While, by now, there are quite a few good experimental tools and programming languages based on dependent types, it is hard to grasp how these tools actually work. A significant part of the literature available on dependent types is written by type theorists for other type theorists to read. As a result, these papers are often not easily accessible to functional programmers.” Löh et al, A tutorial implementation of a dependently typed lambda calculus <http://www.andres-loeh.de/LambdaPi/LambdaPi.pdf> († <http://content.iospress.com/articles/fundamenta-informaticae/fi102-2-03>), Fundamenta Informaticae, no. 2 (vol.102), 2010, pp. 177-207. See also this link <http://www.andres-loeh.de/LambdaPi/> if you wish. As we are developers, bringing cutting-edge technology and a mountain of research right into the industry, standing on the shoulders of giants and work done during four decades, you may enjoy also eg this article: ■ Sheard et al, Language-based verification will change the world <http://dl.acm.org/citation.cfm?id=1882432>, ACM proceedings of the FSE/SDP, Future of software engineering research, SIGSOFT/FSE'10 18th ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE-18), 2010, ACM Press. (PDF <http://www.seas.upenn.edu/~sweirich/papers/foser10.pdf>) <https://www.linkedin.com/pulse/openings-functional-programmers-swedish-star…> Not to in any way diminish the contributions of Bjarne Stroustrup we include this image courtesy of Google Books, click to read the book about why C++ is not up to the tasks that Functor Scalor™ and Functor Prevent™ are. C++ has had great impact on the software community and is still heavily used. That said, John Mitchell lists numerous shortcomings in the book, but we honour Stroustrup in this manner: <https://books.google.se/books?id=7Uh8XGfJbEIC&pg=PA100&lpg=PA100&dq=mitchel…> John Mitchell writes (Concepts of Programming Languages, Cambridge University Press, 2002): "C++ is an object-oriented extension of the C language. It was originally called C with classes , with the name C++ originating around 1984. A Bell Laboratories researcher interested in simulation, Bjarne Stroustrup began the C++ project in the early 1980s. His goal was to add objects and classes to C, using his experience with Simula as the basis for the design. The design and implementation of C++ was originally a one-person effort, with no apparent intent to produce a commercial product. However, as interest in objects and program structure grew over the course of the 1980s, C++ became popular and widely used. In the 1990s, C++ became the most widely used object-oriented language, with good compilers and development environments available for the Macintosh, PC, and Unix-based workstations." We are not using C++ in any of our products, but honour the historical importance of Stroustrup. You’ll find us easily on Twitter, @functors, @functorgroup, @functortech, etc! PS. Servers are again considerably boosted / upgraded this very night (CET), but subscribe to newsletter.functorgroup.com <http://newsletter.functorgroup.com/> and you’ll receive a message when the server work is completed, and for rare but then important news from us in the future. Our real, non-backup site deserves a careful read through before you apply, we strongly recommend this as you would have to share our vision and believe in it too. Some links in this email may not work until tomorrow as we host everything on our own secure very powerful HP servers, hosting very sensitive customer code from companies you are familiar to should we disclose their name, and therefore have invested in our servers again. Be sure to check back on the links such as domain-specific.org <http://domain-specific.org/> and so on and indeed www.functorgroup.com <http://www.functorgroup.com/> tomorrow CET when we open the firewall again and liberate our work horses, then even stronger. Compile time with Haskell is not as blazingly fast as running Functor Prevent™, for all the good reasons, and therefore you will benefit from 48 processors and more when working on our servers. Yours Sincerely, Johan Glimming — Dr Johan Glimming Chief Executive Officer at Functor AB, Chairman at Functor Group AB LinkedIn: se.linkedin.com/in/glimming <http://se.linkedin.com/in/glimming> Functor AB, Box 7070, 164 07 Kista, SWEDEN <x-apple-data-detectors://3/1>, tel. +46-8-55005500 <tel:+46-8-55005500> Web: www.functorgroup.com <http://www.functorgroup.com/> Twitter: @functors <https://www.twitter.com/functors/> UK tel: +44-1223-911400 <tel:+44-1223-911400> US tel: +1-(415)-513-0090 <skype:+1-(415)-513-0090>

1 0

Packages in haskell and licensing
by Arian van Putten 16 Aug '15

16 Aug '15

Hey there, Is there currently any way to look up what licenses all your packages that you pull in have? For example, if I have a GPLv3 package, I want to make sure to not pull in any MIT dependencies. Is something like that currently possible or on the roadmap? -- Groetjes, Arian

3 2

Cross-compiling fails for package 'directory'
by Arie Peterson 16 Aug '15

16 Aug '15

Following <https://github.com/ku-fpg/raspberry-pi/wiki/GHC-Cross-Compiler-for-Raspberr…>, I have built a cross-compiling ghc for creating programs that run on the raspberry pi. This ghc has built a "hello world" program that runs on the rpi: OK so far. Unfortunately, building the package 'directory-1.2.3.0' with this cross- compiler fails with the following error message: "System/Directory/Internal.hsc:31 directive const_str cannot be handled in cross-compilation mode" The offending function from System.Directory is this one: > -- | Filename extension for executable files (including the dot if any) > -- (usually @\"\"@ on POSIX systems and @\".exe\"@ on Windows or OS\/2). > exeExtension :: String > exeExtension = (#const_str EXE_EXTENSION) Although one can imagine that the meaning of this function is tricky when cross-compiling, I don't think that has actually anything to do with the error. The problem is that hsc2hs cannot handle this 'const_str' directive; see <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/hsc2hs.html…>. Now my question: how can this be fixed? Is the failure of hsc2hs to support this directive just a matter of "not implemented right now", maybe by lack of importance? Or is there a fundamental problem? If fixing hsc2hs is hard, could the 'directory' package perhaps choose another way to implement this function?

2 2

Redundant entries in .cabal file?
by David Banas 15 Aug '15

15 Aug '15

Hi all, Does anyone know why I’m getting redundant entries in my ‘cabal init’ generated .cabal file: library exposed-modules: Language.Broker, Language.Broker ? Is it because I’m using a *.hsc file, as my source, and cabal is finding both files: Broker.hsc, and Broker.hs in the Language directory? Thanks, -db

2 1

Unregisterised builds
by Jon Schneider 15 Aug '15

15 Aug '15

Good day all, I am still having issues with (the output from) the cross compiler I have built for PowerPC (e500 family). It seems the runtime is vaguely sane in that it's purposefully whirring round schedule() but for some reason for a "Hello World" allocates stack then heap (after ^C) then runs out then locks up but does not exit. I don't (yet) understand the runtime enough to find the boundary between behaving and not. /tmp # ./helloworld +RTS -Ds created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: allocating new stack chunk of size 32768 bytes cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: allocating new stack chunk of size 32768 bytes ... I have gone through the various +RTS flags but feel I'm going to have to use gdb some more. When using unregisterised to what extent does the compiler need to know about the target platform ? If I said ./configure --target none-of-your-business --with-gcc=my-whizzy-gcc --with-other-tools=... --enable-unregisterised would I be right in saying it this could not be done because it still needs to know things like the word size, endianness and so on or couldn't it get this information just from header files ? What I'm trying to get at is if I did not think there was anything wrong with my cross-gcc, partially because I have experimented with different versions and platforms, what other PowerPC-sepcific knowledge is employed by the unregisterised ghc ? Jon

2 1

Re: [Haskell-cafe] How to model outer space for a MUD
by Doug McIlroy 15 Aug '15

15 Aug '15

> I would not model space -- there's too much of it This lesson has hit home over and over again when people come to the realization that the "inner loop" of their program is unrelated to what the program is nominally doing, Most of the running time is initialization! doug

1 0

"Could not list sources" warning in sandboxed project with add-source deps
by Eric 14 Aug '15

14 Aug '15

I'm getting a warning > Warning: Could not list sources of the add-source dependency 'xyz'.> Skipping the timestamp check. when building a sandboxed project with add-source dependencies. I tried increasing the verbosity of cabal, but it still won't tell me what's going wrong so I can fix it. Any suggestions on how to debug or fix this? thanks,--Eric

2 4

Library for overloaded indexing (a la (!))
by William Yager 14 Aug '15

14 Aug '15

Hello all, I put together a small library for the purpose of creating overloaded indexing operators. The library is available at https://hackage.haskell.org/package/keyed . I would like to solicit some advice on the design of this library. Q1: The library uses TypeFamilies to determine which types to use for the index type (which is used to look up a value) and the value type (which is returned from a lookup). I originally did this using MultiParamTypeClasses and FunctionalDependencies, but thought this was cleaner; are there any good reasons to go back to using FunDeps? Q2: Data.Keyed provides pure indexing, while Data.MKeyed provides monadic indexing (e.g. for mutable vectors or concurrent STM-based maps). I'm having some trouble with the fact that mutable vectors are keyed on the PrimState of their corresponding PrimMonad. Right now, there is a type in the MKeyed class definition called MContainer. This is the type of the Monad that the lookup operation returns. I.e. (!) :: MKeyed d => d -> MKey d -> MContainer d (MValue d) ~ (!) :: IOVector a -> Int -> IO a or (!) :: STVector s a -> Int -> ST s a Unfortunately, this causes an overlap (because both IOVector and STVector are aliased to MVector). I tried making an instance for MVector, but the problem is that it's difficult to actually go from `IOVector a = MVector RealWorld a` to `IO` or `STVector s a = MVector s a` to `ST`, because neither `IO` nor `ST` appears in the type of the vector. I can't do instance (PrimMonad m, s ~ PrimState m) => MKeyed (MVector s a) where ... type MContainer (MVector (PrimState m) a) = m because you can't have type synonyms on the LHS of the type. I tried bringing `m` into scope using RankNTypes, but that didn't work. Is there some syntax I can use to bring `m` into scope here? Or should I be doing this part entirely differently? Q3: Is there any way to automatically derive all instances of Keyed for all types of Data.Vector (using Data.Vector.Generic)? Using `instance Vector v a => Keyed (v a) where ...` doesn't work, as it overlaps with everything of the form `(d :: * -> *) (a :: *) :: *`, like `[a]`. Thanks, Will

5 9