October 2021 - Haskell-Cafe

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

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

06 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 05 Oct '21

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

05 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

Massaging data from the `extensible` package
by Ruben Astudillo 05 Oct '21

05 Oct '21

Hello cafe I have been enjoying the `extensible` package [1] for extensible records and variants, kudos to the author. I have had a problem of not understanding how to "massage" data from one representation to another. To exemplify, suppose I have the following two extensible records {-# language OverloadedLabels #-} import Data.Extensible import Control.Lens type Ext1 = Record '[ "field1" >: String, "field2" >: Integer ] type Ext2 = Record '[ "field1" >: Text, "field2" >: Double ] and I want to map some piece of data between these two types. Currently I am projecting each field individually like this ex1 :: Ext1 ex1 = #field1 @= "hello" <: #field2 @= 2.71 <: nil currentMap :: Ext1 -> Ext2 currentMap s = #field1 @= T.pack (view #field1 s) <: #field2 @= fromInteger (view #field2 s) <: nil For data types with few fields it is not so bad. But I have to do this transformation of data types generated from TH, I am dealing with a few dozens. The transformations are always from `String -> Text` and `Integer -> Double`. I would like to write a high lever combinator that grabs an extensible record, transforms each `String` field on a `Text` one and does the same with `Integer -> Double`. Most of the combinators for transforming the data deal with natural transformations, such as hmap, hsequence and the like. The closest one to what I want is `hfoldMapFor` where I have to define a class with instances for all the types the extensible record has, but it doesn't let me change the type of the result. Does anyone have an idea on how to solve this? Thanks for your time. [1]: https://hackage.haskell.org/package/extensible -- Rubén. (pgp: 4EE9 28F7 932E F4AD)

3 5

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

05 Oct '21

> GHC's use of a State-like monad to represent I/O is semantically bogus, .... I wouldn't take it as a good mental model. Indeed. I fondly remember that in my intro text (the 'Gentle Introduction'), there was a warning this section is not so gentle. But I was already well through the book so it didn't seem such a drama. I'd already figured that 'mentally evaluating' code wasn't about contents of memory locations. For Monads esp I/O, 'programmable semicolon' or 'workflow' might be a better model. Ref the current discussion, I'm expecting a learner would spend a long time writing expressions at the ghci prompt; investigating their type; chucking in a few in-line decls with `let { }`. Dropping those decls into a source file -- which would contain only decls, not even a `module { }` header. A few simple `do{ ; }` blocks at the prompt. I was advocating lambda-calculus for the pure function evaluation parts of an intro. Higher-order functions, partial evaluation, operator sections, (un)currying. The o.p. was having trouble with a signature like `(a -> b -> c) -> a -> b -> d`. Later remarks expressed surprise why function application wasn't written `add(x, y)`. The (very old) paper mentioned was nearly all pure code. Without a firm basis grokking type signatures, the Monad operators are going to seem deeply weird. If you're used to 'higher-order function' meaning something that passes round an entry point for a block of code, partial application will take some head-scratching. And I can see if you're used to `x ++` meaning something and `x+=1` meaning something similar and `* y` meaning something completely different and `(x +)` being a syntax error, Haskell is going to feel strange. (Aside: to this day, that sort of ad-hoc syntax makes me gag. K&R should be publicly flogged on a regular basis. Why couldn't they just follow the model of BCPL, which is far more elegant and consistent in its syntax. They stole nearly everything else from BCPL.) Which reminds me ... My all-time favourite language intro text is still http://rabbit.eng.miami.edu/info/bcpl_reference_manual.pdf This serves also as a language definition.This was thrown at undergrads, and they were left to get on with it. (There was also a 'User Guide' that talked about the operating environment, debugging, IO and file handling -- essentially equiv to Haskell's Appendixes on the base modules.) I note again, the language is small and elegant (expressible in A5 minimanual format). Similarly, you can get enough of lambda-calculus on a few sheets of A4. I contrast that 'Category Theory for Programmers' (mentioned in this thread) is 500 pages, and not even a language primer, although it contains snippets of code. How many hundred pages must I read before I'm allowed to write a Foldable instance? I'm up to 100, and we seem to be still preparing the ground for what is an endomorph.

4 5

Vectors, vector spaces and type-level Haskell
by Stuart Hungerford 04 Oct '21

04 Oct '21

Greetings Haskellers, I'd like to model in Haskell two-dimensional vectors that "belong to" or "have an ambient space of" a two dimensional vector space. I'm also ignoring for now the issue of which field the vector space is over. I realize this is not strictly necessary to just start using 2D vectors, but I would like to bring the vector space in as a first class concept. Looking at for example this approach: https://hackage.haskell.org/package/linear-1.21.7/docs/Linear-V2.html, I get the impression this is likely to need some kind of type-level construct? e.g. type families or type-level literals? I haven't started learning yet about Haskell type-level programming so I thought I'd ask for advice first to see how this could be done idiomatically in Haskell either with or without type-level concepts. TIA, Stu

4 11

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 218, Issue 5
by Stuart Hungerford 04 Oct '21

04 Oct '21

On Mon, Oct 4, 2021 at 11:10 PM <haskell-cafe-request(a)haskell.org> wrote: > [...] > The V2 and V3 etc. types provided by the linear package (which you > already found) model vectors in 2- and 3-dimensional real vector spaces, > over the field given by their 'a' type parameter. Wanting to add a > vector from a 2-dimensional vector space over 'a' and a vector from a > 3-dimensional vector space over 'b' entails adding a 'V2 a' and 'V3 b'; > those are distinct types. The vector space of 'V2 a' is morally 'a^2'. > > It seems this satisfies what you want. Are there other guarantees you > want enforced at compile time that this cannot give you? Thanks Tom -- you're right this is enough for compile time guarantees. This need to encode dimensionality into a type seems to be a compelling use-case for type-level numbers or other type-level capabilities (which I've avoided learning about until now). Stu

1 0