- Haskell-Cafe - Haskell.org

Bug in Data.Bits.shift?
by Keith 17 Oct '21

17 Oct '21

As currently defined, `shift x minBound` calls `shiftR` with a negative displacement. This would avoid that: ``` shift x n | n >= 0 = shiftL x n | n == minBound = shiftR (shiftR x maxBound) 1 | otherwise = shiftR x (-n) ``` P.S. Philosophically, `rotate` on a negative `Integer` should do sign extension in the least significant bits (though by the description of `rotate` it should not...). — Sent from my phone with K-9 Mail.

3 3

Resources on how to implement (Haskell 98) kind-checking?
by Benjamin Redelings 16 Oct '21

16 Oct '21

Hi, 1. I'm looking for resources that describe how to implement kind Haskell 98 checking. Does anyone have any suggestions? * I've looked at the PolyKinds paper, but it doesn't cover type classes. * I've looked at the source code to GHC, but it is hard to follow for a variety of reasons. It isn't laid out like an algorithm description, and the complexity to handle options like PolyKinds and DataKinds makes the code harder to follow. 2. One question that came up is how to handle type variables that are present in class methods, but are not type class parameters. If there are multiple types/classes in a single recursive group, the kind of such type variables might not be fully resolved until a later type-or-class is processed. Is there a recommended approach? I can see two ways to proceed: i) First determine the kinds of all the data types, classes, and type synonyms. Then perform a second pass over each type or class to determine the kinds of type variables (in class methods) that are not type class parameters. ii) Alternatively, record the kind of each type variable as it is encountered -- even though such kinds may contain unification kind variables. After visiting all types-or-classes in the recursive group, replace any kind variables with their definition, or with a * if there is no definition. I've currently implement approach i), which requires doing kind inference on class methods twice. Is this the recommended approach? 3. Also, is Haskell 98 kind checking the same as Haskell 2010 kind checking? -BenRI

8 12

Public floggings
by Michael Turner 13 Oct '21

13 Oct '21

>> Aside: to this day, that sort of ad-hoc syntax makes me gag. K&R should be > publicly flogged on a regular basis. Since I'm to blame for raising the subject that turned into a thread about "the right exposition", I hereby surrender myself to be flogged in lieu of the intended. I've deserved it for years, just for how I've found perversely delightful ways to use the C preprocessor. Especially token-pasting. K&R (the book) was almost indecent exposure -- it left nothing to the imagination. As opposed to most writing on Haskell, where I'm befuddled because it's not at all obvious how it does its thing. It's like you're not /supposed/ to know. But K&R let it all hang out, and for that reason, I loved it. Whip me, beat me, make me write C code. Because that's just the kind of pervert I am. Still, sometimes. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry

2 1

[ANN] linear-generics
by David Feuer 12 Oct '21

12 Oct '21

I am pleased to announce the release of a new package, linear-generics[*], based on GHC.Generics and the venerable generic-deriving. The killer features: 1. Generic1 representations associate compositions the right way around, which is to say the *left* way around, meaning no more inefficient fmaps or pesky Functor constraints. 2. to, from, to1, and from1 are multiplicity polymorphic, so you can use them in all your fancy new linearly typed code. The package includes Template Haskell-based deriving, based closely on generic-deriving, which is the recommended way to write instances. There is also a limited, somewhat unsafe, and somewhat inefficient way using provided DerivingVia targets. Many thanks to Arnaud Spiwack and Ryan Scott for valuable advice and assistance. [*] https://hackage.haskell.org/package/linear-generics

1 0

Partially applied type synonyms
by Ttt Mmm 09 Oct '21

09 Oct '21

