From frederic-emmanuel.picca at synchrotron-soleil.fr Tue Mar 1 10:54:02 2022 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Tue, 1 Mar 2022 11:54:02 +0100 (CET) Subject: [Haskell-cafe] generic way to construct and deconstruct a newtype Message-ID: <738751892.14566907.1646132042309.JavaMail.zimbra@synchrotron-soleil.fr> Hello, I try to write some code use to parse an ini file for one of my softwares, using config-ini[1]. In this config file I have scientific values with units, meter, angstrom, degrees, etc... So I created a bunch of newtype in order to deal with this part of the config file newtype Meter = Meter (Length Double) deriving (Eq, Show) newType Angstrom = Angstrom (Length Double) [...] Then I created a typeclasse in order to have a generic way to extract the fileds values using the BiDir api [2] class HasFieldValue a where fieldvalue :: FieldValue a instance HasFieldValue Meter where fieldvalue = FieldValue { fvParse = mapRight (Meter . (*~ meter)) . fvParse auto , fvEmit = \(Meter m) -> pack . show . (/~ meter) $ m } instance HasFieldValue Angstrom where fieldvalue = FieldValue { fvParse = mapRight (Meter . (*~ angstrom)) . fvParse auto , fvEmit = \(Angstrom m) -> pack . show . (/~ angstrom) $ m } I would like to factorize via a method which should take at least an unit, in order to avoid repetition. I started with this sort of funtion, but I do not know how to write something generic for numberUnit :: (Num a, Fractional a, Read a, Show a, Typeable a) => Unit m d a -> FieldValue (Quantity d a) numberUnit u = FieldValue { fvParse = mapRight ( . (*~ u)) . fvParse number' , fvEmit = \( v) -> pack . show . (/~ u) $ v } thanks for your help [1] https://hackage.haskell.org/package/config-ini-0.2.4.0 [2] https://hackage.haskell.org/package/config-ini-0.2.4.0/docs/Data-Ini-Config-Bidir.html From lemming at henning-thielemann.de Tue Mar 1 11:09:35 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 1 Mar 2022 12:09:35 +0100 (CET) Subject: [Haskell-cafe] generic way to construct and deconstruct a newtype In-Reply-To: <738751892.14566907.1646132042309.JavaMail.zimbra@synchrotron-soleil.fr> References: <738751892.14566907.1646132042309.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: On Tue, 1 Mar 2022, PICCA Frederic-Emmanuel wrote: > Hello, I try to write some code use to parse an ini file > for one of my softwares, using config-ini[1]. > > In this config file I have scientific values with units, meter, angstrom, degrees, etc... > So I created a bunch of newtype in order to deal with this part of the config file > > newtype Meter = Meter (Length Double) > deriving (Eq, Show) > > newType Angstrom = Angstrom (Length Double) > > [...] I would define newtype Quantity dimension a = Quantity a or use one of the libraries for physical dimensions. Then I would convert all values to SI standard units, i.e. all lengths to meter. If you must preserve the units from the config file, I would instead define newtype Quantity dimension unit a = Quantity a From frederic-emmanuel.picca at synchrotron-soleil.fr Tue Mar 1 12:34:19 2022 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Tue, 1 Mar 2022 13:34:19 +0100 (CET) Subject: [Haskell-cafe] generic way to construct and deconstruct a newtype In-Reply-To: References: <738751892.14566907.1646132042309.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <438061248.14631473.1646138059071.JavaMail.zimbra@synchrotron-soleil.fr> > or use one of the libraries for physical dimensions. Then I would convert > all values to SI standard units, i.e. all lengths to meter. If you must > preserve the units from the config file, I would instead define I am already using the dimensional library, I need to check if I can use the low lovel Quantity definition in order to define the right instance. From frederic-emmanuel.picca at synchrotron-soleil.fr Tue Mar 1 12:52:55 2022 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Tue, 1 Mar 2022 13:52:55 +0100 (CET) Subject: [Haskell-cafe] generic way to construct and deconstruct a newtype In-Reply-To: <438061248.14631473.1646138059071.JavaMail.zimbra@synchrotron-soleil.fr> References: <738751892.14566907.1646132042309.JavaMail.zimbra@synchrotron-soleil.fr> <438061248.14631473.1646138059071.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <1795764503.14648237.1646139175296.JavaMail.zimbra@synchrotron-soleil.fr> If I look at the definition of an unit in dimensional I have this angstrom :: (Fractional a) => Unit 'NonMetric DLength a angstrom = mkUnitQ (ucum "Ao" "Å" "Ångström") 0.1 $ nano meter metre, meter :: Num a => Unit 'Metric DLength a metre = mkUnitZ I.nMeter 1 siUnit -- International English. meter = metre -- American English. So it seems thaht I can not differenciate angstrom and metter at the type level. From dyaitskov at gmail.com Tue Mar 1 17:56:02 2022 From: dyaitskov at gmail.com (Daneel Yaitskov) Date: Tue, 1 Mar 2022 12:56:02 -0500 Subject: [Haskell-cafe] order of assertEqual arguments is counterintuitive Message-ID: Hi List, I noticed, that I pay more attention than I should, when working with assertions, because I am not sure about argument order i.e. whether the expected value goes first or vice-versa. Does anybody have similar thought? Such subtle detail should be easy to grasp with regular practice, but I observe difficulties and I suspect that there is a logical reason for that. Unit tests appeared long time ago in Java and spread over all languages. HUnit library inherited de facto standard assert function name and signature. I don't know reasoning behind original signature. I spell "assertEqual" expression as: "Assert that x equals to y" "y" sounds like a model value (i.e. expected value). In assignments "x <- y" y is the model value, because it defines "x". You get "x" - value on the left not on the right. Similar issue with test fixing - I always have to check first, that an expected value is actually one. There is no type safety preventing mixing arguments. I had to open and comprehend a source file with test, because test log is not 100% safe. -- Best regards, Daniil Iaitskov -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Tue Mar 1 19:35:18 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 1 Mar 2022 14:35:18 -0500 Subject: [Haskell-cafe] order of assertEqual arguments is counterintuitive In-Reply-To: References: Message-ID: On Tue, Mar 01, 2022 at 12:56:02PM -0500, Daneel Yaitskov wrote: > I noticed, that I pay more attention than I should, when working with > assertions, because I am not sure about argument order i.e. whether the > expected value goes first or vice-versa. Does anybody have similar thought? The documentation is quite clear: https://hackage.haskell.org/package/HUnit-1.6.2.0/docs/Test-HUnit-Base.html#v:assertEqual > Such subtle detail should be easy to grasp with regular practice, but I > observe difficulties and I suspect that there is a logical reason for that. > > I spell "assertEqual" expression as: "Assert that x equals to y" > "y" sounds like a model value (i.e. expected value). As a combinator that can be curried, -- Check variable given against fixed wanted assertEqual prefix wanted :: (Eq a, Show a) => a -> Assertion is I think more useful than: -- Check variable wanted against fixed given. assertEqual prefix given :: (Eq a, Show a) => a -> Assertion > Similar issue with test fixing - I always have to check first, that an > expected value is actually one. There is no type safety preventing mixing > arguments. The test works either way of course, the only thing that changes is the error message on failure. You could implement a type-safe wrapper: newtype Given a = Given a newtype Wanted a = Wanted a checkEq :: (Eq a, Show a) => String -> Given a -> Wanted a -> Assertion checkEq prefix (Given x) (Wanted y) = assertEqual prefix y x Then always call via: checkEq "Oops" (Given (2 + 2)) (Wanted 5) -- Viktor. From leesteken at pm.me Tue Mar 1 19:50:17 2022 From: leesteken at pm.me (Arjen) Date: Tue, 01 Mar 2022 19:50:17 +0000 Subject: [Haskell-cafe] order of assertEqual arguments is counterintuitive In-Reply-To: References: Message-ID: On Tuesday, March 1st, 2022 at 18:56, Daneel Yaitskov wrote: > Hi List, > > I noticed, that I pay more attention than I should, when working with assertions, because I am not sure about argument order i.e. whether the expected value goes first or vice-versa. Does anybody have similar thought? > > Such subtle detail should be easy to grasp with regular practice, but I observe difficulties and I suspect that there is a logical reason for that. > > Unit tests appeared long time ago in Java and spread over all languages. HUnit library inherited de facto standard assert function name and signature. I don't know reasoning behind original signature. > > I spell "assertEqual" expression as: "Assert that x equals to y" > > "y" sounds like a model value (i.e. expected value). > > In assignments `"x <- y"` y is the model value, because it defines `"x"`. > > You get `"x"` - value on the left not on the right. > > Similar issue with test fixing - I always have to check first, that an expected value is actually one. There is no type safety preventing mixing arguments. I had to open and comprehend a source file with test, because test log is not 100% safe. I think it is common in Haskell to have the most reusable argument(s) first. Like in this case: shouldBeFour = assertEqual "" 4 assert1 = shouldBeFour (2 + 2) assert2 = shouldBeFour (2 * 2) But styles, like people, may vary between libraries. From hecate at glitchbra.in Tue Mar 1 22:06:32 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Tue, 1 Mar 2022 23:06:32 +0100 Subject: [Haskell-cafe] order of assertEqual arguments is counterintuitive In-Reply-To: References: Message-ID: <77690a66-8291-3e66-7adf-fc10fc539015@glitchbra.in> I have also been bitten by this order, but I can also blame myself for not reading the documentation and relying on my previous experience with other libraries, thus building an intuition that I believed was universal (when it was in fact not). I don't think it's worth much arguing about the order of things or the "intuition" at play here, since fortunately this library comes with a manual. Very few software match our mental expectations, and even the one we write are specifically tailored for our selves of a given time and place. And as we all know, we are a stranger to our future selves. Cheers Hécate Le 01/03/2022 à 18:56, Daneel Yaitskov a écrit : > Hi List, > > I noticed, that I pay more attention than I should, when working with > assertions, because I am not sure about argument order i.e. whether > the expected value goes first or vice-versa. Does anybody have similar > thought? > > Such subtle detail should be easy to grasp with regular practice, but > I observe difficulties and I suspect that there is a logical reason > for that. > > Unit tests appeared long time ago in Java and spread over all > languages. HUnit library inherited de facto standard assert function > name and signature. I don't know reasoning behind original signature. > > I spell "assertEqual" expression as:  "Assert that x equals to y" > "y" sounds like a model value (i.e. expected value). > > In assignments |"x <- y"| y is the model value, because it defines |"x"|. > You get |"x"| - value on the left not on the right. > > Similar issue with test fixing - I always have to check first, that an > expected value is actually one. There is no type safety preventing > mixing arguments. I had to open and comprehend a source file with > test, because test log is not 100% safe. > > > > -- > > Best regards, > Daniil Iaitskov > > > > > _______________________________________________ > 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. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Mar 1 22:48:13 2022 From: david.feuer at gmail.com (David Feuer) Date: Tue, 1 Mar 2022 17:48:13 -0500 Subject: [Haskell-cafe] order of assertEqual arguments is counterintuitive In-Reply-To: References: Message-ID: I think newtypes are awkward here. Better to use a record to get "named arguments": data ExpAct a = ExpAct { expected :: a , actual :: a } assertSame :: HasCallStack => (Eq a, Show a) => String -> ExpAct a -> Assertion assertSame s ExpAct{expected=e, actual=a} = assertEqual s e a Now you can write things like assertSame "whatever" ExpAct{expected=4, actual=x} On Tue, Mar 1, 2022, 2:38 PM Viktor Dukhovni wrote: > On Tue, Mar 01, 2022 at 12:56:02PM -0500, Daneel Yaitskov wrote: > > > I noticed, that I pay more attention than I should, when working with > > assertions, because I am not sure about argument order i.e. whether the > > expected value goes first or vice-versa. Does anybody have similar > thought? > > The documentation is quite clear: > > > https://hackage.haskell.org/package/HUnit-1.6.2.0/docs/Test-HUnit-Base.html#v:assertEqual > > > Such subtle detail should be easy to grasp with regular practice, but I > > observe difficulties and I suspect that there is a logical reason for > that. > > > > I spell "assertEqual" expression as: "Assert that x equals to y" > > "y" sounds like a model value (i.e. expected value). > > As a combinator that can be curried, > > -- Check variable given against fixed wanted > assertEqual prefix wanted :: (Eq a, Show a) => a -> Assertion > > is I think more useful than: > > -- Check variable wanted against fixed given. > assertEqual prefix given :: (Eq a, Show a) => a -> Assertion > > > Similar issue with test fixing - I always have to check first, that an > > expected value is actually one. There is no type safety preventing mixing > > arguments. > > The test works either way of course, the only thing that changes is the > error message on failure. You could implement a type-safe wrapper: > > newtype Given a = Given a > newtype Wanted a = Wanted a > > checkEq :: (Eq a, Show a) => String -> Given a -> Wanted a -> Assertion > checkEq prefix (Given x) (Wanted y) = assertEqual prefix y x > > Then always call via: > > checkEq "Oops" (Given (2 + 2)) (Wanted 5) > > -- > Viktor. > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Wed Mar 2 05:09:18 2022 From: qdunkan at gmail.com (Evan Laforge) Date: Tue, 1 Mar 2022 21:09:18 -0800 Subject: [Haskell-cafe] order of assertEqual arguments is counterintuitive In-Reply-To: References: Message-ID: I've always done `equal (thingToTest args) expectedValue` just as a habit, but it's usually the right order for me in haskell because `equal (f args) $ big complicated value`. It seems more common that the expected value is larger than arguments are. But I don't think I chose it due to that, it was probably that I also write `if mode == Whatever then ...` with the constant on the right, and that's probably some kind of "mental handedness" habit. But I've also usually written my own test frameworks, so I got to make the rules. If I use someone else's, then I try to follow whatever convention they put forth. I'm not sure it's ever mattered much though, because as soon as I see an error I go to the line that generated it, and then it's pretty clear if the left or right side is the expected value. On Tue, Mar 1, 2022 at 2:50 PM David Feuer wrote: > > I think newtypes are awkward here. Better to use a record to get "named arguments": > > data ExpAct a = ExpAct > { expected :: a > , actual :: a > } > > assertSame > :: HasCallStack > => (Eq a, Show a) > => String > -> ExpAct a > -> Assertion > assertSame s ExpAct{expected=e, actual=a} = assertEqual s e a > > Now you can write things like > > assertSame "whatever" ExpAct{expected=4, actual=x} > > On Tue, Mar 1, 2022, 2:38 PM Viktor Dukhovni wrote: >> >> On Tue, Mar 01, 2022 at 12:56:02PM -0500, Daneel Yaitskov wrote: >> >> > I noticed, that I pay more attention than I should, when working with >> > assertions, because I am not sure about argument order i.e. whether the >> > expected value goes first or vice-versa. Does anybody have similar thought? >> >> The documentation is quite clear: >> >> https://hackage.haskell.org/package/HUnit-1.6.2.0/docs/Test-HUnit-Base.html#v:assertEqual >> >> > Such subtle detail should be easy to grasp with regular practice, but I >> > observe difficulties and I suspect that there is a logical reason for that. >> > >> > I spell "assertEqual" expression as: "Assert that x equals to y" >> > "y" sounds like a model value (i.e. expected value). >> >> As a combinator that can be curried, >> >> -- Check variable given against fixed wanted >> assertEqual prefix wanted :: (Eq a, Show a) => a -> Assertion >> >> is I think more useful than: >> >> -- Check variable wanted against fixed given. >> assertEqual prefix given :: (Eq a, Show a) => a -> Assertion >> >> > Similar issue with test fixing - I always have to check first, that an >> > expected value is actually one. There is no type safety preventing mixing >> > arguments. >> >> The test works either way of course, the only thing that changes is the >> error message on failure. You could implement a type-safe wrapper: >> >> newtype Given a = Given a >> newtype Wanted a = Wanted a >> >> checkEq :: (Eq a, Show a) => String -> Given a -> Wanted a -> Assertion >> checkEq prefix (Given x) (Wanted y) = assertEqual prefix y x >> >> Then always call via: >> >> checkEq "Oops" (Given (2 + 2)) (Wanted 5) >> >> -- >> Viktor. >> _______________________________________________ >> 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. > > _______________________________________________ > 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. From raoknz at gmail.com Wed Mar 2 10:21:59 2022 From: raoknz at gmail.com (Richard O'Keefe) Date: Wed, 2 Mar 2022 23:21:59 +1300 Subject: [Haskell-cafe] order of assertEqual arguments is counterintuitive In-Reply-To: References: Message-ID: Little point of history: the xUnit family of unit testing frameworks originated in *Smalltalk* (SUnit), which is why the graphic user interface for running tests was a standard part of it. It wasn't just that you could drive tests from a graphic terminal, it was that testing was *integrated* with the IDE. The Wikipedia page on jUnit gets this right, acknowledging the priority of SUnit. Credit should be given to a specific person: Kent Beck, author of the original version of SUnit. It would be good for the HUnit document to give credit where credit is due. AS for the interface, what is the problem? It's always "some string" . It doesn't really matter very much whether the observed or expected value is presented next in assertEqual, but it is documented as expected-then-observed. On Wed, 2 Mar 2022 at 06:57, Daneel Yaitskov wrote: > Hi List, > > I noticed, that I pay more attention than I should, when working with > assertions, because I am not sure about argument order i.e. whether the > expected value goes first or vice-versa. Does anybody have similar thought? > > Such subtle detail should be easy to grasp with regular practice, but I > observe difficulties and I suspect that there is a logical reason for that. > > Unit tests appeared long time ago in Java and spread over all languages. > HUnit library inherited de facto standard assert function name and > signature. I don't know reasoning behind original signature. > > I spell "assertEqual" expression as: "Assert that x equals to y" > "y" sounds like a model value (i.e. expected value). > > In assignments "x <- y" y is the model value, because it defines "x". > You get "x" - value on the left not on the right. > > Similar issue with test fixing - I always have to check first, that an > expected value is actually one. There is no type safety preventing mixing > arguments. I had to open and comprehend a source file with test, because > test log is not 100% safe. > > > > -- > > Best regards, > Daniil Iaitskov > > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith.wygant at gmail.com Wed Mar 2 12:15:32 2022 From: keith.wygant at gmail.com (Keith) Date: Wed, 02 Mar 2022 12:15:32 +0000 Subject: [Haskell-cafe] order of assertEqual arguments is counterintuitive In-Reply-To: References: Message-ID: <5F7D6A76-AA7A-4BC6-84C4-D3EF6192B1D9@gmail.com> Sounds like you want `@?=`, which is less confusingly spelled `shouldBe` in hspec. -- Keith Sent from my phone with K-9 Mail. On 1 March 2022 17:56:02 UTC, Daneel Yaitskov wrote: >Hi List, > >I noticed, that I pay more attention than I should, when working with >assertions, because I am not sure about argument order i.e. whether the >expected value goes first or vice-versa. Does anybody have similar thought? > >Such subtle detail should be easy to grasp with regular practice, but I >observe difficulties and I suspect that there is a logical reason for that. > >Unit tests appeared long time ago in Java and spread over all languages. >HUnit library inherited de facto standard assert function name and >signature. I don't know reasoning behind original signature. > >I spell "assertEqual" expression as: "Assert that x equals to y" >"y" sounds like a model value (i.e. expected value). > >In assignments "x <- y" y is the model value, because it defines "x". >You get "x" - value on the left not on the right. > >Similar issue with test fixing - I always have to check first, that an >expected value is actually one. There is no type safety preventing mixing >arguments. I had to open and comprehend a source file with test, because >test log is not 100% safe. > > > >-- > >Best regards, >Daniil Iaitskov -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Fri Mar 4 10:58:31 2022 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 4 Mar 2022 11:58:31 +0100 (CET) Subject: [Haskell-cafe] data type familly and makeLenses Message-ID: <932970183.17523923.1646391511285.JavaMail.zimbra@synchrotron-soleil.fr> Hello, I defined a typeclass like this with a data familly class HasConfig a where data BinocularsConfig a :: * new :: (MonadIO m, MonadLogger m, MonadThrow m) => Maybe FilePath -> m (BinocularsConfig a) getConfig :: Maybe FilePath -> IO (Either String (BinocularsConfig a)) combineWithCmdLineArgs :: BinocularsConfig a -> Maybe ConfigRange -> Maybe (Path Abs Dir) -> BinocularsConfig a update :: (MonadIO m, MonadLogger m, MonadThrow m) => FilePath -> m (BinocularsConfig a) the instance is for now instance HasConfig PreConfig where data BinocularsConfig PreConfig = BinocularsPreConfig { _binocularsPreConfigProjectionType :: ProjectionType } deriving (Eq, Show) [...] Since I use Ini to serialize/un-serialize the configuration, I need lens for this type My question is how can I generate the like easily makeLenses ''(BinocularsConfig PreConfig) does not work thanks for considering Frederic From will.yager at gmail.com Fri Mar 4 14:18:40 2022 From: will.yager at gmail.com (Will Yager) Date: Fri, 4 Mar 2022 09:18:40 -0500 Subject: [Haskell-cafe] data type familly and makeLenses In-Reply-To: <932970183.17523923.1646391511285.JavaMail.zimbra@synchrotron-soleil.fr> References: <932970183.17523923.1646391511285.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <94FAD795-44B7-4CA1-A639-A07951D07A02@gmail.com> Could you derive Generic and then use generic lenses? > On Mar 4, 2022, at 06:04, PICCA Frederic-Emmanuel wrote: > > Hello, I defined a typeclass like this with a data familly > > class HasConfig a where > data BinocularsConfig a :: * > > new :: (MonadIO m, MonadLogger m, MonadThrow m) => Maybe FilePath -> m (BinocularsConfig a) > getConfig :: Maybe FilePath -> IO (Either String (BinocularsConfig a)) > combineWithCmdLineArgs :: BinocularsConfig a -> Maybe ConfigRange -> Maybe (Path Abs Dir) -> BinocularsConfig a > update :: (MonadIO m, MonadLogger m, MonadThrow m) => FilePath -> m (BinocularsConfig a) > > the instance is for now > > instance HasConfig PreConfig where > data BinocularsConfig PreConfig = > BinocularsPreConfig { _binocularsPreConfigProjectionType :: ProjectionType } > deriving (Eq, Show) > > [...] > > Since I use Ini to serialize/un-serialize the configuration, I need lens for this type > > My question is how can I generate the like easily > > makeLenses ''(BinocularsConfig PreConfig) does not work > > thanks for considering > > Frederic > _______________________________________________ > 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. From oleg.grenrus at iki.fi Fri Mar 4 14:36:03 2022 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 4 Mar 2022 16:36:03 +0200 Subject: [Haskell-cafe] data type familly and makeLenses In-Reply-To: <932970183.17523923.1646391511285.JavaMail.zimbra@synchrotron-soleil.fr> References: <932970183.17523923.1646391511285.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <2d076f9a-bfe7-d776-e395-817542461bc5@iki.fi> Use constructor name:     makeLenses 'BinocularsPreConfig   A minimal example:     {-# LANGUAGE TypeFamilies, TemplateHaskell #-}     import Control.Lens     class HasConfig a where       data BinocularsConfig a :: *     instance HasConfig () where       data BinocularsConfig () =         BinocularsPreConfig { _binocularsPreConfigProjectionType :: Int }                               deriving (Eq, Show)     makeLenses 'BinocularsPreConfig works:     *Main> :t binocularsPreConfigProjectionType     binocularsPreConfigProjectionType       :: (Profunctor p, Functor f) =>          p Int (f Int) -> p (BinocularsConfig ()) (f (BinocularsConfig ())) (In this case it's actually an Iso, as there is just one field). - Oleg On 4.3.2022 12.58, PICCA Frederic-Emmanuel wrote: > Hello, I defined a typeclass like this with a data familly > > class HasConfig a where > data BinocularsConfig a :: * > > new :: (MonadIO m, MonadLogger m, MonadThrow m) => Maybe FilePath -> m (BinocularsConfig a) > getConfig :: Maybe FilePath -> IO (Either String (BinocularsConfig a)) > combineWithCmdLineArgs :: BinocularsConfig a -> Maybe ConfigRange -> Maybe (Path Abs Dir) -> BinocularsConfig a > update :: (MonadIO m, MonadLogger m, MonadThrow m) => FilePath -> m (BinocularsConfig a) > > the instance is for now > > instance HasConfig PreConfig where > data BinocularsConfig PreConfig = > BinocularsPreConfig { _binocularsPreConfigProjectionType :: ProjectionType } > deriving (Eq, Show) > > [...] > > Since I use Ini to serialize/un-serialize the configuration, I need lens for this type > > My question is how can I generate the like easily > > makeLenses ''(BinocularsConfig PreConfig) does not work > > thanks for considering > > Frederic > _______________________________________________ > 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. From frederic-emmanuel.picca at synchrotron-soleil.fr Fri Mar 4 14:37:42 2022 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 4 Mar 2022 15:37:42 +0100 (CET) Subject: [Haskell-cafe] data type familly and makeLenses In-Reply-To: <94FAD795-44B7-4CA1-A639-A07951D07A02@gmail.com> References: <932970183.17523923.1646391511285.JavaMail.zimbra@synchrotron-soleil.fr> <94FAD795-44B7-4CA1-A639-A07951D07A02@gmail.com> Message-ID: <761868330.17708342.1646404662686.JavaMail.zimbra@synchrotron-soleil.fr> ----- Will Yager a écrit : > Could you derive Generic and then use generic lenses? Thanks for the hint, I will install it and I will keep you informed. cheers Fred libghc-generic-lens-dev/stable 2.0.0.0-1 amd64 generically derive traversals, lenses and prisms libghc-generic-lens-doc/stable 2.0.0.0-1 all generically derive traversals, lenses and prisms; documentation libghc-generic-lens-prof/stable 2.0.0.0-1 amd64 generically derive traversals, lenses and prisms; profiling libraries From andrei.h.popescu at gmail.com Sun Mar 6 21:27:25 2022 From: andrei.h.popescu at gmail.com (Andrei Popescu) Date: Sun, 6 Mar 2022 21:27:25 +0000 Subject: [Haskell-cafe] 22nd Midlands Graduate School, 10-14 April 2022: Call for Participation Message-ID: CALL FOR PARTICIPATION 22nd Midlands Graduate School (MGS'22) in the Foundations of Computing Science 10-14 April 2022, Nottingham (UK) https://www.cs.nott.ac.uk/~psznk/events/mgs22.html OVERVIEW MGS is an annual spring school that offers an intensive programme of lectures on the mathematical foundations of computing. While the school addresses especially PhD students in their first or second year, it is also open to UG and MSc students, postdocs, participants from the industry, and generally everyone interested in its topics. MGS'22 is the school's 22nd incarnation. PROGRAMME MGS'22 offers eight courses: - our invited course by Andrej Bauer - three basic courses on category theory, proof theory, and HoTT/UF with agda, which require no previous experience - four advanced courses on topos theory, string diagrams, coalgebra, and graph transformations. REGISTRATION Participation at MGS'22 costs GBP 320. Please see the website https://www.cs.nott.ac.uk/~psznk/events/mgs22.html for details, point "Registration". The fee covers participation in all lectures and exercise classes, refreshments in coffee breaks, and a conference dinner. Please note that you have to book accommodation yourselves but there are rooms available on campus. Places are limited and will be allocated on a first-come-first-served basis. If you would like to participate, please register early to secure a place. The registration period closes as soon as all places are filled or on March 20, whichever is sooner. ORGANISATION Please direct all queries about MGS'22 to Thorsten Altenkirch and Nicolai Kraus, thorsten.... at nottingham.ac.uk nicolai.... at nottingham.ac.uk From eborsboom at fpcomplete.com Sun Mar 6 21:41:47 2022 From: eborsboom at fpcomplete.com (Emanuel Borsboom) Date: Sun, 6 Mar 2022 21:41:47 +0000 Subject: [Haskell-cafe] ANN: stack-2.7.5 Message-ID: See https://haskellstack.org/ for installation and upgrade instructions. **Changes since v2.7.3:** Behavior changes: * Cloning git repositories isn't per sub-directory anymore, see [#5411](https://github.com/commercialhaskell/stack/issues/5411) Other enhancements: * `stack setup` supports installing GHC for macOS aarch64 (M1) * `stack upload` supports authentication with a Hackage API key (via `HACKAGE_KEY` environment variable). Bug fixes: * Ensure that `extra-path` works for case-insensitive `PATH`s on Windows. See [rio#237](https://github.com/commercialhaskell/rio/pull/237) * Fix handling of overwritten `ghc` and `ghc-pkg` locations. [#5597](https://github.com/commercialhaskell/stack/pull/5597) * Fix failure to find package when a dependency is shared between projects. [#5680](https://github.com/commercialhaskell/stack/issues/5680) * `stack ghci` now uses package flags in `stack.yaml` [#5434](https://github.com/commercialhaskell/stack/issues/5434) **Thanks to all our contributors for this release:** * Emanuel Borsboom * HaskellMouse * Julian Ospald * kocielnik * Matt Audesse * Michael Snoyman * MikaelUrankar * Muhammed Zakir * Natan Lao * Patryk Kocielnik * tkaaad97 From ben at well-typed.com Sun Mar 6 22:59:42 2022 From: ben at well-typed.com (Ben Gamari) Date: Sun, 06 Mar 2022 17:59:42 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.2 is not available Message-ID: <87r17ewuxe.fsf@smart-cactus.org> The GHC developers are very happy to at announce the availability of GHC 9.2.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.2.2 This release includes many bug-fixes and other improvements to 9.2.1 including: * A number of bug-fixes in the new AArch64 native code generator * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is handled correctly on platforms lacking support for unaligned memory accesses (#21015, #20987). * Improvements to the compatibility story in GHC's migration to the XDG Base Directory Specification (#20684, #20669, #20660) * Restored compatibility with Windows 7 * A new `-fcompact-unwind` flag, improving compatibility with C++ libraries on Apple Darwin (#11829) * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime bounds checking of array primops (#20769) * Unboxing of unlifted types (#20663) * Numerous improvements in compiler performance. * Many, many others. See the [release notes] for a full list. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket][] if you see anything amiss. Happy compiling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Sun Mar 6 23:11:29 2022 From: ben at well-typed.com (Ben Gamari) Date: Sun, 06 Mar 2022 18:11:29 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.2 is now available In-Reply-To: <87r17ewuxe.fsf@smart-cactus.org> References: <87r17ewuxe.fsf@smart-cactus.org> Message-ID: <87mti2wubc.fsf@smart-cactus.org> Naturally, the subject line here should have read GHC 9.2.2 is *now* available Apologies for the confusion. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From kazu at iij.ad.jp Mon Mar 7 06:27:40 2022 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon, 07 Mar 2022 15:27:40 +0900 (JST) Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.2 is not available In-Reply-To: References: <87r17ewuxe.fsf@smart-cactus.org> Message-ID: <20220307.152740.1433207400109063719.kazu@iij.ad.jp> Hi George, FYI: https://twitter.com/kazu_yamamoto/status/1500643489985761282 --Kazu > Thanks Ben > > When I do an install on macos Monterey 12.2.1 (Intel) I get > > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified > > > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari wrote: > >> >> The GHC developers are very happy to at announce the availability of GHC >> >> 9.2.2. Binary distributions, source distributions, and documentation are >> >> available at downloads.haskell.org: >> >> https://downloads.haskell.org/ghc/9.2.2 >> >> This release includes many bug-fixes and other improvements to 9.2.1 >> including: >> >> * A number of bug-fixes in the new AArch64 native code generator >> >> * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is >> handled >> correctly on platforms lacking support for unaligned memory accesses >> (#21015, #20987). >> >> * Improvements to the compatibility story in GHC's migration to the >> XDG Base Directory Specification (#20684, #20669, #20660) >> >> * Restored compatibility with Windows 7 >> >> * A new `-fcompact-unwind` flag, improving compatibility with C++ >> libraries on >> Apple Darwin (#11829) >> >> * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime >> bounds >> checking of array primops (#20769) >> >> * Unboxing of unlifted types (#20663) >> >> * Numerous improvements in compiler performance. >> >> * Many, many others. See the [release notes] for a full list. >> >> As some of the fixed issues do affect correctness users are encouraged to >> >> upgrade promptly. >> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous >> contributors whose on-going financial and in-kind support has >> facilitated GHC maintenance and release management over the years. >> Moreover, this release would not have been possible without the hundreds >> >> of open-source contributors whose work comprise this release. >> >> As always, do open a [ticket][] if you see anything amiss. >> >> Happy compiling, >> >> - Ben >> >> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> [release notes]: >> https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> From olf at aatal-apotheke.de Mon Mar 7 09:56:49 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 07 Mar 2022 10:56:49 +0100 Subject: [Haskell-cafe] GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus Message-ID: Dear Cafe, I had expected to see ThreadDied in the small example below. But when I compile with ghc --make -threaded -with-rtsopts=-N2 The output is: threadStatus: user error (child thread is crashing!) The status of my child is: ThreadFinished The output is not really a lie. But how do I determine whether a child thread has exited normally or not? Wouldn't you say a call to fail (or any other throwIO) should count as ThreadDied? The documentation of GHC.Conc.forkIO says: "... passes all other exceptions to the uncaught exception handler." and the documentation for GHC.Conc.ThreadStatus says: ThreadDied -- the thread received an uncaught exception One can provoke ThreadDied by using throwTo from the parent thread. So the emphasis in the documentation of ThreadDied should be on the word "received". This is a case of misleading documentation, in my humble opinion. The constructor should not be named ThreadDied because that suggests inclusion of internal reasons. Olaf -- begin threadStatus.hs import Control.Concurrent import GHC.Conc main = mainThread childThread :: IO () childThread = fail "child thread is crashing!" mainThread :: IO () mainThread = do child <- forkIO childThread threadDelay 5000 status <- threadStatus child putStr "The status of my child is: " print status -- end threadStatus.hs From coot at coot.me Mon Mar 7 19:59:44 2022 From: coot at coot.me (coot at coot.me) Date: Mon, 07 Mar 2022 19:59:44 +0000 Subject: [Haskell-cafe] GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus In-Reply-To: References: Message-ID: Hi Olaf, `forkIO` is rather a low level. It's more common to use async package (https://hackage.haskell.org/package/async). Async has `waitCatch` which allows you to wait for a thread to finish and get access to either an exception which killed the thread or the result of the thread handler. Best regards, Marcin Szamotulski Sent with ProtonMail secure email. ------- Original Message ------- On Monday, March 7th, 2022 at 10:56, Olaf Klinke wrote: > Dear Cafe, > > I had expected to see ThreadDied in the small example below. > > But when I compile with > > ghc --make -threaded -with-rtsopts=-N2 > > The output is: > > threadStatus: user error (child thread is crashing!) > > The status of my child is: > > ThreadFinished > > The output is not really a lie. But how do I determine whether a child > > thread has exited normally or not? Wouldn't you say a call to fail (or > > any other throwIO) should count as ThreadDied? > > The documentation of GHC.Conc.forkIO says: > > "... passes all other exceptions to the uncaught exception handler." > > and the documentation for GHC.Conc.ThreadStatus says: > > ThreadDied -- the thread received an uncaught exception > > One can provoke ThreadDied by using throwTo from the parent thread. So > > the emphasis in the documentation of ThreadDied should be on the word > > "received". > > This is a case of misleading documentation, in my humble opinion. > > The constructor should not be named ThreadDied because that suggests > > inclusion of internal reasons. > > Olaf > > -- begin threadStatus.hs > > import Control.Concurrent > > import GHC.Conc > > main = mainThread > > childThread :: IO () > > childThread = fail "child thread is crashing!" > > mainThread :: IO () > > mainThread = do > > child <- forkIO childThread > > threadDelay 5000 > > status <- threadStatus child > > putStr "The status of my child is: " > > print status > > -- end threadStatus.hs > > _______________________________________________ > > 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From ben at smart-cactus.org Tue Mar 8 04:04:12 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 07 Mar 2022 23:04:12 -0500 Subject: [Haskell-cafe] GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus In-Reply-To: References: Message-ID: <87bkyhw0nw.fsf@smart-cactus.org> Olaf Klinke writes: > Dear Cafe, > > I had expected to see ThreadDied in the small example below. > But when I compile with > ghc --make -threaded -with-rtsopts=-N2 > The output is: > > threadStatus: user error (child thread is crashing!) > The status of my child is: > ThreadFinished > > The output is not really a lie. But how do I determine whether a child > thread has exited normally or not? Wouldn't you say a call to fail (or > any other throwIO) should count as ThreadDied? > > The documentation of GHC.Conc.forkIO says: > "... passes all other exceptions to the uncaught exception handler." > and the documentation for GHC.Conc.ThreadStatus says: > ThreadDied -- the thread received an uncaught exception > > One can provoke ThreadDied by using throwTo from the parent thread. So > the emphasis in the documentation of ThreadDied should be on the word > "received". > This is a case of misleading documentation, in my humble opinion. > The constructor should not be named ThreadDied because that suggests > inclusion of internal reasons. > Thanks for reporting this, Olaf! Could you open a GHC ticket? [1] Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/issues/new -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From olf at aatal-apotheke.de Tue Mar 8 07:06:18 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 08 Mar 2022 08:06:18 +0100 Subject: [Haskell-cafe] GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus In-Reply-To: <87bkyhw0nw.fsf@smart-cactus.org> References: <87bkyhw0nw.fsf@smart-cactus.org> Message-ID: On Mon, 2022-03-07 at 23:04 -0500, Ben Gamari wrote: > Olaf Klinke writes: > > > Dear Cafe, > > > > I had expected to see ThreadDied in the small example below. > > But when I compile with > > ghc --make -threaded -with-rtsopts=-N2 > > The output is: > > > > threadStatus: user error (child thread is crashing!) > > The status of my child is: > > ThreadFinished > > > > The output is not really a lie. But how do I determine whether a child > > thread has exited normally or not? Wouldn't you say a call to fail (or > > any other throwIO) should count as ThreadDied? > > > > The documentation of GHC.Conc.forkIO says: > > "... passes all other exceptions to the uncaught exception handler." > > and the documentation for GHC.Conc.ThreadStatus says: > > ThreadDied -- the thread received an uncaught exception > > > > One can provoke ThreadDied by using throwTo from the parent thread. So > > the emphasis in the documentation of ThreadDied should be on the word > > "received". > > This is a case of misleading documentation, in my humble opinion. > > The constructor should not be named ThreadDied because that suggests > > inclusion of internal reasons. > > > Thanks for reporting this, Olaf! Could you open a GHC ticket? [1] > > Cheers, > > - Ben > > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/new Opened as https://gitlab.haskell.org/ghc/ghc/-/issues/21195 Regards Olaf From olf at aatal-apotheke.de Wed Mar 9 13:04:37 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 09 Mar 2022 14:04:37 +0100 Subject: [Haskell-cafe] GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus In-Reply-To: References: Message-ID: <0f8928e2d11db4eff30dcb18b811643d1378be8a.camel@aatal-apotheke.de> On Mon, 2022-03-07 at 19:59 +0000, coot at coot.me wrote: > Hi Olaf, > > `forkIO` is rather a low level. It's more common to use async package (https://hackage.haskell.org/package/async). Async has `waitCatch` which allows you to wait for a thread to finish and get access to either an exception which killed the thread or the result of the thread handler. > > Best regards, > Marcin Szamotulski > > Sent with ProtonMail secure email. Thanks for pointing this out, Marcin. Async seems to offer much better abstractions than what GHC.Conc provides for ThreadId. I have the impression, though, that Async was written for threads that are supposed to do their work and eventually terminate. In my application, a webserver forks several perpetually running threads and offers supervision to the user. Therefore withAsync is not perfectly suited, as we do not know upfront when and what we're going to do with the Async handle. I resorted to the following pattern. import Control.Concurrent.Async import Control.Concurrent import Control.Exception (SomeException) type MyThread = (IO (),MVar (Async ())) startThread :: MyThread -> IO () startThread (action,var) = withAsync action (putMVar var) pauseThread :: MyThread -> IO () pauseThread (_,var) = do a <- takeMVar var cancel a data MyThreadStatus = Paused | Running | Died SomeException threadStatus :: MyThread -> IO MyThreadStatus threadStatus (_,var) = do running <- tryReadMVar var case running of Nothing -> return Paused Just a -> do finished <- poll a case finished of Nothing -> return Running Just (Right _) -> return Paused Just (Left why) -> return (Died why) -- Olaf > > ------- Original Message ------- > > On Monday, March 7th, 2022 at 10:56, Olaf Klinke wrote: > > > Dear Cafe, > > > > I had expected to see ThreadDied in the small example below. > > > > But when I compile with > > > > ghc --make -threaded -with-rtsopts=-N2 > > > > The output is: > > > > threadStatus: user error (child thread is crashing!) > > > > The status of my child is: > > > > ThreadFinished > > > > The output is not really a lie. But how do I determine whether a child > > > > thread has exited normally or not? Wouldn't you say a call to fail (or > > > > any other throwIO) should count as ThreadDied? > > > > The documentation of GHC.Conc.forkIO says: > > > > "... passes all other exceptions to the uncaught exception handler." > > > > and the documentation for GHC.Conc.ThreadStatus says: > > > > ThreadDied -- the thread received an uncaught exception > > > > One can provoke ThreadDied by using throwTo from the parent thread. So > > > > the emphasis in the documentation of ThreadDied should be on the word > > > > "received". > > > > This is a case of misleading documentation, in my humble opinion. > > > > The constructor should not be named ThreadDied because that suggests > > > > inclusion of internal reasons. > > > > Olaf > > > > -- begin threadStatus.hs > > > > import Control.Concurrent > > > > import GHC.Conc > > > > main = mainThread > > > > childThread :: IO () > > > > childThread = fail "child thread is crashing!" > > > > mainThread :: IO () > > > > mainThread = do > > > > child <- forkIO childThread > > > > threadDelay 5000 > > > > status <- threadStatus child > > > > putStr "The status of my child is: " > > > > print status > > > > -- end threadStatus.hs > > > > _______________________________________________ > > > > 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. From will.yager at gmail.com Wed Mar 9 15:39:09 2022 From: will.yager at gmail.com (Will Yager) Date: Wed, 9 Mar 2022 10:39:09 -0500 Subject: [Haskell-cafe] GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus In-Reply-To: <0f8928e2d11db4eff30dcb18b811643d1378be8a.camel@aatal-apotheke.de> References: <0f8928e2d11db4eff30dcb18b811643d1378be8a.camel@aatal-apotheke.de> Message-ID: <7F8AF3CD-86F3-4AE7-8782-3FB9869D8F89@gmail.com> The idiom I use for non-terminating processes with async looks like this (snippet from the end of a main function): outputter <- async $ logged $ forever $ do (topic, msg) <- liftIO $ readChan outputChan liftIO $ MC.publish client topic msg False automation <- async $ logged $ liftIO $ MC.waitForClient client calendarChecker <- async $ logged $ handleCalendarEvents (liftIO . calendar) (_, err :: String) <- liftIO $ waitAny [ "logger1 died" <$ logger1, "logger2 died" <$ logger2, "reporter died" <$ reporter, "client died" <$ automation, "outputter died" <$ outputter, "calendar died" <$ calendarChecker ] print err Typically these things like `automation` will return `IO void`, but they can return whatever you like. > On Mar 9, 2022, at 08:10, Olaf Klinke wrote: > > On Mon, 2022-03-07 at 19:59 +0000, coot at coot.me wrote: >> Hi Olaf, >> >> `forkIO` is rather a low level. It's more common to use async package (https://hackage.haskell.org/package/async). Async has `waitCatch` which allows you to wait for a thread to finish and get access to either an exception which killed the thread or the result of the thread handler. >> >> Best regards, >> Marcin Szamotulski >> >> Sent with ProtonMail secure email. > > Thanks for pointing this out, Marcin. > Async seems to offer much better abstractions than what GHC.Conc > provides for ThreadId. > I have the impression, though, that Async was written for threads that > are supposed to do their work and eventually terminate. > In my application, a webserver forks several perpetually running > threads and offers supervision to the user. Therefore withAsync is not > perfectly suited, as we do not know upfront when and what we're going > to do with the Async handle. I resorted to the following pattern. > > import Control.Concurrent.Async > import Control.Concurrent > import Control.Exception (SomeException) > > type MyThread = (IO (),MVar (Async ())) > > startThread :: MyThread -> IO () > startThread (action,var) = withAsync action (putMVar var) > > pauseThread :: MyThread -> IO () > pauseThread (_,var) = do > a <- takeMVar var > cancel a > > data MyThreadStatus = Paused | Running | Died SomeException > threadStatus :: MyThread -> IO MyThreadStatus > threadStatus (_,var) = do > running <- tryReadMVar var > case running of > Nothing -> return Paused > Just a -> do > finished <- poll a > case finished of > Nothing -> return Running > Just (Right _) -> return Paused > Just (Left why) -> return (Died why) > > -- Olaf > >> >> ------- Original Message ------- >> >>> On Monday, March 7th, 2022 at 10:56, Olaf Klinke wrote: >>> >>> Dear Cafe, >>> >>> I had expected to see ThreadDied in the small example below. >>> >>> But when I compile with >>> >>> ghc --make -threaded -with-rtsopts=-N2 >>> >>> The output is: >>> >>> threadStatus: user error (child thread is crashing!) >>> >>> The status of my child is: >>> >>> ThreadFinished >>> >>> The output is not really a lie. But how do I determine whether a child >>> >>> thread has exited normally or not? Wouldn't you say a call to fail (or >>> >>> any other throwIO) should count as ThreadDied? >>> >>> The documentation of GHC.Conc.forkIO says: >>> >>> "... passes all other exceptions to the uncaught exception handler." >>> >>> and the documentation for GHC.Conc.ThreadStatus says: >>> >>> ThreadDied -- the thread received an uncaught exception >>> >>> One can provoke ThreadDied by using throwTo from the parent thread. So >>> >>> the emphasis in the documentation of ThreadDied should be on the word >>> >>> "received". >>> >>> This is a case of misleading documentation, in my humble opinion. >>> >>> The constructor should not be named ThreadDied because that suggests >>> >>> inclusion of internal reasons. >>> >>> Olaf >>> >>> -- begin threadStatus.hs >>> >>> import Control.Concurrent >>> >>> import GHC.Conc >>> >>> main = mainThread >>> >>> childThread :: IO () >>> >>> childThread = fail "child thread is crashing!" >>> >>> mainThread :: IO () >>> >>> mainThread = do >>> >>> child <- forkIO childThread >>> >>> threadDelay 5000 >>> >>> status <- threadStatus child >>> >>> putStr "The status of my child is: " >>> >>> print status >>> >>> -- end threadStatus.hs >>> >>> _______________________________________________ >>> >>> 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. > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Mar 9 18:23:06 2022 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 09 Mar 2022 18:23:06 +0000 Subject: [Haskell-cafe] GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus In-Reply-To: <7F8AF3CD-86F3-4AE7-8782-3FB9869D8F89@gmail.com> References: <0f8928e2d11db4eff30dcb18b811643d1378be8a.camel@aatal-apotheke.de> <7F8AF3CD-86F3-4AE7-8782-3FB9869D8F89@gmail.com> Message-ID: <3e7062fb-e69e-47c1-baaf-61358c9fe78f@www.fastmail.com> Another good option for eternally long running things is to use race. I actually think race and concurrently are the much better go-to functions from the async library. I will often write code like: race_ daemonThread mainThread >>= \case Left _ -> fail "Daemon terminated" Right a -> return a This forks a thread for a daemon, a thread for the main thread, and then waits for either of them to finish. Assuming the daemon should never terminate, if it terminates the main thread will be terminated and the calling thread (e.g., main) will crash. If the other thread terminates early, that's fine, and we assume that's just the program gracefully terminating. In this case, the daemon will be cancelled. Ollie On Wed, 9 Mar 2022, at 3:39 PM, Will Yager wrote: > > The idiom I use for non-terminating processes with async looks like this (snippet from the end of a main function): > > > > outputter <- async $ > > logged $ > > forever $ do > > (topic, msg) <- liftIO $ readChan outputChan > > liftIO $ MC.publish client topic msg False > > automation <- async $ logged $ liftIO $ MC.waitForClient client > > calendarChecker <- async $ logged $ handleCalendarEvents (liftIO . calendar) > > (_, err :: String) <- > > liftIO $ > > waitAny > > [ "logger1 died" <$ logger1, > > "logger2 died" <$ logger2, > > "reporter died" <$ reporter, > > "client died" <$ automation, > > "outputter died" <$ outputter, > > "calendar died" <$ calendarChecker > > ] > > print err > > Typically these things like `automation` will return `IO void`, but they can return whatever you like. > > > > >> On Mar 9, 2022, at 08:10, Olaf Klinke wrote: >> On Mon, 2022-03-07 at 19:59 +0000, coot at coot.me wrote: >>> Hi Olaf, >>> >>> `forkIO` is rather a low level. It's more common to use async package (https://hackage.haskell.org/package/async). Async has `waitCatch` which allows you to wait for a thread to finish and get access to either an exception which killed the thread or the result of the thread handler. >>> >>> Best regards, >>> Marcin Szamotulski >>> >>> Sent with ProtonMail secure email. >> >> Thanks for pointing this out, Marcin. >> Async seems to offer much better abstractions than what GHC.Conc >> provides for ThreadId. >> I have the impression, though, that Async was written for threads that >> are supposed to do their work and eventually terminate. >> In my application, a webserver forks several perpetually running >> threads and offers supervision to the user. Therefore withAsync is not >> perfectly suited, as we do not know upfront when and what we're going >> to do with the Async handle. I resorted to the following pattern. >> >> import Control.Concurrent.Async >> import Control.Concurrent >> import Control.Exception (SomeException) >> >> type MyThread = (IO (),MVar (Async ())) >> >> startThread :: MyThread -> IO () >> startThread (action,var) = withAsync action (putMVar var) >> >> pauseThread :: MyThread -> IO () >> pauseThread (_,var) = do >> a <- takeMVar var >> cancel a >> >> data MyThreadStatus = Paused | Running | Died SomeException >> threadStatus :: MyThread -> IO MyThreadStatus >> threadStatus (_,var) = do >> running <- tryReadMVar var >> case running of >> Nothing -> return Paused >> Just a -> do >> finished <- poll a >> case finished of >> Nothing -> return Running >> Just (Right _) -> return Paused >> Just (Left why) -> return (Died why) >> >> -- Olaf >> >>> >>> ------- Original Message ------- >>> >>> On Monday, March 7th, 2022 at 10:56, Olaf Klinke wrote: >>> >>>> Dear Cafe, >>>> >>>> I had expected to see ThreadDied in the small example below. >>>> >>>> But when I compile with >>>> >>>> ghc --make -threaded -with-rtsopts=-N2 >>>> >>>> The output is: >>>> >>>> threadStatus: user error (child thread is crashing!) >>>> >>>> The status of my child is: >>>> >>>> ThreadFinished >>>> >>>> The output is not really a lie. But how do I determine whether a child >>>> >>>> thread has exited normally or not? Wouldn't you say a call to fail (or >>>> >>>> any other throwIO) should count as ThreadDied? >>>> >>>> The documentation of GHC.Conc.forkIO says: >>>> >>>> "... passes all other exceptions to the uncaught exception handler." >>>> >>>> and the documentation for GHC.Conc.ThreadStatus says: >>>> >>>> ThreadDied -- the thread received an uncaught exception >>>> >>>> One can provoke ThreadDied by using throwTo from the parent thread. So >>>> >>>> the emphasis in the documentation of ThreadDied should be on the word >>>> >>>> "received". >>>> >>>> This is a case of misleading documentation, in my humble opinion. >>>> >>>> The constructor should not be named ThreadDied because that suggests >>>> >>>> inclusion of internal reasons. >>>> >>>> Olaf >>>> >>>> -- begin threadStatus.hs >>>> >>>> import Control.Concurrent >>>> >>>> import GHC.Conc >>>> >>>> main = mainThread >>>> >>>> childThread :: IO () >>>> >>>> childThread = fail "child thread is crashing!" >>>> >>>> mainThread :: IO () >>>> >>>> mainThread = do >>>> >>>> child <- forkIO childThread >>>> >>>> threadDelay 5000 >>>> >>>> status <- threadStatus child >>>> >>>> putStr "The status of my child is: " >>>> >>>> print status >>>> >>>> -- end threadStatus.hs >>>> >>>> _______________________________________________ >>>> >>>> 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. >> >> >> _______________________________________________ >> 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. > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Wed Mar 9 19:45:26 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 09 Mar 2022 20:45:26 +0100 Subject: [Haskell-cafe] child thread control design patterns (was: GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus) Message-ID: <12167e59a3093b883907479a61fbc8b2f680f993.camel@aatal-apotheke.de> > Another good option for eternally long running things is to use race. I actually think race and concurrently are the much better go-to functions from the async library. I will often write code like: > > race_ daemonThread mainThread >>= \case > Left _ -> fail "Daemon terminated" > Right a -> return a > > This forks a thread for a daemon, a thread for the main thread, and then waits for either of them to finish. Assuming the daemon should never terminate, if it terminates the main thread will be terminated and the calling thread (e.g., main) will crash. If the other thread terminates early, that's fine, and we assume that's just the program gracefully terminating. In this case, the daemon will be cancelled. > > Ollie That is indeed a neat pattern. What are its advantages/disadvantages? The main thread in my case is the (Yesod) webserver. Perhaps Yesod does exactly what you propose, internally. Currently I use a bracket to kill all child threads when the webserver shuts down, like: main = bracket forkWorkers (traverse_ cancel) (const (warp port site)) Your idiom would be something like this? main = foldr race_ (warp port site) workers I also do want to include the possibility of a child (daemon) thread to crash without crashing the webserver (hence my original question), which your race solution does not cater for. In fact I will have a mix of perpetually running actions and actions that are fired on command of the user and then exit gracefully. Therefore I must save the original IO action somewhere, to be re- executed. And since operations on the child thread are initiated by the Yesod event handler, I can not pass them to the continuation of withAsync. Olaf From ollie at ocharles.org.uk Thu Mar 10 07:44:24 2022 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 10 Mar 2022 07:44:24 +0000 Subject: [Haskell-cafe] child thread control design patterns (was: GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus) In-Reply-To: <12167e59a3093b883907479a61fbc8b2f680f993.camel@aatal-apotheke.de> References: <12167e59a3093b883907479a61fbc8b2f680f993.camel@aatal-apotheke.de> Message-ID: <008637dd-cc68-45d4-be1f-f54602490631@www.fastmail.com> On Wed, 9 Mar 2022, at 7:45 PM, Olaf Klinke wrote: > That is indeed a neat pattern. What are its advantages/disadvantages? > The main thread in my case is the (Yesod) webserver. Perhaps Yesod does > exactly what you propose, internally. Mostly that one doesn't have to think about linking threads together, that just comes by design. If you want "these things must always be running", I find it's a nice fit. Also, this pattern implements the "structured concurrency" paradigm, which I'm a big fan of (see https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/) > Your idiom would be something like this? > > main = foldr race_ (warp port site) workers Yes, something like that. > I also do want to include the possibility of a child (daemon) thread to > crash without crashing the webserver (hence my original question), > which your race solution does not cater for. In fact I will have a mix > of perpetually running actions and actions that are fired on command of > the user and then exit gracefully. Right, if you _expect_ the daemon to terminate, then this isn't a good fit. However, I would still be striving to get some kind of structured concurrency solution. To that end, I would probably have some over-arching daemon that has a shared job queue (e.g., an STM TChan), and web requests can write to this TChan (maybe with a TMVar to fill in responses). Then, the worker daemon would pop jobs off this TChan and itself spawn new threads and manage the lifetime of them. This gives you the best of both worlds - structured concurrency in main, and ephemeral worker threads. Hope this helps, Ollie -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Thu Mar 10 17:53:38 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 10 Mar 2022 18:53:38 +0100 Subject: [Haskell-cafe] child thread control design patterns (was: GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus) In-Reply-To: <008637dd-cc68-45d4-be1f-f54602490631@www.fastmail.com> References: <12167e59a3093b883907479a61fbc8b2f680f993.camel@aatal-apotheke.de> <008637dd-cc68-45d4-be1f-f54602490631@www.fastmail.com> Message-ID: <6b9eee0a49b9c2405c8da246530b5b2773ed3a74.camel@aatal-apotheke.de> On Thu, 2022-03-10 at 07:44 +0000, Oliver Charles wrote: > On Wed, 9 Mar 2022, at 7:45 PM, Olaf Klinke wrote: > > That is indeed a neat pattern. What are its advantages/disadvantages? > > The main thread in my case is the (Yesod) webserver. Perhaps Yesod does > > exactly what you propose, internally. > > Mostly that one doesn't have to think about linking threads together, that just comes by design. If you want "these things must always be running", I find it's a nice fit. Also, this pattern implements the "structured concurrency" paradigm, which I'm a big fan of (see https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/) > > > Your idiom would be something like this? > > > > main = foldr race_ (warp port site) workers > > Yes, something like that. > > > I also do want to include the possibility of a child (daemon) thread to > > crash without crashing the webserver (hence my original question), > > which your race solution does not cater for. In fact I will have a mix > > of perpetually running actions and actions that are fired on command of > > the user and then exit gracefully. > > Right, if you _expect_ the daemon to terminate, then this isn't a good fit. However, I would still be striving to get some kind of structured concurrency solution. To that end, I would probably have some over-arching daemon that has a shared job queue (e.g., an STM TChan), and web requests can write to this TChan (maybe with a TMVar to fill in responses). Then, the worker daemon would pop jobs off this TChan and itself spawn new threads and manage the lifetime of them. This gives you the best of both worlds - structured concurrency in main, and ephemeral worker threads. > > Hope this helps, > Ollie Hmm, but this over-arching daemon (nursery, as it is called in the blog post) watching over the queue *is* my webserver. Instead of a TChan it has routes that correspond to start and pause commands of specific daemon threads. Inter-thread signalling is indeed handled via TVars, that's what they're for. It would be cool to have a TVar or TChan that is read-only for one side and write-only for the other. And thank to Control.Concurrent.Async.link I have full control over which exceptions get propagated from child to parent. The library designers probably should not have made async and link two distinct functions, because that enables the programmer to disregard those exceptions. Should we be porting Trio to Haskell? Or does Haskell offer enough abstraction already? There are some points in the blog post that I disagree with. If any function can fork a concurrent process, not all is lost. Because of immutable values we pretty much know what can be touched by that concurrent process. And because of that, often we can ignore how long the concurrent process runs because it can not affect our linear code. I should have read the Async documentation more carefully. startThread :: MyThread -> IO () startThread (action,var) = withAsync action (putMVar var) immediately cancels the thread because putMVar returns. Hence one must use async instead of withAsync if the main thread can not be passed to withAsync. The pattern similar to your race would be: foldr (\a b -> withAsync a (const b)) mainThread daemons which, unlike race, does not kill the mainThread if one of the daemons crashes, but cancels the daemons if the mainThread terminates. Olaf From me at michaelpj.com Fri Mar 11 10:50:52 2022 From: me at michaelpj.com (Michael Peyton Jones) Date: Fri, 11 Mar 2022 10:50:52 +0000 Subject: [Haskell-cafe] child thread control design patterns (was: GHC.Conc.threadStatus - documentation of ThreadDied :: ThreadStatus) In-Reply-To: <6b9eee0a49b9c2405c8da246530b5b2773ed3a74.camel@aatal-apotheke.de> References: <12167e59a3093b883907479a61fbc8b2f680f993.camel@aatal-apotheke.de> <008637dd-cc68-45d4-be1f-f54602490631@www.fastmail.com> <6b9eee0a49b9c2405c8da246530b5b2773ed3a74.camel@aatal-apotheke.de> Message-ID: I hadn't come across structured concurrency before, that was an interesting read. A quick google turns up a Haskell structured concurrency package, but it seems to be relatively new: https://hackage.haskell.org/package/ki Michael On Thu, Mar 10, 2022 at 5:59 PM Olaf Klinke wrote: > On Thu, 2022-03-10 at 07:44 +0000, Oliver Charles wrote: > > On Wed, 9 Mar 2022, at 7:45 PM, Olaf Klinke wrote: > > > That is indeed a neat pattern. What are its advantages/disadvantages? > > > The main thread in my case is the (Yesod) webserver. Perhaps Yesod does > > > exactly what you propose, internally. > > > > Mostly that one doesn't have to think about linking threads together, > that just comes by design. If you want "these things must always be > running", I find it's a nice fit. Also, this pattern implements the > "structured concurrency" paradigm, which I'm a big fan of (see > https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ > ) > > > > > Your idiom would be something like this? > > > > > > main = foldr race_ (warp port site) workers > > > > Yes, something like that. > > > > > I also do want to include the possibility of a child (daemon) thread to > > > crash without crashing the webserver (hence my original question), > > > which your race solution does not cater for. In fact I will have a mix > > > of perpetually running actions and actions that are fired on command of > > > the user and then exit gracefully. > > > > Right, if you _expect_ the daemon to terminate, then this isn't a good > fit. However, I would still be striving to get some kind of structured > concurrency solution. To that end, I would probably have some over-arching > daemon that has a shared job queue (e.g., an STM TChan), and web requests > can write to this TChan (maybe with a TMVar to fill in responses). Then, > the worker daemon would pop jobs off this TChan and itself spawn new > threads and manage the lifetime of them. This gives you the best of both > worlds - structured concurrency in main, and ephemeral worker threads. > > > > Hope this helps, > > Ollie > > Hmm, but this over-arching daemon (nursery, as it is called in the blog > post) watching over the queue *is* my webserver. Instead of a TChan it > has routes that correspond to start and pause commands of specific > daemon threads. Inter-thread signalling is indeed handled via TVars, > that's what they're for. It would be cool to have a TVar or TChan that > is read-only for one side and write-only for the other. And thank to > Control.Concurrent.Async.link I have full control over which exceptions > get propagated from child to parent. The library designers probably > should not have made async and link two distinct functions, because > that enables the programmer to disregard those exceptions. > Should we be porting Trio to Haskell? Or does Haskell offer enough > abstraction already? > There are some points in the blog post that I disagree with. If any > function can fork a concurrent process, not all is lost. Because of > immutable values we pretty much know what can be touched by that > concurrent process. And because of that, often we can ignore how long > the concurrent process runs because it can not affect our linear code. > > I should have read the Async documentation more carefully. > > startThread :: MyThread -> IO () > startThread (action,var) = withAsync action (putMVar var) > > immediately cancels the thread because putMVar returns. > Hence one must use async instead of withAsync if the main thread can > not be passed to withAsync. The pattern similar to your race would be: > > foldr (\a b -> withAsync a (const b)) mainThread daemons > > which, unlike race, does not kill the mainThread if one of the daemons > crashes, but cancels the daemons if the mainThread terminates. > > Olaf > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elenam at morris.umn.edu Fri Mar 11 23:07:13 2022 From: elenam at morris.umn.edu (Elena Machkasova) Date: Fri, 11 Mar 2022 17:07:13 -0600 Subject: [Haskell-cafe] TFPIE 2022 March 16 online - last call for participation Message-ID: Dear All, TFPIE 2022 invites you to attend the conference on March 16 online. The program and the registration link are posted here: https://wiki.tfpie.science.ru.nl/TFPIE2022 Registration is free, but required for the zoom link to be sent. TFPIE is followed by TFP on March 17-18: https://trendsfp.github.io/index.html The registration is the same for the two conferences. More details: The 2022 edition of Trends in Functional Programming in Education will be held *virtually on March 16th 2022*, together with TFP which will be held on March 17-18. Note that *Lambda Days* in Krakow, Poland has been rescheduled to July 28-29, and authors of TFPIE accepted papers are welcome to present their papers at the Lambda Days, in addition to the virtual presentations in March. The goal of TFPIE is to gather researchers, teachers and professionals that use, or are interested in the use of, functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas and work-in-progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. Hope to see you there! Elena Machkasova -- Dr. Elena Machkasova Associate Professor of Computer Science Division of Science and Mathematics University of Minnesota, Morris Office: Sci 2325 (320) 589-6308 http://cda.morris.umn.edu/~elenam/ Pronouns: she/her/hers or any other -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Sun Mar 13 11:06:53 2022 From: P.Achten at cs.ru.nl (Peter Achten) Date: Sun, 13 Mar 2022 12:06:53 +0100 Subject: [Haskell-cafe] [Call for participation] TFPiE and TFP online events March 16-18 Message-ID: <5bf71760-9954-67b3-5b5c-da9cd5d47ce1@cs.ru.nl> -------------------------------------------------------------------------------               C A L L  F O R  P A R T I C I P A T I O N  11th International Workshop on Trends in Functional Programming in Education                                   +            23rd Symposium on Trends in Functional Programming                          16 - 18 March 2022                  wiki.tfpie.science.ru.nl/TFPIE2022                          trendsfp.github.io ------------------------------------------------------------------------------- The programmes for TFPIE and TFP are online (all times are UTC+0): - TFPIE: https://wiki.tfpie.science.ru.nl/TFPIE2022 - TFP:   https://trendsfp.github.io/schedule.html Registration is free. Prior to the events you receive a mail with the links to the Zoom meetings. The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. We aspire to be a lively environment for presenting the latest research results, and other contributions. The Trends in Functional Programming in Education workshops are an informal meeting intended for researchers, professors, teachers, and all professionals that use or are interested in the use of functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas, and work in progress on the use of functional programming in education are discussed. We foster a spirit of open discussion by having a review process for publication after the workshop. The program has a lot of interesting talks, possibilities for interaction, and keynote presentations: Trends in Functional Programming in Education keynote speaker: --------------------------------------------------------------- Peter Achten: The Perfect Functional Programming Course Trends in Functional Programming keynote speaker: ------------------------------------------------- Christiaan Baaij: Building a Haskell-to-Hardware compiler: Theory & Practice From nadine.and.henry at pobox.com Sun Mar 13 14:10:48 2022 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Sun, 13 Mar 2022 07:10:48 -0700 Subject: [Haskell-cafe] Why is this package being compiled Message-ID: <87bkyandsn.fsf@pobox.com> Dear Haskell friends, Is there a way to discover why a certain package is being compiled? In my case, the package cryptonite is a dependency of some other package, but I don't know which one. cryptonite doesn't compile on GHC 9.2.2, so if I can find out which package is causing it to be selected, perhaps I can work around my code so it (my code) does not depend on that package. I hope I am making myself clear. Any pointers would be appreciated. Best wishes, Nadine and Henry Laxen The rest is silence From lemming at henning-thielemann.de Sun Mar 13 15:12:55 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 13 Mar 2022 16:12:55 +0100 (CET) Subject: [Haskell-cafe] Why is this package being compiled In-Reply-To: <87bkyandsn.fsf@pobox.com> References: <87bkyandsn.fsf@pobox.com> Message-ID: On Sun, 13 Mar 2022, Henry Laxen wrote: > Dear Haskell friends, > > Is there a way to discover why a certain package is being compiled? In my > case, the package cryptonite is a dependency of some other package, but I > don't know which one. cryptonite doesn't compile on GHC 9.2.2, so if I can > find out which package is causing it to be selected, perhaps I can work around > my code so it (my code) does not depend on that package. I hope I am making > myself clear. Any pointers would be appreciated. If you manage to forbid Cabal to compile 'cryptonite' it will tell you, why it is required, i.e. which package directly depends on 'cryptonite'. --constraint="cryptonite installed" or --constraint="cryptonite>=1000000" should provoke an according message. Yes, just tested it in an example project and got: ... [__8] next goal: cryptonite (dependency of http-client-tls) [__8] rejecting: cryptonite-0.29, cryptonite-0.28, cryptonite-0.27, ... From vamchale at gmail.com Sun Mar 13 17:31:39 2022 From: vamchale at gmail.com (Vanessa McHale) Date: Sun, 13 Mar 2022 10:31:39 -0700 Subject: [Haskell-cafe] Why is this package being compiled In-Reply-To: <87bkyandsn.fsf@pobox.com> References: <87bkyandsn.fsf@pobox.com> Message-ID: I would use cabal-plan: https://hackage.haskell.org/package/cabal-plan there’s a subcommand, cabal-plan dot, which produces output suitable for graphviz: https://graphviz.org Cheers, Vanessa McHale > On Mar 13, 2022, at 7:10 AM, Henry Laxen wrote: > > Dear Haskell friends, > > Is there a way to discover why a certain package is being compiled? In my > case, the package cryptonite is a dependency of some other package, but I > don't know which one. cryptonite doesn't compile on GHC 9.2.2, so if I can > find out which package is causing it to be selected, perhaps I can work around > my code so it (my code) does not depend on that package. I hope I am making > myself clear. Any pointers would be appreciated. > Best wishes, > Nadine and Henry Laxen The rest is silence > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Sun Mar 13 18:06:28 2022 From: vamchale at gmail.com (Vanessa McHale) Date: Sun, 13 Mar 2022 11:06:28 -0700 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate Message-ID: I’m looking to appreciate “retro” Haskell projects, things from before stabilization/company use. Such as: fgl https://web.engr.oregonstate.edu/~erwig/fgl/haskell/ WWWBrowser https://cth.altocumulus.org/~hallgren/wwwbrowser.html Balsa/Teak (languages) http://apt.cs.manchester.ac.uk/projects/tools/balsa/ BlueSpec compiler https://github.com/B-Lang-org/bsc The CABAL spec (Common Architecture for Building Applications and Tools) https://www.haskell.org/cabal/proposal/index.html Frag (that one Haskell game) https://wiki.haskell.org/Frag Hugs string extensions https://www.haskell.org/hugs/pages/users_guide/here-documents.html I guess darcs/c2hs/happy/alex count, they have history! Bonus points for Makefiles to build the project Professor-HTML project page Hugs support Haskell 1.4 etc. support -------------- next part -------------- An HTML attachment was scrubbed... URL: From power.walross at gmail.com Sun Mar 13 18:15:06 2022 From: power.walross at gmail.com (Fendor) Date: Sun, 13 Mar 2022 19:15:06 +0100 Subject: [Haskell-cafe] Why is this package being compiled In-Reply-To: References: <87bkyandsn.fsf@pobox.com> Message-ID: <054238b4-cd4d-0129-7ef2-0464770a920a@gmail.com> I second cabal-plan, but I am suggesting in particular the PR https://github.com/haskell-hvr/cabal-plan/pull/53 which features the sub-command `why-depends` pruning the dependency tree to show you exactly why you depend on a certain package. (Trying to raise some awareness for that PR as I want it to be merged) Best regards, Fendor On 13/03/2022 18:31, Vanessa McHale wrote: > I would use cabal-plan: https://hackage.haskell.org/package/cabal-plan > > there’s a subcommand, cabal-plan dot, which produces output suitable > for graphviz: https://graphviz.org > > Cheers, > Vanessa McHale > >> On Mar 13, 2022, at 7:10 AM, Henry Laxen >> wrote: >> >> Dear Haskell friends, >> >> Is there a way to discover why a certain package is being compiled? >>  In my >> case, the package cryptonite is a dependency of some other package, but I >> don't know which one.  cryptonite doesn't compile on GHC 9.2.2, so if >> I can >> find out which package is causing it to be selected, perhaps I can >> work around >> my code so it (my code) does not depend on that package.  I hope I am >> making >> myself clear.  Any pointers would be appreciated. >> Best wishes, >> Nadine and Henry Laxen            The rest is silence >> _______________________________________________ >> 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. > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Sun Mar 13 18:18:41 2022 From: vamchale at gmail.com (Vanessa McHale) Date: Sun, 13 Mar 2022 11:18:41 -0700 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: <4785D2B4-B81F-4DDA-ACF3-1EEB83D601EC@gmail.com> Oh also data parallel Haskell, and repa/accelerate I suppose! > On Mar 13, 2022, at 11:06 AM, Vanessa McHale wrote: > > I’m looking to appreciate “retro” Haskell projects, things from before stabilization/company use. > > Such as: > > fgl https://web.engr.oregonstate.edu/~erwig/fgl/haskell/ > > WWWBrowser https://cth.altocumulus.org/~hallgren/wwwbrowser.html > > Balsa/Teak (languages) http://apt.cs.manchester.ac.uk/projects/tools/balsa/ > > BlueSpec compiler https://github.com/B-Lang-org/bsc > > The CABAL spec (Common Architecture for Building Applications and Tools) https://www.haskell.org/cabal/proposal/index.html > > Frag (that one Haskell game) https://wiki.haskell.org/Frag > > Hugs string extensions https://www.haskell.org/hugs/pages/users_guide/here-documents.html > > I guess darcs/c2hs/happy/alex count, they have history! > > Bonus points for > > Makefiles to build the project > Professor-HTML project page > Hugs support > Haskell 1.4 etc. support -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Sun Mar 13 18:24:33 2022 From: qdunkan at gmail.com (Evan Laforge) Date: Sun, 13 Mar 2022 11:24:33 -0700 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: <4785D2B4-B81F-4DDA-ACF3-1EEB83D601EC@gmail.com> References: <4785D2B4-B81F-4DDA-ACF3-1EEB83D601EC@gmail.com> Message-ID: WASH was an interesting web page thing. Homepage complete with washing machine graphics. On Sun, Mar 13, 2022, 11:19 AM Vanessa McHale wrote: > Oh also data parallel Haskell, and repa/accelerate I suppose! > > On Mar 13, 2022, at 11:06 AM, Vanessa McHale wrote: > > I’m looking to appreciate “retro” Haskell projects, things from before > stabilization/company use. > > Such as: > > fgl https://web.engr.oregonstate.edu/~erwig/fgl/haskell/ > > WWWBrowser https://cth.altocumulus.org/~hallgren/wwwbrowser.html > > Balsa/Teak (languages) > http://apt.cs.manchester.ac.uk/projects/tools/balsa/ > > BlueSpec compiler https://github.com/B-Lang-org/bsc > > The CABAL spec (Common Architecture for Building Applications and Tools) > https://www.haskell.org/cabal/proposal/index.html > > Frag (that one Haskell game) https://wiki.haskell.org/Frag > > Hugs string extensions > https://www.haskell.org/hugs/pages/users_guide/here-documents.html > > I guess darcs/c2hs/happy/alex count, they have history! > > Bonus points for > > > - Makefiles to build the project > - Professor-HTML project page > - Hugs support > - Haskell 1.4 etc. support > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergueyz at gmail.com Sun Mar 13 19:48:21 2022 From: sergueyz at gmail.com (Serguey Zefirov) Date: Sun, 13 Mar 2022 22:48:21 +0300 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: Can Fudgets [1] qualify? [1] https://github.com/solomon-b/fudgets Right now it is cabalized but once upon a time it was very old school. I remember playing Invaders written in Fudgets in early 2000-s. вс, 13 мар. 2022 г. в 21:07, Vanessa McHale : > I’m looking to appreciate “retro” Haskell projects, things from before > stabilization/company use. > > Such as: > > fgl https://web.engr.oregonstate.edu/~erwig/fgl/haskell/ > > WWWBrowser https://cth.altocumulus.org/~hallgren/wwwbrowser.html > > Balsa/Teak (languages) > http://apt.cs.manchester.ac.uk/projects/tools/balsa/ > > BlueSpec compiler https://github.com/B-Lang-org/bsc > > The CABAL spec (Common Architecture for Building Applications and Tools) > https://www.haskell.org/cabal/proposal/index.html > > Frag (that one Haskell game) https://wiki.haskell.org/Frag > > Hugs string extensions > https://www.haskell.org/hugs/pages/users_guide/here-documents.html > > I guess darcs/c2hs/happy/alex count, they have history! > > Bonus points for > > > - Makefiles to build the project > - Professor-HTML project page > - Hugs support > - Haskell 1.4 etc. support > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.d.clayden at gmail.com Sun Mar 13 22:04:55 2022 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Mon, 14 Mar 2022 11:04:55 +1300 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate Message-ID: Hi Vanessa, in the same mould as 'Here documents' there's Hugs Extensible records /TRex https://www.haskell.org/hugs/pages/hugsman/exts.html#sect7.2 Not sure whether it counts as "retro": it still works, and is still superior to H2010 Datatype records (with GHC's extensions). AntC > I’m looking to appreciate “retro” Haskell projects, things from before stabilization/company use. > > Such as: > > > Hugs string extensions https://www.haskell.org/hugs/pages/users_guide/here-documents.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From noteed at gmail.com Mon Mar 14 00:14:57 2022 From: noteed at gmail.com (Vo Minh Thu) Date: Mon, 14 Mar 2022 01:14:57 +0100 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: I would look up Paul Hudak, Conal Elliott, and Oleg Kiselyov work (Fran, Yampa,...). Maybe some classic papers about implementing a Haskell type checker or compiler, but I don't know if they come with source code. Maybe xmonad qualifies? I also think Don had a mpd client. As you talked about BlueSpec, this makes me think of copilot. Maybe some solutions to some ICFP contests. There is a video game, "kitty and the robots", or something like that. I wonder if they open sourced their code. Cheers, Thu Le dim. 13 mars 2022 à 20:50, Serguey Zefirov a écrit : > Can Fudgets [1] qualify? > > [1] https://github.com/solomon-b/fudgets > > Right now it is cabalized but once upon a time it was very old school. I > remember playing Invaders written in Fudgets in early 2000-s. > > вс, 13 мар. 2022 г. в 21:07, Vanessa McHale : > >> I’m looking to appreciate “retro” Haskell projects, things from before >> stabilization/company use. >> >> Such as: >> >> fgl https://web.engr.oregonstate.edu/~erwig/fgl/haskell/ >> >> WWWBrowser https://cth.altocumulus.org/~hallgren/wwwbrowser.html >> >> Balsa/Teak (languages) >> http://apt.cs.manchester.ac.uk/projects/tools/balsa/ >> >> BlueSpec compiler https://github.com/B-Lang-org/bsc >> >> The CABAL spec (Common Architecture for Building Applications and Tools) >> https://www.haskell.org/cabal/proposal/index.html >> >> Frag (that one Haskell game) https://wiki.haskell.org/Frag >> >> Hugs string extensions >> https://www.haskell.org/hugs/pages/users_guide/here-documents.html >> >> I guess darcs/c2hs/happy/alex count, they have history! >> >> Bonus points for >> >> >> - Makefiles to build the project >> - Professor-HTML project page >> - Hugs support >> - Haskell 1.4 etc. support >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadine.and.henry at pobox.com Mon Mar 14 03:43:14 2022 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Sun, 13 Mar 2022 20:43:14 -0700 Subject: [Haskell-cafe] Why is this package being compiled In-Reply-To: <87bkyandsn.fsf@pobox.com> References: <87bkyandsn.fsf@pobox.com> Message-ID: <87r17542st.fsf@pobox.com> Thank you Henning, Vanessa, and Fendor. I was not aware of cabal-plan. It is a great tool. Thank you for pointing me to it. I also did not think of using constraints to discover dependencies. Best wishes,, Nadine and Henry Laxen The rest is silence From frederic-emmanuel.picca at synchrotron-soleil.fr Mon Mar 14 13:13:19 2022 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Mon, 14 Mar 2022 14:13:19 +0100 (CET) Subject: [Haskell-cafe] bracket and type family Message-ID: <471431693.24354937.1647263599512.JavaMail.zimbra@synchrotron-soleil.fr> Hello I try to have a generic way to open and close ressources for my software class DataResource a where data OpenedDataResource a :: * acquireDataResource :: a -> IO (OpenedDataResource a) releaseDataResource :: OpenedDataResource a -> IO () the idea is to have a generic method like this withDataResource :: DataResource a => a -> (OpenedDataResource a -> IO r) -> IO r withDataResource r = bracket (acquireDataResource r) releaseDataResource and later another one for the bracket of Pipes. So I try with something simple -- File newtype H5FilePath = H5FilePath FilePath instance DataResource H5FilePath where data OpenedDataResource H5FilePath = File acquireDataResource (H5FilePath f) = openFile (pack f) [ReadOnly] Nothing releaseDataResource = closeFile but I end up with this sort of error src/Hkl/H5.hs:231:40: error: • Couldn't match type ‘File’ with ‘OpenedDataResource H5FilePath’ Expected type: IO (OpenedDataResource H5FilePath) Actual type: IO File • In the expression: openFile (pack f) [ReadOnly] Nothing In an equation for ‘acquireDataResource’: acquireDataResource (H5FilePath f) = openFile (pack f) [ReadOnly] Nothing In the instance declaration for ‘DataResource H5FilePath’ | 231 | acquireDataResource (H5FilePath f) = openFile (pack f) [ReadOnly] Nothing | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ src/Hkl/H5.hs:232:25: error: • Couldn't match type ‘OpenedDataResource H5FilePath’ with ‘File’ Expected type: OpenedDataResource H5FilePath -> IO () Actual type: File -> IO () • In the expression: closeFile In an equation for ‘releaseDataResource’: releaseDataResource = closeFile In the instance declaration for ‘DataResource H5FilePath’ | 232 | releaseDataResource = closeFile | ^^^^^^^^^ cabal: Failed to build hkl-0.1.0.0 (which is required by exe:binoculars-ng from hkl-0.1.0.0). I do not understand why ? and more seriously, I do not know how to fix this. thanks for your help Frederic From lemming at henning-thielemann.de Mon Mar 14 13:32:30 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 14 Mar 2022 14:32:30 +0100 (CET) Subject: [Haskell-cafe] bracket and type family In-Reply-To: <471431693.24354937.1647263599512.JavaMail.zimbra@synchrotron-soleil.fr> References: <471431693.24354937.1647263599512.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <1e454fa-e763-d1f1-19de-531163553d6@henning-thielemann.de> On Mon, 14 Mar 2022, PICCA Frederic-Emmanuel wrote: > So I try with something simple > > -- File > > newtype H5FilePath = H5FilePath FilePath > > instance DataResource H5FilePath where > data OpenedDataResource H5FilePath = File > acquireDataResource (H5FilePath f) = openFile (pack f) [ReadOnly] Nothing > releaseDataResource = closeFile > > but I end up with this sort of error It means that openFile returns File type but your instance requires that it returns OpenedDataResource H5FilePath. That is, you must wrap the result of openFile in the File data constructor. I.e.: acquireDataResource (H5FilePath f) = File <$> openFile (pack f) [ReadOnly] Nothing releaseDataResource (File f) = closeFile f Since you used "data" instead of "type" in your type class, your data types are custom types per instance. From ivanperezdominguez at gmail.com Mon Mar 14 15:12:09 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Mon, 14 Mar 2022 11:12:09 -0400 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: For info: Yampa's development continues to this day, and there have been several mobile (iOS/Android) games released that use Yampa. There are also some demo/open source games. All of that is listed on the Yampa website. Source: I'm the maintainer of Yampa, and I founded the company that released such games. Copilot's development also continues. Source: I'm the technical lead of Copilot. Ivan On Sun, 13 Mar 2022 at 20:16, Vo Minh Thu wrote: > I would look up Paul Hudak, Conal Elliott, and Oleg Kiselyov work (Fran, > Yampa,...). > > Maybe some classic papers about implementing a Haskell type checker or > compiler, but I don't know if they come with source code. > > Maybe xmonad qualifies? > > I also think Don had a mpd client. > > As you talked about BlueSpec, this makes me think of copilot. > > Maybe some solutions to some ICFP contests. > > There is a video game, "kitty and the robots", or something like that. I > wonder if they open sourced their code. > > Cheers, > Thu > > Le dim. 13 mars 2022 à 20:50, Serguey Zefirov a > écrit : > >> Can Fudgets [1] qualify? >> >> [1] https://github.com/solomon-b/fudgets >> >> Right now it is cabalized but once upon a time it was very old school. I >> remember playing Invaders written in Fudgets in early 2000-s. >> >> вс, 13 мар. 2022 г. в 21:07, Vanessa McHale : >> >>> I’m looking to appreciate “retro” Haskell projects, things from before >>> stabilization/company use. >>> >>> Such as: >>> >>> fgl https://web.engr.oregonstate.edu/~erwig/fgl/haskell/ >>> >>> WWWBrowser https://cth.altocumulus.org/~hallgren/wwwbrowser.html >>> >>> Balsa/Teak (languages) >>> http://apt.cs.manchester.ac.uk/projects/tools/balsa/ >>> >>> BlueSpec compiler https://github.com/B-Lang-org/bsc >>> >>> The CABAL spec (Common Architecture for Building Applications and Tools) >>> https://www.haskell.org/cabal/proposal/index.html >>> >>> Frag (that one Haskell game) https://wiki.haskell.org/Frag >>> >>> Hugs string extensions >>> https://www.haskell.org/hugs/pages/users_guide/here-documents.html >>> >>> I guess darcs/c2hs/happy/alex count, they have history! >>> >>> Bonus points for >>> >>> >>> - Makefiles to build the project >>> - Professor-HTML project page >>> - Hugs support >>> - Haskell 1.4 etc. support >>> >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Mon Mar 14 15:15:53 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Mon, 14 Mar 2022 11:15:53 -0400 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: Also, because projects are difficult to maintain, anything that reduces the maintenance burden would help keep them up to date. There is a (non-official) proposal to re-implement fudgets on top of Monadic Stream Functions (https://github.com/ivanperez-keera/dunai/). That would likely 1) lower the maintenance burden on the Fudgets side and 2) serve as a large use case for MSFs. Ivan On Mon, 14 Mar 2022 at 11:12, Ivan Perez wrote: > For info: Yampa's development continues to this day, and there have been > several mobile (iOS/Android) games released that use Yampa. There are also > some demo/open source games. All of that is listed on the Yampa website. > Source: I'm the maintainer of Yampa, and I founded the company that > released such games. > > Copilot's development also continues. Source: I'm the technical lead of > Copilot. > > Ivan > > > > On Sun, 13 Mar 2022 at 20:16, Vo Minh Thu wrote: > >> I would look up Paul Hudak, Conal Elliott, and Oleg Kiselyov work (Fran, >> Yampa,...). >> >> Maybe some classic papers about implementing a Haskell type checker or >> compiler, but I don't know if they come with source code. >> >> Maybe xmonad qualifies? >> >> I also think Don had a mpd client. >> >> As you talked about BlueSpec, this makes me think of copilot. >> >> Maybe some solutions to some ICFP contests. >> >> There is a video game, "kitty and the robots", or something like that. I >> wonder if they open sourced their code. >> >> Cheers, >> Thu >> >> Le dim. 13 mars 2022 à 20:50, Serguey Zefirov a >> écrit : >> >>> Can Fudgets [1] qualify? >>> >>> [1] https://github.com/solomon-b/fudgets >>> >>> Right now it is cabalized but once upon a time it was very old school. I >>> remember playing Invaders written in Fudgets in early 2000-s. >>> >>> вс, 13 мар. 2022 г. в 21:07, Vanessa McHale : >>> >>>> I’m looking to appreciate “retro” Haskell projects, things from before >>>> stabilization/company use. >>>> >>>> Such as: >>>> >>>> fgl https://web.engr.oregonstate.edu/~erwig/fgl/haskell/ >>>> >>>> WWWBrowser https://cth.altocumulus.org/~hallgren/wwwbrowser.html >>>> >>>> Balsa/Teak (languages) >>>> http://apt.cs.manchester.ac.uk/projects/tools/balsa/ >>>> >>>> BlueSpec compiler https://github.com/B-Lang-org/bsc >>>> >>>> The CABAL spec (Common Architecture for Building Applications and >>>> Tools) https://www.haskell.org/cabal/proposal/index.html >>>> >>>> Frag (that one Haskell game) https://wiki.haskell.org/Frag >>>> >>>> Hugs string extensions >>>> https://www.haskell.org/hugs/pages/users_guide/here-documents.html >>>> >>>> I guess darcs/c2hs/happy/alex count, they have history! >>>> >>>> Bonus points for >>>> >>>> >>>> - Makefiles to build the project >>>> - Professor-HTML project page >>>> - Hugs support >>>> - Haskell 1.4 etc. support >>>> >>>> _______________________________________________ >>>> 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. >>> >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Mon Mar 14 15:28:47 2022 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Mon, 14 Mar 2022 16:28:47 +0100 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate Message-ID: > I’m looking to appreciate “retro” Haskell projects, If "retro" = "old", then look at this from 1997 https://github.com/jwaldmann/rx (state at first commit) And, I second what others have suggested: Paul Hudak: Haskore, https://web.archive.org/web/19970206084830/http://haskell.cs.yale.edu:80/haskore/ Peter Thiemann: Wash, http://www2.informatik.uni-freiburg.de/~thiemann/haskell/WASH/ The pinnacle of Haskell retrocomputing certainly is https://downloads.haskell.org/~ghc/0.29/ > ... things from before stabilization/company use. Haskell(98,2010) does have stability: language and core libraries adhere to the report. It's the companies that are destroying it :-) But you're right, they also spend effort on stabilization. When I cabalized my project in/around 2014, I was pleasantly surprised how little change it needed. Basically, just build-depend: haskell98. Don't read the actual source too closely - it's full of Lists and Ints, because, well .. little did I know at the time. On the other hand: naive means of expression, combined with absence, or ignorance, of libraries - makes future-proof software. Will you tell us the results of your appreciations? Are you "just" collecting sources? (already that is worthwhile) Compiling them? Running? Benchmarking? Writing a paper? I'd love to read that. - J.W. From jamesbtobin at gmail.com Tue Mar 15 11:18:37 2022 From: jamesbtobin at gmail.com (James Tobin) Date: Tue, 15 Mar 2022 11:18:37 +0000 Subject: [Haskell-cafe] JOB | Developers (Edinburgh) Message-ID: Hello, I'm working with a global fintech company looking to hire for their new office in Edinburgh. Should there be frontend or backend people that work with the likes of Core Java, Javascript, Typescript, React, RxJS interested in forming a small development squad do get in touch. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James From juhpetersen at gmail.com Wed Mar 16 12:52:12 2022 From: juhpetersen at gmail.com (Jens Petersen) Date: Wed, 16 Mar 2022 20:52:12 +0800 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.2 is now available In-Reply-To: <87r17ewuxe.fsf@smart-cactus.org> References: <87r17ewuxe.fsf@smart-cactus.org> Message-ID: On Mon, 7 Mar 2022 at 07:02, Ben Gamari wrote: > The GHC developers are very happy to at announce the availability of GHC > > 9.2.2. > Great, thank you! I have updated the Fedora ghc9.2 package to 9.2.2. So if you are running Fedora 35 or higher you can install it now from the updates-testing repo. Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Wed Mar 16 16:38:29 2022 From: vamchale at gmail.com (Vanessa McHale) Date: Wed, 16 Mar 2022 09:38:29 -0700 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.2 is not available In-Reply-To: <87r17ewuxe.fsf@smart-cactus.org> References: <87r17ewuxe.fsf@smart-cactus.org> Message-ID: <991892FD-1F54-40DF-B188-9564CCD61BCC@gmail.com> Thanks all! This makes M1 a much more feasible platform now that the NCG works - it is 2x faster to compile than the LLVM backend! > On Mar 6, 2022, at 2:59 PM, Ben Gamari wrote: > > > The GHC developers are very happy to at announce the availability of GHC > 9.2.2. Binary distributions, source distributions, and documentation are > available at downloads.haskell.org: > > https://downloads.haskell.org/ghc/9.2.2 > > This release includes many bug-fixes and other improvements to 9.2.1 including: > > * A number of bug-fixes in the new AArch64 native code generator > > * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is handled > correctly on platforms lacking support for unaligned memory accesses > (#21015, #20987). > > * Improvements to the compatibility story in GHC's migration to the > XDG Base Directory Specification (#20684, #20669, #20660) > > * Restored compatibility with Windows 7 > > * A new `-fcompact-unwind` flag, improving compatibility with C++ libraries on > Apple Darwin (#11829) > > * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime bounds > checking of array primops (#20769) > > * Unboxing of unlifted types (#20663) > > * Numerous improvements in compiler performance. > > * Many, many others. See the [release notes] for a full list. > > As some of the fixed issues do affect correctness users are encouraged to > upgrade promptly. > > Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake > pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous > contributors whose on-going financial and in-kind support has > facilitated GHC maintenance and release management over the years. > Moreover, this release would not have been possible without the hundreds > of open-source contributors whose work comprise this release. > > As always, do open a [ticket][] if you see anything amiss. > > Happy compiling, > > - Ben > > > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [release notes]: https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html > _______________________________________________ > 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. From john at yourdigitalvoice.net Thu Mar 17 04:52:56 2022 From: john at yourdigitalvoice.net (John Sinclair) Date: Thu, 17 Mar 2022 17:52:56 +1300 Subject: [Haskell-cafe] Functional Conf 2022 - March 24-26 online - registrations closing soon Message-ID: Hey Haskellers, It is just a week until Functional Conf 2022 kicks off online. We hope you will be among the 400+ attendees we expect at the conference. Learn more and register: https://confng.in/cHeBoXDf We have an exciting lineup of speakers for you this year including a keynote from Bartosz Milewski a guru of Haskell and Category Theory. You can check the full schedule here: https://confng.in/WCrltlIO This year, we are pleased to present Haskell talks by: - Bartosz Milewski (Author of "Category Theory for Programmers") - Tony Morris (Software Engineer @ Simple Machines) - Michael Snoyman (VP, Engineering @ FP Complete) - Curtis D'Alves (Ph.D Candidate @ McMaster University) - Evie Ciobanu (Senior Haskell Engineer @ Hasura) - Christopher Anand (Associate Professor @ McMaster University) - Siddharth Bhat (Student @ IIIT Hyderabad) - Saurabh Nanda (Founder @ Vacation Labs) - Quy Dai Nhan Thai (Software Engineer @ Google) - Auke Booij (Haskell Engineer @ Hasura) The conference is broader than just Haskell talks and offers an excellent opportunity to expand your understanding of what is happening in the world of functional programming. There will be opportunities for networking and socialising with other attendees in video hangouts, who knows who you might meet? The talks will be streamed via Zoom on the confengine.com platform. You can check out the talks from the last (in-person) Functional Conf on YouTube: https://confng.in/niusPTYB With exceptional speakers, enthusiastic learners and a supportive community of functional programmers you don't want to miss this! Register now to save your place: https://confng.in/_3SLI-9u -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Sat Mar 19 16:56:48 2022 From: vamchale at gmail.com (Vanessa McHale) Date: Sat, 19 Mar 2022 11:56:48 -0500 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: Hm found some more! HBC - compiler for Haskell 1.4 https://www2.ki.informatik.uni-frankfurt.de/doc/html/hbc/hbc.html JHC - just for fun http://repetae.net/computer/jhc/ HLearn - an ambitious, Haskell-y project https://github.com/mikeizbicki/HLearn Kansas Lava - part of the classic, Haskell+Hardware https://ku-fpg.github.io/software/kansas-lava/ rx looks quite fun! Gotta study those grammars myself… tidal - not so retro but seems indie? cool spirit I think? http://tidalcycles.org http://hakaru-dev.github.io/intro/quickstart/ https://kittenlang.org https://www.egison.org ^ not so retro but cool languages with a good spirit https://wiki.haskell.org/ThreadScope > On Mar 14, 2022, at 10:28 AM, Johannes Waldmann wrote: > >> I’m looking to appreciate “retro” Haskell projects, > > If "retro" = "old", then look at this from 1997 > https://github.com/jwaldmann/rx (state at first commit) > > And, I second what others have suggested: > Paul Hudak: Haskore, > https://web.archive.org/web/19970206084830/http://haskell.cs.yale.edu:80/haskore/ > Peter Thiemann: Wash, > http://www2.informatik.uni-freiburg.de/~thiemann/haskell/WASH/ > > The pinnacle of Haskell retrocomputing certainly is > https://downloads.haskell.org/~ghc/0.29/ > >> ... things from before stabilization/company use. > > Haskell(98,2010) does have stability: > language and core libraries adhere to the report. > > It's the companies that are destroying it :-) > But you're right, they also spend effort on stabilization. > > When I cabalized my project in/around 2014, > I was pleasantly surprised how little change it needed. > Basically, just build-depend: haskell98. > > Don't read the actual source too closely - it's full of > Lists and Ints, because, well .. little did I know at the time. > On the other hand: naive means of expression, combined with > absence, or ignorance, of libraries - makes future-proof software. > > Will you tell us the results of your appreciations? > Are you "just" collecting sources? (already that is worthwhile) > Compiling them? Running? Benchmarking? > Writing a paper? I'd love to read that. > > - J.W. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Sat Mar 19 20:46:47 2022 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Sat, 19 Mar 2022 21:46:47 +0100 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: <11bd159f-bd8b-75f0-e664-3c53e635842f@htwk-leipzig.de> > HBC - by Lennart Augustsson > compiler for Haskell One of the first! (Yale Haskell 1988, GHC 1989, HBC 1990) Written in lazy ML, though. Check the sources at https://archive.org/details/haskell-b-compiler Also, https://wiki.haskell.org/News/1988 (and following) https://github.com/haskell-lisp/yale-haskell - J.W. From dreixel at gmail.com Sun Mar 20 16:00:47 2022 From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=) Date: Sun, 20 Mar 2022 16:00:47 +0000 Subject: [Haskell-cafe] Haskell internships with Standard Chartered Bank in the UK Message-ID: All details at https://discourse.haskell.org/t/haskell-internships-with-standard-chartered-bank-in-the-uk/4235 Cheers, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Sun Mar 20 16:59:11 2022 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 21 Mar 2022 00:59:11 +0800 Subject: [Haskell-cafe] [announce] Stackage LTS 19 (ghc-9.0) & Nightly moved to ghc-9.2 Message-ID: The Stackage Team is happy to announce the first release of the stable LTS 19 series of package sets over GHC 9.0.2: https://www.stackage.org/lts-19.0 We are also excited to announce that Nightly has been updated to use ghc-9.2.2 (thanks to heroic work by Adam Bergmark)! You can find a few more details in the short accompanying post: https://www.stackage.org/blog/2022/03/announce-lts-19-nightly-ghc9.2 Thank you to everyone in the Haskell community who contributed to make these new releases possible! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikhil at acm.org Mon Mar 21 20:54:37 2022 From: nikhil at acm.org (Rishiyur Nikhil) Date: Mon, 21 Mar 2022 16:54:37 -0400 Subject: [Haskell-cafe] Retro/indie Haskell to appreciate In-Reply-To: References: Message-ID: > I’m looking to appreciate “retro” Haskell projects, things from before stabilization/company use. > Such as: > ... > BlueSpec compiler https://github.com/B-Lang-org/bsc Note, the Bluespec compiler, though written in "retro" Haskell, remains in daily production use (as it has been, for 2 decades). Another project, written a few years ago but in totally "retro" style is Forvis, a complete executable spec for the RISC-V instruction set: https://github.com/rsnikhil/Forvis_RISCV-ISA-Spec Covers RV32 and RV64; unprivileged and privileged: unprivileged ISA: I (basic integer) M (integer multiply/divide) A (atomics) F, D (single and double precision floating point) C (compressed) privileged ISA: M (machine), S (supervisor) and U (user modes) Sv32, Sv39 and Sv48 virtual memory and has successfully booted a Linux kernel. Rgds, Nikhil -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Wed Mar 23 08:56:29 2022 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Wed, 23 Mar 2022 09:56:29 +0100 Subject: [Haskell-cafe] Call for Talks: Haskell Implementors' Workshop 2022 Message-ID: <20F7F799-892E-47A3-BED1-EAAC629E09DF@getmailspring.com> (apologies for multiple copies of this message) ACM SIGPLAN Haskell Implementors' Workshop https://icfp22.sigplan.org/home/hiw-2022 Ljubljana, Slovenia, 11 September 2022 Co-located with ICFP 2022 https://icfp22.sigplan.org/ Important dates --------------- Deadline: 11 July, 2022 (AoE) Notification: 11 August, 2022 Workshop: 11 September, 2022 The 14th Haskell Implementors' Workshop is to be held alongside ICFP 2022 this year in Ljubljana. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2022. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfphiw22.hotcrp.com until July 11th (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Pepe Iborra (Meta) * Gabrielle Keller (Utrecht University) * Emily Pilmore (Kadena) * Vladislav Zavialov (Serokell) * Alejandro Serrano (Tweag) Contact ------- * Alejandro Serrano -------------- next part -------------- An HTML attachment was scrubbed... URL: From goemansrowan at gmail.com Wed Mar 23 14:48:12 2022 From: goemansrowan at gmail.com (rowan goemans) Date: Wed, 23 Mar 2022 15:48:12 +0100 Subject: [Haskell-cafe] inference with implicitparams seems broken Message-ID: <766b6a94-18d0-dbcb-d2ac-dcc3e48ce93f@gmail.com> Hello everyone, I wonder why the following taken from an stackoverflow answer doesn't work: https://stackoverflow.com/questions/71184922/is-it-possible-to-infer-a-type-that-is-a-reflection-like-closure. Code of the answer posted here verbatim: ``` {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE RankNTypes #-} module Temp where withX :: Int -> ((?x :: Int) => r) -> r withX x r =   let ?x = x   in r somethingThanNeedsX :: (?x :: Int) => Int somethingThanNeedsX = ?x + 2 foo :: Int foo = bar   where     bar = withX 42 baz     baz = somethingThanNeedsX ``` This won't compile with the error message: ``` Orig.hs:19:11: error:     • Unbound implicit parameter (?x::Int)         arising from a use of ‘somethingThanNeedsX’     • In the expression: somethingThanNeedsX       In an equation for ‘baz’: baz = somethingThanNeedsX       In an equation for ‘foo’:           foo             = bar             where                 bar = withX 42 baz                 baz = somethingThanNeedsX    | 19 |     baz = somethingThanNeedsX ``` If you give `baz` a type signature which includes the implicit param it compiles. But I think this is a bug. GHC should not require a type signature here. I tried searching for a GHC ticket but I couldn't find one. But that might also be down to me not using the right query. Anyway my question is, is this expected behavior? This really makes implicit params less ergonomic. Best regards, Rowan Goemans From jaro.reinders at gmail.com Wed Mar 23 14:56:09 2022 From: jaro.reinders at gmail.com (J. Reinders) Date: Wed, 23 Mar 2022 15:56:09 +0100 Subject: [Haskell-cafe] inference with implicitparams seems broken In-Reply-To: <766b6a94-18d0-dbcb-d2ac-dcc3e48ce93f@gmail.com> References: <766b6a94-18d0-dbcb-d2ac-dcc3e48ce93f@gmail.com> Message-ID: It’s due to the monomorphism restriction [1]. If you give `baz` an argument it does infer the type correctly: ``` foo :: Int foo = bar where bar = withX 42 (baz ()) baz () = somethingThanNeedsX ``` Or you can disable the monomorphism restriction: ``` {-# LANGUAGE NoMonomorphismRestriction #-} ``` [1] https://wiki.haskell.org/Monomorphism_restriction > On 23 Mar 2022, at 15:48, rowan goemans wrote: > > Hello everyone, > > I wonder why the following taken from an stackoverflow answer doesn't work: https://stackoverflow.com/questions/71184922/is-it-possible-to-infer-a-type-that-is-a-reflection-like-closure. Code of the answer posted here verbatim: > > ``` > {-# LANGUAGE ImplicitParams #-} > {-# LANGUAGE RankNTypes #-} > > module Temp where > > withX :: Int -> ((?x :: Int) => r) -> r > withX x r = > let ?x = x > in r > > somethingThanNeedsX :: (?x :: Int) => Int > somethingThanNeedsX = ?x + 2 > > foo :: Int > foo = bar > where > bar = withX 42 baz > > baz = somethingThanNeedsX > ``` > > This won't compile with the error message: > > ``` > Orig.hs:19:11: error: > • Unbound implicit parameter (?x::Int) > arising from a use of ‘somethingThanNeedsX’ > • In the expression: somethingThanNeedsX > In an equation for ‘baz’: baz = somethingThanNeedsX > In an equation for ‘foo’: > foo > = bar > where > bar = withX 42 baz > baz = somethingThanNeedsX > | > 19 | baz = somethingThanNeedsX > ``` > > If you give `baz` a type signature which includes the implicit param it compiles. But I think this is a bug. GHC should not require a type signature here. I tried searching for a GHC ticket but I couldn't find one. But that might also be down to me not using the right query. > > Anyway my question is, is this expected behavior? This really makes implicit params less ergonomic. > > Best regards, > > Rowan Goemans > > _______________________________________________ > 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. From goemansrowan at gmail.com Thu Mar 24 13:04:34 2022 From: goemansrowan at gmail.com (rowan goemans) Date: Thu, 24 Mar 2022 14:04:34 +0100 Subject: [Haskell-cafe] inference with implicitparams seems broken In-Reply-To: References: <766b6a94-18d0-dbcb-d2ac-dcc3e48ce93f@gmail.com> Message-ID: <022e507b-d747-0370-487c-77f137f67bef@gmail.com> Indeed, with the monomorphism restriction disabled it works without issues. is this by design/expected though? Morally I feel it is already monomorph, it's just missing an argument which needs to be provided. Would there be interest in fixing this in GHC? On 3/23/22 15:56, J. Reinders wrote: > It’s due to the monomorphism restriction [1]. If you give `baz` an argument it does infer the type correctly: > > ``` > foo :: Int > foo = bar > where > bar = withX 42 (baz ()) > baz () = somethingThanNeedsX > ``` > > Or you can disable the monomorphism restriction: > > ``` > {-# LANGUAGE NoMonomorphismRestriction #-} > ``` > > [1] https://wiki.haskell.org/Monomorphism_restriction > >> On 23 Mar 2022, at 15:48, rowan goemans wrote: >> >> Hello everyone, >> >> I wonder why the following taken from an stackoverflow answer doesn't work: https://stackoverflow.com/questions/71184922/is-it-possible-to-infer-a-type-that-is-a-reflection-like-closure. Code of the answer posted here verbatim: >> >> ``` >> {-# LANGUAGE ImplicitParams #-} >> {-# LANGUAGE RankNTypes #-} >> >> module Temp where >> >> withX :: Int -> ((?x :: Int) => r) -> r >> withX x r = >> let ?x = x >> in r >> >> somethingThanNeedsX :: (?x :: Int) => Int >> somethingThanNeedsX = ?x + 2 >> >> foo :: Int >> foo = bar >> where >> bar = withX 42 baz >> >> baz = somethingThanNeedsX >> ``` >> >> This won't compile with the error message: >> >> ``` >> Orig.hs:19:11: error: >> • Unbound implicit parameter (?x::Int) >> arising from a use of ‘somethingThanNeedsX’ >> • In the expression: somethingThanNeedsX >> In an equation for ‘baz’: baz = somethingThanNeedsX >> In an equation for ‘foo’: >> foo >> = bar >> where >> bar = withX 42 baz >> baz = somethingThanNeedsX >> | >> 19 | baz = somethingThanNeedsX >> ``` >> >> If you give `baz` a type signature which includes the implicit param it compiles. But I think this is a bug. GHC should not require a type signature here. I tried searching for a GHC ticket but I couldn't find one. But that might also be down to me not using the right query. >> >> Anyway my question is, is this expected behavior? This really makes implicit params less ergonomic. >> >> Best regards, >> >> Rowan Goemans >> >> _______________________________________________ >> 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. From lists at richarde.dev Thu Mar 24 19:05:56 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 24 Mar 2022 19:05:56 +0000 Subject: [Haskell-cafe] inference with implicitparams seems broken In-Reply-To: <022e507b-d747-0370-487c-77f137f67bef@gmail.com> References: <766b6a94-18d0-dbcb-d2ac-dcc3e48ce93f@gmail.com> <022e507b-d747-0370-487c-77f137f67bef@gmail.com> Message-ID: <010f017fbd52381d-a86b123e-7216-4cd2-b2ae-3169c8717091-000000@us-east-2.amazonses.com> > On Mar 24, 2022, at 9:04 AM, rowan goemans wrote: > > is this by design/expected though? It is by design, yes. With a sufficiently nuanced expectation, I would also say it's expected. (Though, to be fair, if I were not primed to be thinking about the monomorphism restriction, I can't honestly say I would get it right if quizzed.) > Would there be interest in fixing this in GHC? Figuring out when to generalize a local binding is a hard problem. So, there is definitely interest in finding a better way to do it, but I don't think anyone knows a design that meets the most expectations. Language design is hard! :) Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From goemansrowan at gmail.com Thu Mar 24 21:37:30 2022 From: goemansrowan at gmail.com (rowan goemans) Date: Thu, 24 Mar 2022 22:37:30 +0100 Subject: [Haskell-cafe] inference with implicitparams seems broken In-Reply-To: <010f017fbd52381d-a86b123e-7216-4cd2-b2ae-3169c8717091-000000@us-east-2.amazonses.com> References: <766b6a94-18d0-dbcb-d2ac-dcc3e48ce93f@gmail.com> <022e507b-d747-0370-487c-77f137f67bef@gmail.com> <010f017fbd52381d-a86b123e-7216-4cd2-b2ae-3169c8717091-000000@us-east-2.amazonses.com> Message-ID: Hi Richard, Thanks for answering. I have made a tiny change to GHC in a fork that lifts the monomorphization restriction but only for implicit params. See this commit: https://gitlab.haskell.org/rowanG/ghc/-/merge_requests/1/diffs?commit_id=35fcad2d7f556706dd129a57815abe421a559861 Is there some example I could run to see in action why the monomorphisation restriction is required? I looked at the Haskell report and I don't immediately see why the points raised apply to implicit params. I get a feeling that monomorph(Contains only a concrete type like Int or Bool) implicit params would never be a problem and maybe only polymorphic ones are? Rowan Goemans On 3/24/22 20:05, Richard Eisenberg wrote: > > >> On Mar 24, 2022, at 9:04 AM, rowan goemans >> wrote: >> >> is this by design/expected though? > > It is by design, yes. With a sufficiently nuanced expectation, I would > also say it's expected. (Though, to be fair, if I were not primed to > be thinking about the monomorphism restriction, I can't honestly say I > would get it right if quizzed.) > >> Would there be interest in fixing this in GHC? > > Figuring out when to generalize a local binding is a hard problem. So, > there is definitely interest in finding a better way to do it, but I > don't think anyone knows a design that meets the most expectations. > Language design is hard! :) > > Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Fri Mar 25 19:17:13 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Fri, 25 Mar 2022 19:17:13 +0000 Subject: [Haskell-cafe] inference with implicitparams seems broken In-Reply-To: References: <766b6a94-18d0-dbcb-d2ac-dcc3e48ce93f@gmail.com> <022e507b-d747-0370-487c-77f137f67bef@gmail.com> <010f017fbd52381d-a86b123e-7216-4cd2-b2ae-3169c8717091-000000@us-east-2.amazonses.com> Message-ID: <010f017fc282e664-0b040474-b0a5-48e2-b855-0c3c38626635-000000@us-east-2.amazonses.com> Hi Rowan, The problem is that generalizing a let-binding turns something that looks like a constant into a function. This means that repeated use of the variable will evaluate it separately each time. This can be observed to slow down a program. A key point of the monomorphism restriction is to prevent non-functions from actually being functions. This applies equally well to implicit parameters as to other constraints. Richard > On Mar 24, 2022, at 5:37 PM, rowan goemans wrote: > > Hi Richard, > > Thanks for answering. I have made a tiny change to GHC in a fork that lifts the monomorphization restriction but only for implicit params. See this commit: https://gitlab.haskell.org/rowanG/ghc/-/merge_requests/1/diffs?commit_id=35fcad2d7f556706dd129a57815abe421a559861 > Is there some example I could run to see in action why the monomorphisation restriction is required? I looked at the Haskell report and I don't immediately see why the points raised apply to implicit params. I get a feeling that monomorph(Contains only a concrete type like Int or Bool) implicit params would never be a problem and maybe only polymorphic ones are? > > Rowan Goemans > > On 3/24/22 20:05, Richard Eisenberg wrote: >> >> >>> On Mar 24, 2022, at 9:04 AM, rowan goemans > wrote: >>> >>> is this by design/expected though? >> >> It is by design, yes. With a sufficiently nuanced expectation, I would also say it's expected. (Though, to be fair, if I were not primed to be thinking about the monomorphism restriction, I can't honestly say I would get it right if quizzed.) >> >>> Would there be interest in fixing this in GHC? >> >> Figuring out when to generalize a local binding is a hard problem. So, there is definitely interest in finding a better way to do it, but I don't think anyone knows a design that meets the most expectations. Language design is hard! :) >> >> Richard > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at glitchbra.in Sat Mar 26 07:54:52 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Sat, 26 Mar 2022 08:54:52 +0100 Subject: [Haskell-cafe] Accessing a MinGW/MSYS2 shell from Setup.hs Message-ID: Hi everyone, I am writing a custom Setup.hs to do an Autotools build for a bundled library. This is easy everywhere with `process` _except_ Windows, because I can't get a shell with the Autotools in them, despite there definitely being one. `process` gives me a cmd.exe shell, which wouldn't know about the Autotools, and on Windows, _any_ GHC installation has to have certain POSIX stuff available, which is why it bundles MinGW. Is the shell I get from that accessible from Setup.hs, via `process` or otherwise? Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From npolikarpova at eng.ucsd.edu Sat Mar 26 22:56:34 2022 From: npolikarpova at eng.ucsd.edu (Nadia Polikarpova) Date: Sat, 26 Mar 2022 15:56:34 -0700 Subject: [Haskell-cafe] Haskell Symposium 2022: Call for Papers Message-ID: ========================================================================= ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2022 Ljubljana, Slovenia Thu 15 -- Fri 16 September, 2022 http://www.haskell.org/haskell-symposium/2022/ ========================================================================= The ACM SIGPLAN Haskell Symposium 2022 will be co-located with the 2022 International Conference on Functional Programming (ICFP). Differently from previous years, Haskell'22 will use a single-track submission process (that is, we will only have the regular track and no early track). The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * Tutorials, to document how to use a particular language feature, programming technique, tool or library within the Haskell ecosystem; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. Like an experience report and a functional pearl, tutorials should make a contribution from which other Haskellers can benefit. What distinguishes a tutorial is that its focus is on explaining an aspect of the Haskell language and/or ecosystem in a way that is generally useful to a Haskell audience. Tutorials for many such topics can be found online; the distinction here is that by writing it up for formal review it will be vetted by experts and formally published. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. If your contribution is not a research paper, please mark the title of your experience report, functional pearl, tutorial or system demonstration as such, by supplying a subtitle (Experience Report, Functional Pearl, Tutorial Paper, System Demonstration). Submission Details ================== Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2022 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors' own related work should be in the third person (e.g., not "We build on our previous work" but rather "We build on the work of "). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Tutorial: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Abstract submission: 27 May 2022 (Fri) Paper submission: 3 June 2022 (Fri) Notification: 1 July 2022 (Fri) Deadlines are anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/), and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism). Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell22.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors can distinguish between anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the conference chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Proceedings =========== Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permission-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy (http://www.acm.org/publications/policies/copyright-policy) and ACM Author Rights (http://authors.acm.org/main.html). Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artifacts ========= Authors of accepted papers are encouraged to make auxiliary material (artifacts like source code, test data, etc.) available with their paper. They can opt to have these artifacts published alongside their paper in the ACM Digital Library (copyright of artifacts remains with the authors). If an accepted paper's artifacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artifacts Available badge (https://www.acm.org/publications/policies/artifact-review-badging#available). Applications for such a badge can be made after paper acceptance and will be reviewed by the PC chair. Program Committee ================= Lennart Augustsson Epic Games Jean-Philippe Bernardy University of Gothenburg Iavor Diatchki Galois, Inc Michael Gale Tweag William Hallahan Yale University Makoto Hamana Gumma University John Hughes Chalmers University of Technology Alexis King Tweag James Koppel Massachusets Institute of Technology Rudy Matela Dominic Orchard University of Kent Nadia Polikarpova (chair) University of California, San Diego Eric Seidel Bridgewater Associates Satnam Singh Groq Wouter Swierstra Utrecht University Hiroshi Unno University of Tsukuba Marco Vassena CISPA - Helmholtz-Zentrum Dimitrios Vytiniotis DeepMind If you have questions, please contact the chair at: npolikarpova at ucsd.edu ========================================================================= From teratux.mail at gmail.com Sun Mar 27 17:13:40 2022 From: teratux.mail at gmail.com (TeraTux) Date: Sun, 27 Mar 2022 19:13:40 +0200 Subject: [Haskell-cafe] Hatlab: My attempt to make a library inspired by Matlab and NumPy Message-ID: Greetings! I made a library which implements functions similar to those in Matlab or NumPy. The code is not much clean yet, you can see it at https://gitlab.com/Hume2/hatlab . The functions with comments are intended to be used. I want to know if it is a good start or I just wasted time. The matrices can have arbitrary dimensions, starting from 0D matrices, which are basically scalars. Operations like + - * / are element-wise. I also implemented broadcasting of these operations. I also implemented indexing. Some examples: a = matrix2D [[1,2,3],[4,5,6],[7,8,9]] a !# [2,2] -- element at index [2,2] a !$ [At 1, All] -- 1st row a !$ [To (-1), All] -- all rows except the last one a !$ [Where $ a ># 5] -- all elements bigger than 5 (The ># operator returns a matrix of bools, I will come to that later.) It is also possible to update a matrix. These operations do not copy all the elements from the original matrix, they just make another matrix which points to the original matrix at places where it was not changed. Some examples: a = eye 5 b = matrix2D [[1,2,3],[4,5,6],[7,8,9]] a !:[FromTo 1 4, FromTo 1 4]:= b -- replace the middle square by a different matrix a !:[FromTo 1 4, FromTo 1 4]:= 1 -- set all values in the middle square to 1 a !:[FromTo 1 4, FromTo 1 4]:+= 1 -- add one to all values in the middle square a !:[FromTo 1 4, FromTo 1 4]:$= cos -- replace all values in the middle square by their cosine Operators are broadcasted the same way as in Matlab or NumPy. If one operand has size 1 and the other one has size N or vice-versa in given dimension, the operator acts as if the thinner matrix was repeated in the given dimension N times. Example: a = matrix1D [10, 20, 30] -- row vector b = matrix2D [[1], [2], [3]] -- column vector a + b -- returns [[11, 21, 31], [12, 22, 32], [13, 23, 33]] There is a function "scalar" which creates a 0D matrix out of any value, so we can do: a + (scalar 5) -- returns [15, 25, 35] a * (scalar 2) -- returns [20, 40, 60] If a type is in the class Num, Fractional or Floating, the matrix of the given type is also in the given class. Conversions are performed using the function "scalar", so we can write: a + 5 a * 2 because the "5" and "2" are then interpreted as 0D matrices. Operator * is interpreted as element-wise multiplication. To do matrix multiplication, use the × operator. It can be also used to multiply matrices with vectors. Examples: v = matrix1D [1,2,3] m = matrix2D [[1,0,1],[2,-1,1],[0,1,-1]] v × m -- multiply row vector v with matrix m m × v -- multiply matrix m with column vector v m × m -- multiply matrix m by itself There are also functions for element-wise boolean operations. They work similarly and they have the # suffix. Examples: a = matrix2D [[True, True], [False, False]] b = matrix2D [[True, False], [True, False]] a &# b -- element-wise and a |# b -- element-wise or There are also element-wise comparison functions in a similar fashion. Examples: a = eye 3 b = ones [3,3] a ==# b -- returns a matrix of bools saying where the element of matrix a is equal to the corresponding element in matrix b. a <# b -- similar as above except that it tests for being less than instead of equality. a ==# 1 -- Broadcasting works for these operators too, so this syntax is valid also. There are also other functions not described in this mail. I will not describe them here because this mail is already too long. Don't worry asking me if you don't understand the meaning of any function from my comments. I did not implement any algorithms for linear equation solving, not even any other matrix algorithms yet. If this library has any potential, I may do that in the future. Please, let me know if this library has any potential or it was just a waste of time. Hume2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From leah at vuxu.org Sun Mar 27 20:10:29 2022 From: leah at vuxu.org (Leah Neukirchen) Date: Sun, 27 Mar 2022 22:10:29 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2022-03-30 @ 19:30 Message-ID: <87sfr39mx6.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Wednesday, March 30 at **Augustiner-Gaststätte Rumpler** at 19h30 CEST. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-mar-2022/ Everybody is welcome! Local COVID rules apply. cu, -- Leah Neukirchen https://leahneukirchen.org/ From goemansrowan at gmail.com Mon Mar 28 12:08:06 2022 From: goemansrowan at gmail.com (rowan goemans) Date: Mon, 28 Mar 2022 14:08:06 +0200 Subject: [Haskell-cafe] inference with implicitparams seems broken In-Reply-To: <010f017fc282e664-0b040474-b0a5-48e2-b855-0c3c38626635-000000@us-east-2.amazonses.com> References: <766b6a94-18d0-dbcb-d2ac-dcc3e48ce93f@gmail.com> <022e507b-d747-0370-487c-77f137f67bef@gmail.com> <010f017fbd52381d-a86b123e-7216-4cd2-b2ae-3169c8717091-000000@us-east-2.amazonses.com> <010f017fc282e664-0b040474-b0a5-48e2-b855-0c3c38626635-000000@us-east-2.amazonses.com> Message-ID: <177d1159-22ac-b3c1-26bd-cff76864b5d8@gmail.com> Hi Richard, I understand why the monomorphism restriction is in place. But I feel the reason about potentially repeated computations which are non-obvious aren't really applicable to implicit params. If you use a function with a different implicit param then I don't think anyone would be surprised that it is a different computations. Maybe I'm just not seeing it though. E.g. this is confusing if monomorphism restriction isn't enabled: ``` plus a b = a + b res = plus 6 10 usage1 :: Int usage1 = res usage2 :: Integer usage2 = res ``` as the potentially expensive `plus` computation is ran twice where a user wouldn't expect it to be evaluated twice. But something comparable with implicit params isn't confusing I think: ``` plus a = a + ?b res = plus 6 usage1 :: Int usage1 = let ?b = 10 in res usage2 :: Integer usage2 = let ?b = 10 in res ``` My main point though is whether this was something that was already discussed somewhere with the conclusion being that implicit params should really fall under the monomorphism restriction. Instead of it being an artifact of the current implementation in GHC. Because I would be quite interested in lifting it for implicit params. Rowan Goemans On 3/25/22 20:17, Richard Eisenberg wrote: > Hi Rowan, > > The problem is that generalizing a let-binding turns something that > looks like a constant into a function. This means that repeated use of > the variable will evaluate it separately each time. This can be > observed to slow down a program. A key point of the monomorphism > restriction is to prevent non-functions from actually being functions. > This applies equally well to implicit parameters as to other constraints. > > Richard > >> On Mar 24, 2022, at 5:37 PM, rowan goemans >> wrote: >> >> Hi Richard, >> >> Thanks for answering. I have made a tiny change to GHC in a fork that >> lifts the monomorphization restriction but only for implicit params. >> See this commit: >> https://gitlab.haskell.org/rowanG/ghc/-/merge_requests/1/diffs?commit_id=35fcad2d7f556706dd129a57815abe421a559861 >> >> Is there some example I could run to see in action why the >> monomorphisation restriction is required? I looked at the Haskell >> report and I don't immediately see why the points raised apply to >> implicit params. I get a feeling that monomorph(Contains only a >> concrete type like Int or Bool) implicit params would never be a >> problem and maybe only polymorphic ones are? >> >> Rowan Goemans >> >> On 3/24/22 20:05, Richard Eisenberg wrote: >>> >>> >>>> On Mar 24, 2022, at 9:04 AM, rowan goemans >>>> wrote: >>>> >>>> is this by design/expected though? >>> >>> It is by design, yes. With a sufficiently nuanced expectation, I >>> would also say it's expected. (Though, to be fair, if I were not >>> primed to be thinking about the monomorphism restriction, I can't >>> honestly say I would get it right if quizzed.) >>> >>>> Would there be interest in fixing this in GHC? >>> >>> Figuring out when to generalize a local binding is a hard problem. >>> So, there is definitely interest in finding a better way to do it, >>> but I don't think anyone knows a design that meets the most >>> expectations. Language design is hard! :) >>> >>> Richard >> _______________________________________________ >> 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From godzbanebane at gmail.com Mon Mar 28 14:14:44 2022 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Mon, 28 Mar 2022 17:14:44 +0300 Subject: [Haskell-cafe] Can't use TypeApplications with polymorphic let bind Message-ID: Dear Cafe, I recently came upon this little "type-inference puzzle". Can anyone shine some light on why the third example doesn't compile? ``` {-# LANGUAGE TypeApplications #-} -- doesn't work -- I expect this, not sure why it happens {- class C m where   c :: () -> m instance C Int where   c () = 0 instance C Bool where   c () = False f :: (Int, Bool) f =   let x = c    in    (x (), x ()) -} -- works -- I expect this, not sure why it happens {- class C m where   c :: () -> m instance C Int where   c () = 0 instance C Bool where   c () = False f :: (Int, Bool) f =   let x u = c u    in    (x (), x ()) -} -- doesn't work -- I don't expect this, not sure why it happens {- class C m where   c :: () -> m instance C Int where   c () = 0 instance C Bool where   c () = False f :: (Int, Bool) f =   let x u = c u    in    (x @Int (), x @Bool ()) -- wtf.hs:54:5: error: --     • Cannot apply expression of type ‘() -> m0’ --       to a visible type argument ‘Int’ --     • In the expression: x @Int () --       In the expression: (x @Int (), x @Bool ()) --       In the expression: let x u = c u in (x @Int (), x @Bool ()) --    | -- 54 |    (x @Int (), x @Bool ()) --    |     ^^^^^^^^^ -} ``` Cheers, Georgi From lists at richarde.dev Mon Mar 28 19:33:05 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 28 Mar 2022 19:33:05 +0000 Subject: [Haskell-cafe] inference with implicitparams seems broken In-Reply-To: <177d1159-22ac-b3c1-26bd-cff76864b5d8@gmail.com> References: <766b6a94-18d0-dbcb-d2ac-dcc3e48ce93f@gmail.com> <022e507b-d747-0370-487c-77f137f67bef@gmail.com> <010f017fbd52381d-a86b123e-7216-4cd2-b2ae-3169c8717091-000000@us-east-2.amazonses.com> <010f017fc282e664-0b040474-b0a5-48e2-b855-0c3c38626635-000000@us-east-2.amazonses.com> <177d1159-22ac-b3c1-26bd-cff76864b5d8@gmail.com> Message-ID: <010f017fd2048141-52d1f160-247a-4c44-be36-aee4c3f31026-000000@us-east-2.amazonses.com> Hi Rowan, Thanks for the detailed answer. For me, there is always a danger in the possibility that I might not realize there is an implicit param in play, but I see your point. To my knowledge, this particular question has not been considered: whether (and how) the MR should apply to implicit parameters. My recommendation, if you want to pursue this, is to post at the ghc-proposals repo. If you're not yet sure exactly what behavior you think would be better, I encourage you to make an Issue first. Issues tend to get good discussion going. Then, once there is some consensus about future directions, you (or someone else) can make a formal proposal to change this behavior. It's true that the implementation change is easy (I agree with your code), but specification is not so easy sometimes. :) Richard > On Mar 28, 2022, at 8:08 AM, rowan goemans wrote: > > Hi Richard, > > I understand why the monomorphism restriction is in place. But I feel the reason about potentially repeated computations which are non-obvious aren't really applicable to implicit params. If you use a function with a different implicit param then I don't think anyone would be surprised that it is a different computations. Maybe I'm just not seeing it though. E.g. this is confusing if monomorphism restriction isn't enabled: > > ``` > plus a b = a + b > > res = plus 6 10 > > usage1 :: Int > usage1 = res > > usage2 :: Integer > usage2 = res > ``` > > as the potentially expensive `plus` computation is ran twice where a user wouldn't expect it to be evaluated twice. > > But something comparable with implicit params isn't confusing I think: > > ``` > plus a = a + ?b > > res = plus 6 > > usage1 :: Int > usage1 = let ?b = 10 in res > > usage2 :: Integer > usage2 = let ?b = 10 in res > ``` > > My main point though is whether this was something that was already discussed somewhere with the conclusion being that implicit params should really fall under the monomorphism restriction. Instead of it being an artifact of the current implementation in GHC. Because I would be quite interested in lifting it for implicit params. > > Rowan Goemans > > On 3/25/22 20:17, Richard Eisenberg wrote: >> Hi Rowan, >> >> The problem is that generalizing a let-binding turns something that looks like a constant into a function. This means that repeated use of the variable will evaluate it separately each time. This can be observed to slow down a program. A key point of the monomorphism restriction is to prevent non-functions from actually being functions. This applies equally well to implicit parameters as to other constraints. >> >> Richard >> >>> On Mar 24, 2022, at 5:37 PM, rowan goemans > wrote: >>> >>> Hi Richard, >>> >>> Thanks for answering. I have made a tiny change to GHC in a fork that lifts the monomorphization restriction but only for implicit params. See this commit: https://gitlab.haskell.org/rowanG/ghc/-/merge_requests/1/diffs?commit_id=35fcad2d7f556706dd129a57815abe421a559861 >>> Is there some example I could run to see in action why the monomorphisation restriction is required? I looked at the Haskell report and I don't immediately see why the points raised apply to implicit params. I get a feeling that monomorph(Contains only a concrete type like Int or Bool) implicit params would never be a problem and maybe only polymorphic ones are? >>> >>> Rowan Goemans >>> >>> On 3/24/22 20:05, Richard Eisenberg wrote: >>>> >>>> >>>>> On Mar 24, 2022, at 9:04 AM, rowan goemans > wrote: >>>>> >>>>> is this by design/expected though? >>>> >>>> It is by design, yes. With a sufficiently nuanced expectation, I would also say it's expected. (Though, to be fair, if I were not primed to be thinking about the monomorphism restriction, I can't honestly say I would get it right if quizzed.) >>>> >>>>> Would there be interest in fixing this in GHC? >>>> >>>> Figuring out when to generalize a local binding is a hard problem. So, there is definitely interest in finding a better way to do it, but I don't think anyone knows a design that meets the most expectations. Language design is hard! :) >>>> >>>> Richard >>> _______________________________________________ >>> 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. >> > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Mon Mar 28 22:34:59 2022 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Mon, 28 Mar 2022 22:34:59 +0000 Subject: [Haskell-cafe] [ANN] base16-0.3.2.0, base32-0.2.2.0, base64-0.4.2.4 Message-ID: Hello All, I'm pleased to announce that `base16`, `base32`, and `base64` have been updated to support GHC 9.2.x. In the most recent versions, due to GHC issue #20338 in which `targetByteOrder` was incorrect on Big Endian architectures, the required GHC version lower bound has been upped to GHC 8.10.x. In this version, GHC 8.10.x was silently patched to fix this behavior. Cheers, Emily -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaynah.dargaye at nomadic-labs.com Tue Mar 29 06:49:58 2022 From: zaynah.dargaye at nomadic-labs.com (Zaynah Dargaye) Date: Tue, 29 Mar 2022 08:49:58 +0200 Subject: [Haskell-cafe] First CfP: FMBC 2022 - 4th International Workshop on Formal Methods for Blockchains Message-ID: FMBC 2022 First Call for Papers [ Please distribute, apologies for multiple postings. ] ======================================================================== 4th International Workshop on Formal Methods for Blockchains (FMBC) - First Call https://fmbc.gitlab.io/2022 August 11, 2022, Haifa, Israel Co-located with the The Federated Logic Conference 2022 (FLoC 22 -- https://www.floc2022.org/) as a satellite workshop of the 34th International Conference on Computer-Aided Verification (CAV 2022 -- http://i-cav.org/2022/). ----------------------------------------------------------------- Important dates --------------------- Abstract submission: May 3, 2022 Full paper submission: May 10, 2022 Notification: June 15, 2022 Camera-ready: July 13, 2022 Workshop: August 11, 2022 Deadlines are Anywhere on Earth -- https://en.wikipedia.org/wiki/Anywhere_on_Earth. ---------------------- ---------------------- TOPICS OF INTEREST --------------------- Blockchains are decentralized transactional ledgers that rely on cryptographic hash functions for guaranteeing the integrity of the stored data. Participants on the network reach agreement on what valid transactions are through consensus algorithms. Blockchains may also provide support for Smart Contracts. Smart Contracts are scripts of an ad-hoc programming language that are stored in the Blockchain and that run on the network. They can interact with the ledger’s data and update its state. These scripts can express the logic of possibly complex contracts between users of the Blockchain. Thus, Smart Contracts can facilitate the economic activity of Blockchain participants. With the emergence and increasing popularity of cryptocurrencies such as Bitcoin and Ethereum, it is now of utmost importance to have strong guarantees of the behavior of Blockchain software. These guarantees can be brought by using Formal Methods. Indeed, Blockchain software encompasses many topics of computer science where using Formal Methods techniques and tools are relevant: consensus algorithms to ensure the liveness and the security of the data on the chain, programming languages specifically designed to write Smart Contracts, cryptographic protocols, such as zero-knowledge proofs, used to ensure privacy, etc. This workshop is a forum to identify theoretical and practical approaches of formal methods for Blockchain technology. Topics include, but are not limited to: * Formal models of Blockchain applications or concepts * Formal methods for consensus protocols * Formal methods for Blockchain-specific cryptographic primitives or protocols * Design and implementation of Smart Contract languages * Verification of Smart Contracts ---------------------- ---------------------- SUBMISSION --------------------- Submit original manuscripts (not published or considered elsewhere) with a page limit of 12 pages for full papers and Systematization of Knowledge (SoK) papers, 6 pages for short papers, and 2 pages for tool papers (excluding bibliography and short appendix of up to 5 additional pages). Alternatively, you may also submit an extended abstract of up to 3 pages (including a bibliography) summarizing your ongoing work in the area of formal methods and blockchain. Authors of selected extended abstracts are invited to give a short lightning talk. -------------------- -------------------- PROCEEDINGS ------------------- All submissions will be peer-reviewed by at least three members of the program committee for quality and relevance. Accepted regular papers (full and short papers) will be included in the workshop proceedings. ---------------------- ---------------------- INVITED SPEAKER --------------------- Massimo Bartoletti, Professor, Università degli Studi di Cagliari, Italy ---------------------- ---------------------- PROGRAM COMMITTEE --------------------- PC CO-CHAIRS * Zaynah Dargaye (Nomadic Labs, France) (zaynah.dargaye at nomadic-labs.com) * Schneidewind Clara, (MPI-SP, Germany) (clara.schneidewind at mpi-sp.org) PC MEMBERS Wolfgang Ahrendt (Chalmers University of Technology, Sweden) Leonardo Alt (Ethereum Foundation, Germany) Lacramioara Astefanoaei (Nomadic Labs, France) Roberto Blanco (MPI-SP, Germany) Joachim Breitner (Germany) Achim Brucker (University of Exeter, UK) Ethan Cecchetti (University of Maryland, USA) Manuel Chakravarty (IOHK & Tweag, Netherlands) Jing Chen (Algorand Inc, USA) Jérémie Decouchant (TU Delft, Netherlands) Antonella Del Pozzo (Université Paris-Saclay & CEA & List, France) Dana Drachsler Cohen (Technion, Israel) Cezara Dragoi (INRIA & ENS & CNRS & PSL, France) Ansgar Fehnker (Twente, Netherlands) Dominik Harz (Interlay & Imperial College London, UK) Lars Hupel (INNOQ, Germany) Igor Konnov (Informal Systems, Austria) Paul Laforgue (Nomadic Labs, France) Julian Nagele (Bank of America, USA) Russel O’Connor (Blockstream) Maria Potop-Butucaru (LIP6, France) Albert Rubio (Complutense University of Madrid, Spain) César Sanchez (IMDEA, Spain) Sun Meng (Peking University, China) Simon Thompson (IO Global, UK) Josef Widder (Informal Systems, Austria) -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Tue Mar 29 15:32:46 2022 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 29 Mar 2022 18:32:46 +0300 Subject: [Haskell-cafe] Can't use TypeApplications with polymorphic let bind In-Reply-To: References: Message-ID: First example doesn't work due MonomorphismRestriction. Second one works because it's all Haskell98 (to first approximation: it must work). Third one is interesting. At first I didn't expect it work, but given a bit of thought, I wasn't tht sure anymore: I don't know why `x` isn't already generalized when type-checking body of the let-in. - Oleg On 28.3.2022 17.14, Georgi Lyubenov wrote: > Dear Cafe, > > I recently came upon this little "type-inference puzzle". Can anyone > shine some light on why the third example doesn't compile? > > ``` > {-# LANGUAGE TypeApplications #-} > -- doesn't work > -- I expect this, not sure why it happens > {- > class C m where >   c :: () -> m > > instance C Int where >   c () = 0 > > instance C Bool where >   c () = False > > f :: (Int, Bool) > f = >   let x = c >    in >    (x (), x ()) > -} > > -- works > -- I expect this, not sure why it happens > {- > class C m where >   c :: () -> m > > instance C Int where >   c () = 0 > > instance C Bool where >   c () = False > > f :: (Int, Bool) > f = >   let x u = c u >    in >    (x (), x ()) > -} > > -- doesn't work > -- I don't expect this, not sure why it happens > {- > class C m where >   c :: () -> m > > instance C Int where >   c () = 0 > > instance C Bool where >   c () = False > > f :: (Int, Bool) > f = >   let x u = c u >    in >    (x @Int (), x @Bool ()) > -- wtf.hs:54:5: error: > --     • Cannot apply expression of type ‘() -> m0’ > --       to a visible type argument ‘Int’ > --     • In the expression: x @Int () > --       In the expression: (x @Int (), x @Bool ()) > --       In the expression: let x u = c u in (x @Int (), x @Bool ()) > --    | > -- 54 |    (x @Int (), x @Bool ()) > --    |     ^^^^^^^^^ > -} > ``` > > Cheers, > Georgi > > _______________________________________________ > 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. From lists at richarde.dev Tue Mar 29 19:30:28 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 29 Mar 2022 19:30:28 +0000 Subject: [Haskell-cafe] New Executive Director for the Haskell Foundation Message-ID: <010f017fd7287b47-3fd347cd-73f5-4371-997c-d56420c87911-000000@us-east-2.amazonses.com> Official announcement on Discourse: https://discourse.haskell.org/t/new-executive-director-for-the-haskell-foundation/4290 Text repeated here (but responses from David and Andrew are already on Discourse): It is my great pleasure to announce the next Executive Director of the Haskell Foundation: David Thrane Christiansen. David is a long-time Haskeller who comes with a demonstrated passion for functional programming, having done intensive work with Idris, Racket, and Haskell, among other formative experiences. In particular, David was a key part of the Idris community when it morphed from a smallish language project to one more widely used. David holds a PhD in Computer Science from the IT University of Copenhagen (the city where he currently lives), has co-authored a book on dependent types (The Little Typer), and has worked for Galois and Deon Digital. Lest anyone get worried about one PhD excited about dependent types (me) involved in hiring another PhD excited about dependent types (David): over the course of many conversations about the HF, David has impressed upon me the importance of reaching out beyond current Haskell communities, seeking new voices and approaches. Haskell is a language that anyone can master -- but we have work to do to have its perception match that reality. I know David is committed to that course of action, and of focusing on the practical aspects of Haskell use that affect the Haskell community broadly. David begins his employment with the HF on Monday, May 2. About the process: The HF formed a Transition Committee (our charter is public: https://gitlab.haskell.org/hf/meta/-/blob/main/committees/transition.md) comprising José Pedro Magalhães (chair), Ed Kmett, and myself. We put together a call for applications and processed these applications as they came in. Applicants that passed an initial screening interview were given four additional interviews. The Transition Committee then made a recommendation to the Board based on the written feedback from these interviews, and the Board voted unanimously and enthusiastically to accept the recommendation to hire David. I hope you join me in being excited about this next chapter for the Haskell Foundation! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Tue Mar 29 19:38:17 2022 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 29 Mar 2022 15:38:17 -0400 Subject: [Haskell-cafe] Can't use TypeApplications with polymorphic let bind In-Reply-To: References: Message-ID: For the third case, the GHC manual says -XTypeApplications: > can be used whenever the full polymorphic type of the function is known. If the function is an identifier (the common case), its type is considered known only when the identifier has been given a type signature. If the identifier does not have a type signature, visible type application cannot be used. So it works if x has a type signature: x :: C m => () -> m x u = c u g = (x @Int (), x @Bool ()) I think 'g' should work without the type signature on 'x'. Inferred type variables may switch places between ghc versions. So "h" below might change between (Int,Bool) and (Bool,Int). So they reject "h". But for 'g' there's only one ordering. h = (x (), x ()) @Int @Bool The error "Cannot apply expression of type _ to a visible type argument _ in the expression: x ..." might be clearer if it also had "Possible fix: add a type signature to the declaration/binding of x" Regards, Adam On Tue, Mar 29, 2022 at 11:40 AM Oleg Grenrus wrote: > First example doesn't work due MonomorphismRestriction. > Second one works because it's all Haskell98 (to first approximation: it > must work). > Third one is interesting. At first I didn't expect it work, but given a > bit of thought, I wasn't tht sure anymore: I don't know why `x` isn't > already generalized when type-checking body of the let-in. > > - Oleg > > On 28.3.2022 17.14, Georgi Lyubenov wrote: > > Dear Cafe, > > > > I recently came upon this little "type-inference puzzle". Can anyone > > shine some light on why the third example doesn't compile? > > > > ``` > > {-# LANGUAGE TypeApplications #-} > > -- doesn't work > > -- I expect this, not sure why it happens > > {- > > class C m where > > c :: () -> m > > > > instance C Int where > > c () = 0 > > > > instance C Bool where > > c () = False > > > > f :: (Int, Bool) > > f = > > let x = c > > in > > (x (), x ()) > > -} > > > > -- works > > -- I expect this, not sure why it happens > > {- > > class C m where > > c :: () -> m > > > > instance C Int where > > c () = 0 > > > > instance C Bool where > > c () = False > > > > f :: (Int, Bool) > > f = > > let x u = c u > > in > > (x (), x ()) > > -} > > > > -- doesn't work > > -- I don't expect this, not sure why it happens > > {- > > class C m where > > c :: () -> m > > > > instance C Int where > > c () = 0 > > > > instance C Bool where > > c () = False > > > > f :: (Int, Bool) > > f = > > let x u = c u > > in > > (x @Int (), x @Bool ()) > > -- wtf.hs:54:5: error: > > -- • Cannot apply expression of type ‘() -> m0’ > > -- to a visible type argument ‘Int’ > > -- • In the expression: x @Int () > > -- In the expression: (x @Int (), x @Bool ()) > > -- In the expression: let x u = c u in (x @Int (), x @Bool ()) > > -- | > > -- 54 | (x @Int (), x @Bool ()) > > -- | ^^^^^^^^^ > > -} > > ``` > > > > Cheers, > > Georgi > > > > _______________________________________________ > > 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. > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Mar 29 20:44:03 2022 From: david.feuer at gmail.com (David Feuer) Date: Tue, 29 Mar 2022 16:44:03 -0400 Subject: [Haskell-cafe] Can't use TypeApplications with polymorphic let bind In-Reply-To: References: Message-ID: My guess is that even the one-variable case is potentially fragile. The following types are almost equivalent: Int -> Int a ~ Int => a -> Int However, the second one has a type argument while the first doesn't. Which one is inferred seems like it could potentially depend on the way the function is defined as well as details of the type inference algorithm. On Tue, Mar 29, 2022, 3:40 PM adam vogt wrote: > For the third case, the GHC manual says -XTypeApplications: > > > can be used whenever the full polymorphic type of the function is known. > If the function is an identifier (the common case), its type is considered > known only when the identifier has been given a type signature. If the > identifier does not have a type signature, visible type application cannot > be used. > > So it works if x has a type signature: > > x :: C m => () -> m > x u = c u > g = (x @Int (), x @Bool ()) > > I think 'g' should work without the type signature on 'x'. Inferred type > variables may switch places between ghc versions. So "h" below might change > between (Int,Bool) and (Bool,Int). So they reject "h". But for 'g' there's > only one ordering. > > h = (x (), x ()) @Int @Bool > > The error "Cannot apply expression of type _ to a visible type argument _ > in the expression: x ..." might be clearer if it also had "Possible fix: > add a type signature to the declaration/binding of x" > > Regards, > Adam > > > > On Tue, Mar 29, 2022 at 11:40 AM Oleg Grenrus wrote: > >> First example doesn't work due MonomorphismRestriction. >> Second one works because it's all Haskell98 (to first approximation: it >> must work). >> Third one is interesting. At first I didn't expect it work, but given a >> bit of thought, I wasn't tht sure anymore: I don't know why `x` isn't >> already generalized when type-checking body of the let-in. >> >> - Oleg >> >> On 28.3.2022 17.14, Georgi Lyubenov wrote: >> > Dear Cafe, >> > >> > I recently came upon this little "type-inference puzzle". Can anyone >> > shine some light on why the third example doesn't compile? >> > >> > ``` >> > {-# LANGUAGE TypeApplications #-} >> > -- doesn't work >> > -- I expect this, not sure why it happens >> > {- >> > class C m where >> > c :: () -> m >> > >> > instance C Int where >> > c () = 0 >> > >> > instance C Bool where >> > c () = False >> > >> > f :: (Int, Bool) >> > f = >> > let x = c >> > in >> > (x (), x ()) >> > -} >> > >> > -- works >> > -- I expect this, not sure why it happens >> > {- >> > class C m where >> > c :: () -> m >> > >> > instance C Int where >> > c () = 0 >> > >> > instance C Bool where >> > c () = False >> > >> > f :: (Int, Bool) >> > f = >> > let x u = c u >> > in >> > (x (), x ()) >> > -} >> > >> > -- doesn't work >> > -- I don't expect this, not sure why it happens >> > {- >> > class C m where >> > c :: () -> m >> > >> > instance C Int where >> > c () = 0 >> > >> > instance C Bool where >> > c () = False >> > >> > f :: (Int, Bool) >> > f = >> > let x u = c u >> > in >> > (x @Int (), x @Bool ()) >> > -- wtf.hs:54:5: error: >> > -- • Cannot apply expression of type ‘() -> m0’ >> > -- to a visible type argument ‘Int’ >> > -- • In the expression: x @Int () >> > -- In the expression: (x @Int (), x @Bool ()) >> > -- In the expression: let x u = c u in (x @Int (), x @Bool ()) >> > -- | >> > -- 54 | (x @Int (), x @Bool ()) >> > -- | ^^^^^^^^^ >> > -} >> > ``` >> > >> > Cheers, >> > Georgi >> > >> > _______________________________________________ >> > 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. >> _______________________________________________ >> 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. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: