- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Reading Haddock sources on hackage no longer possible with simple browsers?
by M Douglas McIlroy 16 Nov '20

16 Nov '20

> I am pretty sure nobody writes code like this > I confirmed your example, reading with lynx and w3m. > wouldn’t just directly opening the sources (in a text editor) be simpler? Is there a (simple) way to preserve the experience when browsing using Lynx without also holding back features aimed at a regular browsing experience? I second that. I have always been annoyed by the ransom-note appearance of colorized listings. But that's just my taste. I suspect, though, that lots of people have been frustrated when they discover they can't use the code they see because it's festooned with markup. Golang.org offers similar listings, but also provides a button for selecting the underlying plain text. I would like hackage a lot better if it did so, too. Doug

3 2

[ANN] base64-bytestring-1.2.0.1 + future plans
by Emily Pillmore 16 Nov '20

16 Nov '20

Hi Everyone, I'm pleased to announce that we've released a new version of `base64-bytestring` that now supports `bytestring-0.11` in a backwards-compatible manner. I'd also like to make an RFC: we are thinking that we will drop support for GHC versions <7.10 in future releases of the project. The earliest release in which this can be expected will be around 6 months from now. The dev burden for supporting back to 7.0 is high, and unless someone screams in protest, the value does not seem to be there. I'd like to get your thoughts on this. Cheers, Emily

1 0

Redirecting hackage.haskell.org to HTTPS
by Tikhon Jelvis 16 Nov '20

16 Nov '20

Pages on hackage.haskell.org are currently served over both HTTP and HTTPS. Package security on Hackage does not depend on HTTPS, so we keep HTTP endpoints for backwards compatibility with automated systems that depend on Hackage and do not support HTTPS. However, this means that it's possible for users to inadvertently browse Hackage pages on HTTP which is not a great user experience. To address this issue without breaking existing scripts, we are planning to redirect requests to HTTPS based on User-Agent headers: requests with "Mozilla/5.0" in their User-Agent string will be redirected to HTTPS and other requests will remain unchanged. Please contact us at committee(a)haskell.org if this change will cause problems with how you use Hackage. Otherwise, the new behavior will go into effect on 2020-11-23. Thanks! -Tikhon Jelvis, on behalf of the Haskell.org Committee

3 2

Re: [Haskell-cafe] Reading Haddock sources on hackage no longer possible with simple browsers?
by Johannes Waldmann 15 Nov '20

15 Nov '20

> I recently noticed that it is no longer possible > to read the source of a module, because extra type information > (which is likely hidden in a modern browser) > is inline with the actual sources. I confirmed your example, reading with lynx and w3m. It seems the extra text is the methods of the type classes (mentioned after "deriving") and it gets shown on on mouse-over in a graphical browser. (Re: "nobody writes code like this" - the compiler does? Some methods here seem auto-generated.) Looks like a bug in haddock, then? (Or in lynx' handling of CSS?) The actual HTML source looks legit, at least partially (see example below) This seems related: https://github.com/haskell/haddock/pull/1197 I will open an issue on accessibility. - J.W. deriving (Int -> ISBN -> ShowS [ISBN] -> ShowS ISBN -> String (Int -> ISBN -> ShowS) -> (ISBN -> String) -> ([ISBN] -> ShowS) -> Show ISBN forall a. (Int -> a -> ShowS) -> (a -> String) -> ([a] -> ShowS) -> Show a showList :: [ISBN] -> ShowS $cshowList :: [ISBN] -> ShowS show :: ISBN -> String $cshow :: ISBN -> String showsPrec :: Int -> ISBN -> ShowS $cshowsPrec :: Int -> ISBN -> ShowS Show

4 4

Reading Haddock sources on hackage no longer possible with simple browsers?
by Mario Lang 15 Nov '20

15 Nov '20

Hi. I have been using Lynx to read stuff on hacakge for a long time. I recently noticed that it is no longer possible to read the source of a module, because extra type information (which is likely hidden in a modern browser) is inline with the actual sources. This makes the go to source feature effectively useless. An example (from the ISBN package): deriving (Int -> ISBN -> ShowS [ISBN] -> ShowS ISBN -> String (Int -> ISBN -> ShowS) -> (ISBN -> String) -> ([ISBN] -> ShowS) -> Show ISBN forall a. (Int -> a -> ShowS) -> (a -> String) -> ([a] -> ShowS) -> Show a showList :: [ISBN] -> ShowS $cshowList :: [ISBN] -> ShowS show :: ISBN -> String $cshow :: ISBN -> String showsPrec :: Int -> ISBN -> ShowS $cshowsPrec :: Int -> ISBN -> ShowS Show, ISBN -> ISBN -> Bool (ISBN -> ISBN -> Bool) -> (ISBN -> ISBN -> Bool) -> Eq ISBN forall a. (a -> a -> Bool) -> (a -> a -> Bool) -> Eq a /= :: ISBN -> ISBN -> Bool $c/= :: ISBN -> ISBN -> Bool == :: ISBN -> ISBN -> Bool $c== :: ISBN -> ISBN -> Bool Eq) I know Haskell has a ton of extensions, but I am pretty sure nobody writes code like this :-) This is, frankly, pretty horrible. Can something be done to fix this? (I am aware that certain modernisations are unstoppable. However, this one looks like a bug.) -- CYa, ⡍⠁⠗⠊⠕

