January 2018 - Haskell-Cafe

Getting some funny brackets in Haddock docs
by David Feuer 10 Jan '18

10 Jan '18

The containers Haddock documentation currently represents sequences, sets, and maps via the relevant `fromList` function. For example, Data.Map gives the example findWithDefault 'x' 1 (fromList [(5,'a'), (3,'b')]) == 'x' I find these `fromList` calls exceedingly distracting, and I think they obscure the key ideas. Of course, I *could* just specify at the top that the documentation assumes OverloadedLists, but I think that's likely to be somewhat confusing, especially to beginners. My preference would really be to represent these data structures using funny brackets of some sort. Perhaps ⟦7,34,12⟧ for a sequence, ⦃40,3⦄ for a set, and ⟪(12,"alpha"), (14,"bravo")⟫ for a map. But there are three problems: 1. How can I insert the brackets conveniently? I definitely don't want to fill the module with Unicode. My preference would be to use \{ and \} or \[ and \] and have them get replaced by the left and right brackets appropriate to the module in question. But I don't actually know how to do that. 2. Funny brackets could presumably cause trouble for people who don't have appropriate fonts available. How could I mitigate this? 3. This whole idea could cause trouble for people who want to copy and paste examples from the documentation. Are people likely to want to do that? If so, how might I mitigate that problem? Are there tricks I can play to make copy/paste turn a funny left bracket into `fromList [` and a funny right bracket into `]`, and also not break things for non-HTML backends? Thanks, David

4 3

Re: [Haskell-cafe] Package takeover: re2
by Andrey Sverdlichenko 08 Jan '18

08 Jan '18

Thanks! On Mon, Jan 8, 2018 at 11:20 PM John Millikin <john(a)john-millikin.com> wrote: > Just added you to the maintainer's list. Sorry for the delayed response, > I've been away from reliable internet for a few weeks. > > When you upload the next version, please also update the contact info to > yours. I'll say on my site that you're the new maintainer. > > On Mon, Jan 8, 2018 at 9:54 AM, Andrey Sverdlichenko <blaze(a)ruddy.ru> > wrote: > >> I'd like to take over maintenance of the package re2. It is built >> against old version of re2 library, never updated after 2014 and listed as >> "deprecated" on the author's website. I rather update this one than add >> another package for the same bindings. >> >> I tried to contact owner a week ago, but to no avail. My hackage username >> is blaze. >> > >

1 0

looking for deep learning explanation a la Lämmel's map-reduce paper
by Johannes Waldmann 08 Jan '18

08 Jan '18

Dear Cafe, I like this paper (R. Lämmel in SCP 2008) very much https://userpages.uni-koblenz.de/~laemmel/MapReduce/ both for contents and for style - and I wonder if there's something similar ("Haskell for design recovery", "rigorous description", "executable specification") on deep learning. Mainly for understanding/teaching without all the hype. (But of course, an accelerate-* implementation would be nice.) Yes I know that hyperbole *is* the main thing in this area. Happy New Year - J.

2 2

Package takeover: re2
by Andrey Sverdlichenko 08 Jan '18

08 Jan '18

I'd like to take over maintenance of the package re2. It is built against old version of re2 library, never updated after 2014 and listed as "deprecated" on the author's website. I rather update this one than add another package for the same bindings. I tried to contact owner a week ago, but to no avail. My hackage username is blaze.

1 0

Syntax highlight for numeric literals
by Takenobu Tani 07 Jan '18

07 Jan '18

Dear cafe, I wrote and pushed a bit about the syntax highlights of numeric literals for `BinaryLiterals`, `HexFloatLiterals` and `NumericUnderscores` extensions on editors. https://github.com/takenobu-hs/haskell-numeric-highlight I'm glad if this helps you. Regards, Takenobu

2 2

PSA: `cabal update` command needs manual unsticking
by Gershom B 05 Jan '18

05 Jan '18

Dear Haskellers, A recent update to hackage, which fixed up the 01-index.tar.gz file, revealed a bug in existing versions of cabal-install, when index files are cleaned up. This bug means that the `cabal update` command, which updates the hackage index file, will fail silently and leave the old file in place. It is easy to get things working again, but it requires manual intervention. Here is the most straightforward way to get things working again: On gnu/linux or mac: rm ~/.cabal/packages/hackage.haskell.org/01-index.* On windows: remove the same files, but from %appdata%\cabal\packages\hackage.haskell.org rerun `cabal update` to fetch a new 01-index. Apologies all for the inconvenience and any confusion this may have caused. There is a PR to fix this behavior in the works, but since the problem is on the client side, the fix will only improve the situations for new versions of `cabal`. Happy New Years to all, and cheers to a very functional 2018, Gershom p.s.: since the problem comes in unpacking the 01-index.tar.gz into the 01-index.tar, you can also just untar that file in place manually, or force cabal into doing the same by running `touch ~/.cabal/packages/hackage.haskell.org/01-index.tar`