I was surprised to find the below code doesn't typecheck even with -XLiberalTypeSynonyms. Am I missing something or is this really not possible? Thanks, Tom --- {-# LANGUAGE FlexibleInstances, KindSignatures, LiberalTypeSynonyms, StandaloneDeriving #-} -- This works: data Foo s x = Foo (s x) x deriving (Eq) -- This replacement doesn't: {- data Foo' sx x = Foo' sx x deriving (Eq) type Foo (s :: * -> *) (x :: *) = Foo' (s x) x -} data Bar (m :: * -> *) = Bar (m Int) -- Neither of these typecheck: x :: Bar (Foo Maybe) x = undefined deriving instance Eq (Bar (Foo Maybe))

3 6

[ANN] Cabal-3.4.1.0, cabal-install-3.4.1.0, Cabal-3.6.2.0, and cabal-install-3.6.2.0
by Emily Pillmore 08 Oct '21

08 Oct '21

Hello Haskell, The Cabal team is excited to announce the release of `Cabal-3.6.2.0`, and `cabal-install-3.6.2.0`. ## Changelog for `Cabal-3.6.2.0` and `cabal-install-3.6.2.0` This is the fifth release of the 3.0 release series for both packages. This minor version release introduces a set of fixes for some regressions seen when the tool interacts with `autoconf`, as well as some fixes for regressions to the way Paths_ modules interact with non-standard preludes: - Making Paths_ modules work with non-standard preludes again [#5962]( https://github.com/haskell/cabal/issues/5962 ) - Generate Paths_ module with qualified Data.List.last import so that compatibility with non-standard preludes is not regressed compared to cabal 3.4. - Windows: redo the fix to breakage caused by new autoconf; the wrong fix made cabal sometimes fail with old autoconf [#7494]( https://github.com/haskell/cabal/issues/7494 ) [#7649]( https://github.com/haskell/cabal/issues/7649 ) - Reverts #7510 that failed on Windows when used with pre-generated scripts included in packages such as network, time, process. - Adds a subtler fix/workaround for the deficiencies of new autoconf versions on Windows. **IMPORTANT NOTE**: The last bug affects configuration files generated with `autoconf-2.70` or later. They will not work with `cabal-3.4.0.0`. Please either upgrade to `3.4.1.0` or the new `3.6.2.0` releases. I'd like to thank the many contributors who offered patches, tickets, and other help in the preparation of this release. We appreciate all of your help! Happy hacking!

1 0

Examples of Continuation monad that impossible to understand and maintain?
by YueCompl 08 Oct '21

08 Oct '21

Dear Cafe, I'm wrapping up my CPS codebase to provide some monadic interface, it appears almost the Cont monad, so the following statement is a pretty valid caveat to me now: > Abuse of the Continuation monad can produce code that is impossible to understand and maintain. Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:tex… <https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:tex… of the Continuation monad can produce code that is impossible to understand and maintain> But I can't find concrete examples demonstrating the "impossible to understand and maintain" situation, in figuring out what pitfalls I'd rather to avoid. Please share what you know about it, many appreciations! Background of my CPS necessarity: Library code need to delegate STM transaction boundary delimitation to (scripting) application code, though `inlineSTM :: STM a -> m a` can be used to force some action to be within current tx, the usual `>>=` binding should honor whether a separate `atomically` tx should be issued for its rhs computation, as specified by the scripting context. Thanks, Compl

4 8

Re: [Haskell-cafe] Partially applied type synonyms
by Anthony Clayden 08 Oct '21

08 Oct '21

> I was surprised to find the below code doesn't typecheck even with -XLiberalTypeSynonyms. Am I missing something or is this really not possible? Reading the error message would help: * The type synonym `Foo' should have 2 arguments, but has been given 1 -XLiberalTypeSynonyms relaxes the 'saturated application' rule a little https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/liberal_type_synony… "You can apply a type synonym to a partially applied type synonym:" But that isn't what you're doing. The docs say that still " ... malformedness ... * Partially-applied type synonym." Type Synonyms are not functions. Think of them as 'macro' expansions. Possibly your `Bar` could be a type synonym, taking `(Foo Maybe)` as an argument in the `instance Eq`. What type is it exactly that you want to derive an instance for?

2 1

Re: [Haskell-cafe] Public floggings
by Anthony Clayden 07 Oct '21

07 Oct '21

> how I've found perversely delightful ways to use the C preprocessor. Especially token-pasting. Then boy! do I have an offer for you/you'll be like a pig in muck. There's a Haskell compiler written in C++, using all the tricks you love: * #define nested inside #if, so you're never quite sure which version of a macro is in play. * #defines that expand to a series of assignments and routine calls. * Module-wide and global variables that get updated as side-effects of routine calls (as well as those routines passing back results) * All data structures being cons pairs deeply nested, typically routines poke into hd(hd(tl(e))) or some such. Someone's generously put the source online https://github.com/FranklinChen/hugs98-plus-Sep2006/tree/master/src You can load it up into Visual Studio, and produce a genuine Windows executable with a Haskell REPL. (Ah, silly me, of course you'd want the familiar *nix command line -- that's even easier.) And there's real work you could contribute to https://mail.haskell.org/pipermail/hugs-bugs/2021-October/thread.html Enjoy!

1 0

Monomorphism restriction [Was: Rank2Types in let bindings]
by Olaf Klinke 07 Oct '21

07 Oct '21

> > {-# LANGUAGE RankNTypes #-} > > newtype General = General { > > useGeneral :: forall a. Integral a => a -> Bool > > } > > > > doesNotWork :: General > > doesNotWork = let > > g = even :: forall a. Integral a => a -> Bool > > b = specializeGeneral g > > in General g > > > > doesWork :: General > > doesWork = let > > g = General even > > b = specializeGeneral (useGeneral g) > > in g > > > > specializeGeneral :: (Int -> Bool) -> Bool > > specializeGeneral p = p 5 > > > > I was under the impression that one can always use a more general type > > where a more special type is needed. In `doesNotWork` above, despite the > > explicit Rank-2 type annotation, usage in `specializeGeneral` apparently > > makes the compiler infer the type of `g` to be (Int -> Bool) and > > complains that `a` can not me matched with `Bool`. What gets me is that > > the compiler error is at `General g`, so the compiler must have ignored > > my Rank-2 type annotation. Should it be allowed to do that? > > > > Olaf > > Hi Olaf, > > This is the monomorphism restriction. g is a binding without a > signature, so it gets specialized. The type annotation is part of the > body of g, but if you want to generalize g it should be a separate > declaration > > let g :: forall ... > g = ... > Oh, thanks! I should have suspected. But somehow I feel my type annotation should have circumvented the monomorphism restriction. So g = even is a pattern binding and therefore subject to monomorphism restriction, regardless of following type annotation? So thanks for teaching me that it is not irrelevant where to place a type annotation. To this day I believed that name = expression :: type and name :: type name = expression are equivalent because one is syntactic sugar for the other. Do the two give rise to different elements in the abstract syntax tree? Am I the only one who finds this odd? Which Haskell book should I have read to be aware of this? The Consequences part in Section 4.5.5 of the Haskell report mentions the distinction between function an pattern bindings, but is not clear about the position of the type annotation. It merely states "the user must be careful to affix these [pattern bindings] with type signatures to retain full overloading". Olaf

2 1