2 1

Generic Sorting
by Henry Laxen 15 Nov '20

15 Nov '20

Good evening Haskellers. I've done some searching but so far haven't found anything, which make me think this probably isn't possible. I am wondering if it is possible to do a "Generic Sort" on multilevel data structures. Suppose you have something like: data A = A Int [Int] data B = B Int [A] a1 = A 2 [2,1] a2 = A 1 [4,3] b = B 1 [a1,a2] genericSort b = B 1 [A 1 [3,4], A 2 [1,2]] note that not only are the A's sorted, but the list inside each A is sorted. It "sorted all the way down". Has Edward written such a thing yet? ;-) His "discrimination" library doesn't do this, in case you're wondering. Any ideas? Best wishes, Henry Laxen

3 3

support for ergonomic dependent types
by Richard Eisenberg 14 Nov '20

14 Nov '20

Hi all, The GHC Steering Committee has been struggling recently to decide on several related proposals. The struggle is all around whether we should favor making a design that is future-compatible with dependent types, or favor a design that is more cohesive with e.g. Haskell98. (Sometimes, we can have both. Those are good times.) This isn't about backward compatibility -- the design for dependent Haskell is fully backward compatible with Haskell98. It's more about how well the new features fit with the old ones. To clarify our thinking on it all, I've made a new proposal to discuss whether or not we want to favor keeping an avenue open to ergonomic dependent types in the future. If you have an opinion, please express it on the proposal. In particular, if you care about the possibility of ergonomic dependent types in Haskell, now is the time to show that support by thumbs-upping the proposal. The proposal is at https://github.com/ghc-proposals/ghc-proposals/pull/378. Thanks! Richard

1 0

Re: [Haskell-cafe] What to call Occult Effects
by Olaf Klinke 14 Nov '20

14 Nov '20

> First, instead of `const id` I will use `const`, that is, we shall > prove > > const = liftM2 const :: M a -> M b -> M a > > which I believe should be equivalent to your property. My belief was wrong, which is evident when using do-notation. Kim-Ee stated do {_ <- b; x <- a; return x} = a while I examined do {x <- a; _ <- b; return x} = a Since do {x <- a; return x} = a holds for any monad, Kim-Ee's property can be reduced to do {_ <- b; a} = a or more concisely b >> a = a which I called Kleisli-const in my previous post. As we seemed to have settled for "occlusive" I suggest calling b >> a = a "right-occlusive" or "occlusive from the right" because the right action occludes the side-effects of the left action, and do {x <- a; _ <- b; return x} = a should be called "left-occlusive" or "occlusive from the left" because the left action hides the effect of the right action. Under commutativity, both are the same but in general these might be different properties. I do not have a distinguishing counterexample, though, because all monads I come up with are commutative. David Feuer hinted at the possibility to define occlusiveness more generally for Applicative functors. Commutativity might be stated for Applicatives as liftA2 f a b = liftA2 (flip f) b a So far I can only see two classes of occlusive monads: The reader-like (Identity ~ Reader ()) and the set-like monads. Olaf

3 4

Advent of Haskell is still waiting for ideas
by Ida Bzowska 14 Nov '20

14 Nov '20

Hi there, Advent of Haskell is an advent calendar filled with Haskell content, obviously :) The first confirmations to "Advent of Haskell" participants' have been sent this week, but there are still a lot of open spots to go, so do not hesitate to submit your idea. All the details are available here: https://adventofhaskell.com Happy haskelling everyone! λCheers, Ida

1 0

caching ~/.cabal with github actions on windows
by Ben Franksen 13 Nov '20

13 Nov '20

I can't get this to work. It works perfectly fine on Linux and MacOS but on Windows cabal always re-builds all the dependencies. The cache post-action on Windows tells me that the cache hasn't changed, which means cabal actually re-created the ~/.cabal directory exactly as it was in the cache! Is this a known bug in cabal on Windows? Does anyone have a work-around? Cheers Ben

3 6