6 5

How does the RTS pin ByteArray# objects during FFI calls?
by Reiner Pope 03 Jan '18

03 Jan '18

Hi Haskell-Cafe, I understand from https://mail.haskell.org/pipermail/haskell-cafe/2014-June/114763.html that it is safe to pass ByteArray# objects to FFI calls, using the UnliftedFFITypes language extension. As I understand it, the implicit guarantee is that the RTS will pin the ByteArray#'s address in memory for the duration of the FFI call -- even if the ByteArray# wasn't allocated pinned. I'm curious: how does the RTS achieve this "retroactive" pinning? The documentation at https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/Pinned suggests that *all* ByteArrays are allocated pinned to account for the possibility that they will in future be passed to the FFI. Is this really the case? This seems like it forces an unreasonably slow allocator on small (say, ~10-byte) ByteArray allocations where the GC's usual bump-pointer allocator might otherwise be preferable. Regards, Reiner

2 2

ANN: capataz-0.0.0.1 - An OTP-like supervisor library for Haskell
by Román González 02 Jan '18

02 Jan '18

Hello, I'm glad to share the release of a new library for supervising Haskell threads inspired in OTP/Akka called capataz * Hackage: http://hackage.haskell.org/package/capataz * Github: https://github.com/roman/Haskell-capataz * Documentation/Tutorials: https://romanandreg.gitbooks.io/capataz/content/ capataz enhances the reliability of your concurrent applications by offering supervision of threads that run in your application. Advantages over standard libraries: * Links related long-living processes together under a common capataz supervisor, with restart/shutdown order. * Set restart strategies (Permanent, Transient, Temporary) on `IO` sub-routines on a granular level * Set restart strategies on a pool of long-living worker threads (AllForOne, OneForOne) * Complete telemetry on your supervised threads lifecycle (start, error, restarts, shutdown) * Drop-in replacement of forkIO invocations Please feel free to reach out if you are curious and have any ideas/improvements. Cheers. Roman.-

1 0

Shadowing record field names
by ☂Josh Chia (謝任中) 01 Jan '18

01 Jan '18

Quite often, I need to use record types like this: data Whole1 = Whole1 { part :: Part, ... } data Whole2 = Whole2 { part :: Part, ... } Where Whole1 & Whole2 are types of things that have a Part and some other things. E.g. a Book has an Author, a Title, etc and so does an Article. The problem is that I'm not actually allowed to use the same name (author/part) in two different record types. Some people use lens to solve this. You can have a lens called 'author' for dealing with the Author in both Book and Article (e.g. using makeClassy). That's fine, but there's yet another problem. Let's say I have a function that takes an Author and a [Library] and returns all the Libraries that have Books or Articles matching the Author. So: findAuthorLibraries :: Author -> [Library] -> [Library] findAuthorLibraries author libraries = ... But I already have a lens called 'author' and ghc will complain about shadowing. So, to avoid shadowing, should I use 'theAuthor' instead of 'author' for the function argument? Or, should I name the lens 'authorLens', 'authorL' or 'lAuthor' instead of 'author'? Prefixing with 'the' is quite unreadable because whether or not an argument has that prefix depends on whether there's a lens with a conflicting name so it adds noise to the code. Adding a 'Lens' prefix to the 'author' lens also seems quite an overbearing eyesore because for consistency I would have to use the prefix for all my field-accessing lenses. Maybe I should use Lens.Control.TH.makeClassy and then define: findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library] findAuthorLibraries hasAuthor libraries = ... But that may be making my function more complicated and general than I want, affecting readability, simplicity, compilation time and maybe even performance. In summary, I find that there are ways around the problem but they really affect readability. I could also disable the warning about shadowing but that seems pretty dangerous. It may be OK to disable the warning for the specific cases where a function argument shadows something from the topmost scope, but GHC does not allow such selective disabling of that warning. In a code base that deals mainly with concrete business logic, this problem probably crops up more than in a code base that deals mainly with more abstract things. What do people do to address this problem? Any recommendations or best practices? Josh

7 10