- Haskell-Cafe - Haskell.org

[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 09 Oct '21

09 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 08 Oct '21

08 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 08 Oct '21

08 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

Re: [Haskell-cafe] Terminator syntax style (Was: Nested (=>) (Was: On finding the right exposition...))
by Douglas McIlroy 07 Oct '21

07 Oct '21

>> Could you say what "terminator syntax style" is? I'm not finding any >> hits on popular search engines. > https://wiki.haskell.org/Terminator_vs._separator Apropos of "finding the right exposition", consider this definition in the cited wiki article: Separator: There is a symbol between each element. The more carefully you read this the more it becomes nonsense. 1, "Each element" is an individual. You can't put something between an individual. 2 The defining sentence states a property of a representation of a sequence. It fails to indicate that "separator" is the symbol's role. In fact what's being defined is "separator notation", not the bare word "separator". The proper usage appears only later in the article. It should be employed throughout--most importantly in the title and the definition. The same goes for "terminator". Doug

1 0

Re: [Haskell-cafe] mine sockets lib vs yesod
by Branimir Maksimovic 07 Oct '21

07 Oct '21

> On 27.09.2021., at 12:13, Mikolaj Konarski <mikolaj.konarski(a)gmail.com> wrote: > > Hi Branimir, > >> I guess that if I port it to Haskell purely from CPP, I won’t have problems with copyright? > > I will retain exactly the same copyright it had. To get rid of the old > copyright, you'd need to clean-room re-implement it (you yell ideas > from another room and somebody implements them in Haskell not having > seen the CPP code beforehand). OK. > >> if using -threaded performance is *worse*. > > This is normal. You trade performance for the ability to pre-empt > (e.g., not get stuck on blocking FFI). > > Kind regards, > Mikolaj I will implement it whole in Haskell, in async fashion as it seems with current hardware bandwith is saturated with just single CPU/Core. Greettings, Branimir.

1 1

Rank2Types in let bindings
by Olaf Klinke 06 Oct '21

06 Oct '21

Dear Cafe, apologies if this is a duplicate question. I want to define an element of a Rank-2 type, use its specialization and then return the general thing. Apparently this is not possible without a newtype. {-# 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

2 1

Re: [Haskell-cafe] On finding the right exposition...
by Anthony Clayden 06 Oct '21

06 Oct '21

> ... I never understood why (->) is right associative in types, but (=>) is not and you are instead supposed to pack constraints in a tuple. `-XRankNTypes` enables something called Rank 1 types, which accepts this: > foo :: Ord a => Num b => a -> Show b => b > -- foo :: (Ord a, Num b, Show b) => a -> b -- inferred/canonical We should also have: > bar :: forall a. forall {- empty -}. forall b. blah > -- bar :: forall a b. blah -- equivalent But `PatternSynonyms` drives a cart and horses through that: you must have exactly 2 `... => ... => ...` and exactly 2 `forall`s (possibly empty) -- that is, if you explicitly quantify at all. Or you can go: > MyPat :: Num a => a -> Baz a -- which is shorthand for > MyPat :: Num a => () => a -> Baz a -- which is equiv to > MyPat :: Num a => Num a => a -> Baz a > MyPat :: () => Num a => a -> Baz a -- this means something different

2 1

Re: [Haskell-cafe] On finding the right exposition
by Douglas McIlroy 05 Oct '21

05 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. > And for so many other reasons, too, like mandating a preprocessor (with > a complex, operationally defined semantics) simply because they couldn't > be bothered to design a (simple, 1st order) module system. Manners, please. Such immoderate words have no place on this mailing list. Doug

1 0