- Libraries - Haskell.org

Re: Deprecate Foldable for Either
by Artyom Kazak 19 Mar '17

19 Mar '17

On 20 Mar 2017 1:31 a.m., "Tony Morris" <tonymorris(a)gmail.com> wrote: "But the inconsistency with my intuition for the function named l-e-n-g-t-h that I learned in C programming school in the 1980s" is the best criteria that I have seen, and which commands outright dismissal. This is exactly my criterion (except that I learned English, not C), and I do not agree with you that it "commands outright dismissal". There is value in functions being as general as possible, etc, but there is also value in conforming to human intuitions – because it prevents people from shooting themselves in their feet. Whether those intuitions come from math, or from C, or from English, or elsewhere, is entirely irrelevant. If behavior of `length` fully conforms to your intuitions, that's splendid and you're lucky; however, for me and my usecases it's *only* a source of pain, and I want a way to free myself of that pain (without having to learn another language or spend time trying to change my intuitions). Wanting to make one's life easier is not an unreasonable desire.

3 4

Deprecate Foldable for Either
by Andreas Abel 19 Mar '17

19 Mar '17

Today a student came to me wondering why a certain function produced a regular result, where he had expected an error. Turned out he had used `concat`, but not on a lists of lists as he had thought, but on a lists of `Either a [b]`. With the Foldable instance for Either, which considers Either a b to be a container of 0-1 elements of b, errors are happily swallowed. I think this instance is harmful and should be deprecated (and later removed) from base. There are similarly pointless Foldable instances as well. See a discussion one year ago, which was heated, but had no consequences. https://mail.haskell.org/pipermail/libraries/2016-February/026678.html -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www.cse.chalmers.se/~abela/

24 63

Re: Deprecate Foldable for Either
by Artyom Kazak 19 Mar '17

19 Mar '17

On 20 Mar 2017 3:31 a.m., "Tony Morris" <tonymorris(a)gmail.com> wrote: What intuition exactly? Demonstrate it to me so that I may empathise with it. What pain? Show it to me. Are you sure it's intuition and not something else? How are you so sure? Okay, I have to admit that in this particular instance it's not quite my intuition which causes the pain. Or rather, it's a different kind of intuition, which I have acquired from Haskell in particular – "I don't have to be particularly careful about minor refactorings, because if I change the type of one thing, the compiler will tell me what other things I have to change if I want to preserve the logic of my code". The behavior of 'length' breaks this intuition because "I'll just pass a tuple here instead of whatever I used before" stops being a (relatively) safe refactoring. (I'm saying "relatively" because of the existence of other extremely polymorphic things – e.g. 'Aeson.encode'. Luckily, they're much less common than 'length'.) (An example of a scenario which more closely fits what I originally had in mind: Set.size is O(1), but HashSet.size is O(n) – this one was pretty fun to hunt down when we found that our code was unexpectedly slow. Unfortunately, I can not adequately expand the intuition behind my initial judgment of "HashSet.size is surely fast", because it's hard to do at 4am.) The pain is pretty easy to demonstrate: I had to waste a day recreating the Foldable/Traversable hierarchy in a custom prelude to ensure that nobody in my team would be bitten by a refactoring. It wasn't *that* painful, sure – but it's somewhat scary to think that there might be dozens of other refactor-unfriendly functions lurking in libraries we're using (and one day they will come to bite us).

1 0

Q Monad State
by Ethan Pailes 11 Mar '17

11 Mar '17

Hi, I've been working on PADS with Kathleen Fisher for the past couple of months, and we have some questions about the Q Monad. In working on extending the PADS language, we have encountered a need to maintain a type environment across invocations of the [pads||] quasi quoter. This allows PADS types to be defined in one quote block and used in a later quote block. Unfortunately, the right way to do this is not obvious from the Q Monad’s interface[1]. The monad provides `qGetQ` and `qPutQ` methods to provide a place to store state across quotes, but unfortunately this state is local to each module. It is desirable from a usability perspective to be able to reuse PADS declarations across modules, but in the particular case of PADS the problem is actually worse than that. PADS ships with a standard library module which uses PADS to define several of the core types required to be productive, so without the ability to do type checking across modules the use of this standard library becomes impossible. There are two solutions to the problem that we have considered. 1. We can generate metadata about each type as it is defined and emit a top level declaration which contains this metadata. 1. This clutters the global namespace. 2. It lets you examine the metadata for each type easily in `ghci` which leads to a nice debugging workflow. 3. If you want to perform any typechecks or other calculations based on the metadata, they must happen after generated code is spliced in. 1. This means you lose a lot of type safety because everything must be represented as an `Exp` (even with typed template haskell there is no way to get a type for an `Exp` of the form `VarE <<name of metadata>>`) 2. It becomes impossible to report type errors at compile time. This is a dealbreaker because otherwise, what is the point? 2. Using `unsafePerformIO` to create an IORef and then using the Q Monand’s `qRunIO` function to access the state cell. 1. This works smoothly across modules 2. You get type safety back because everything happens in the Q Monad. You don’t have to generate code in order to get at the values. 3. It uses `unsafePerformIO` and `qRunIO` so you have to worry about how often everything gets run. 1. It seems like it should be safe with a {-# NONINLINE #-} pragma for the code which creates the IORef. 2. The IORef is hidden, and no one else should be able to modify it. 3. Adding stuff to a `Data.Map.Strict` (the environment implementation we are using) is idempotent, so the quote code getting run multiple times should not be an issue. We have two main questions based on this. 1. Is the IO (ab)use outlined above really as safe as we think it is? 2. Given that environments are such a common requirement in compiling programming languages, and the goal of quasi quotation is allowing easy creation of EDSLs for Haskell, does it make sense to provide some state mechanism for the Q monad which is not restricted by modules. [1]: https://hackage.haskell.org/package/template-haskell-2.11. 1.0/docs/Language-Haskell-TH-Syntax.html Thanks, Ethan Pailes

2 4

Re: Proposal: flipped fmap in base (again)
by Ryan Scott 10 Mar '17

10 Mar '17

+1 from me as well on including (<&>) in base. I wouldn't object to adding ffor either, if folks with find that useful. Ryan S.

1 0

Proposal: flipped fmap in base (again)
by Siddhanathan Shanmugam 10 Mar '17

10 Mar '17

This was proposed about 7 years ago, and rejected at the time: https://ghc.haskell.org/trac/ghc/ticket/3962 Is it okay if I revive this argument now? I think it would be useful to have the lens operator <&> in base, which is defined as: (<&>) :: Functor f => f a -> (a -> b) -> f b as <&> f = f <$> as This is analogous to a lifted version of (&) that already present in Data.Function Cheers, Sid

9 17

Alternative.some and NonEmpty
by Vladislav Zavialov 08 Mar '17

08 Mar '17

Since 'Data.List.NonEmpty' is now in 'base', it makes sense to change the type of 'some' from some :: Alternative f => f a -> f [a] to some :: Alternative f => f a -> f (NonEmpty a) as it's guaranteed to return a non-empty list. Currently, both users and implementors of 'Alternative' instances are at a disadvantage. The users have to use the unsafe NonEmpty.fromList function to take advantage of the fact that the result of 'some' is indeed non-empty. The implementors have more space for error - it's possible to accidentally return an empty list. I volunteer to implement. Does everyone agree it's a good idea?

9 15

Re: Deprecate Foldable for Either
by dominic＠steinitz.org 06 Mar '17

06 Mar '17

Is anyone arguing that this is acceptable? > On 5 Mar 2017, at 10:32, libraries-request(a)haskell.org wrote: > > sum ([1,2,3], 1) == 1 On another note, the change that allowed this has brought discord to a previously harmonious community. I for one regret this. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

2 1

Proposal: modify `Read` instances for `Float` and `Double`
by Iavor Diatchki 05 Mar '17

05 Mar '17

Hello, I am working on a small GHC extension to support floating point literals in hexadecimal notation (https://github.com/ghc-proposals/ghc-proposals/pull/37) which is similar to what's available in other languages. To support this change, I would like to propose that we modify the `Read` instances for `Float` and `Double` to parse literals in the new notation. This may affect existing programs---although it doesn't seem very likely. Here is an example: current behavior: reads "0x10p10" = [(16.0,"p10")] new behavior: reads "0x10p10" = [(16384,"")] What do people think? -Iavor

6 7

Re: [Haskell-cafe] Inlinable (>>>)
by Joe Hillenbrand 03 Mar '17

03 Mar '17

CCing Libraries On Thu, Mar 2, 2017 at 7:18 AM, David Sorokin <david.sorokin(a)gmail.com> wrote: > Hi Cafe, > > I offer to define the functions of the Control.Category module inlinable: > > -- | Right-to-left composition > (<<<) :: Category cat => cat b c -> cat a b -> cat a c > {-# INLINABLE (<<<) #-} > (<<<) = (.) > > -- | Left-to-right composition > (>>>) :: Category cat => cat a b -> cat b c -> cat a c > {-# INLINABLE (>>>) #-} > f >>> g = g . f > > Perhaps all functions from this module should be marked by this pragma as possible. > > I suppose that the current definition without the pragma is the cause why the execution slows down in my applications, when using monad parameters in the constraints. I noticed it yet two or three years ago, while playing with the monad transformers, but decided to write now. > > Best regards, > David Sorokin > > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0