From lemming at henning-thielemann.de Sat Aug 1 10:15:27 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 1 Aug 2020 12:15:27 +0200 (CEST) Subject: [Haskell-cafe] doctest-extract Message-ID: I have started an alternative implementation of 'doctest'. In contrast to the original one, doctest-extract extracts Haskell test-modules from doctest comments. This integrates better with Cabal and its package version resolution and the tests are compiled, not interpreted in GHCi. Disadvantage is that doctest-extract does not support all features of 'doctest', e.g. IO-tests. I uploaded a preview as package candidates to Hackage: $ cabal install $(for pkg in doctest-extract-0.0 doctest-lib-0.0 utility-ht-0.0.16 non-empty-0.3.3; do echo https://hackage.haskell.org/package/$pkg/candidate/$pkg.tar.gz; done) Extract test modules like so: $ doctest-extract -i src/ -o test/ --executable-main=Test/Main.hs --import-tested $$(cat test-module.list) There is still a problem: A failing QuickCheck test does not abort the whole test-suite. 'cabal test' will report success even if one QuickCheck property test fails. I wonder what is the proposed way to make a failing property fail the test-suite? I could use (QC.whenFail exitFailure). Is this the intended way? From lemming at henning-thielemann.de Sun Aug 2 16:49:07 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 2 Aug 2020 18:49:07 +0200 (CEST) Subject: [Haskell-cafe] doctest-extract In-Reply-To: References: Message-ID: On Sat, 1 Aug 2020, Henning Thielemann wrote: > There is still a problem: A failing QuickCheck test does not abort the whole > test-suite. 'cabal test' will report success even if one QuickCheck property > test fails. I wonder what is the proposed way to make a failing property fail > the test-suite? I could use (QC.whenFail exitFailure). Is this the intended > way? (whenFail exitFailure) would not even help. QuickCheck catches it and keeps going. :-( From erkokl at gmail.com Mon Aug 3 17:19:22 2020 From: erkokl at gmail.com (Levent Erkok) Date: Mon, 3 Aug 2020 10:19:22 -0700 Subject: [Haskell-cafe] doctest-extract In-Reply-To: References: Message-ID: <631F8B1B-100A-4B34-8033-87050CF62E74@gmail.com> Hi Henning: I’m quite interested in this, especially as doctest on GHC 8.10 has issues: https://github.com/sol/doctest/issues/264 Furthermore, compiling doctests would be a huge performance boost and can speed up CI times significantly. I’m curious why your new package does not support IO-tests. Is that a “current” limitation, or is there a fundamental reason why IO-tests ca not be supported using your approach. Cheers, -Levent. > On Aug 1, 2020, at 3:15 AM, Henning Thielemann wrote: > > > I have started an alternative implementation of 'doctest'. In contrast to the original one, doctest-extract extracts Haskell test-modules from doctest comments. This integrates better with Cabal and its package version resolution and the tests are compiled, not interpreted in GHCi. Disadvantage is that doctest-extract does not support all features of 'doctest', e.g. IO-tests. > > I uploaded a preview as package candidates to Hackage: > > $ cabal install $(for pkg in doctest-extract-0.0 doctest-lib-0.0 utility-ht-0.0.16 non-empty-0.3.3; do echo https://hackage.haskell.org/package/$pkg/candidate/$pkg.tar.gz; done) > > > Extract test modules like so: > > $ doctest-extract -i src/ -o test/ --executable-main=Test/Main.hs --import-tested $$(cat test-module.list) > > > There is still a problem: A failing QuickCheck test does not abort the whole test-suite. 'cabal test' will report success even if one QuickCheck property test fails. I wonder what is the proposed way to make a failing property fail the test-suite? I could use (QC.whenFail exitFailure). Is this the intended way? > _______________________________________________ > 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 Mon Aug 3 17:26:46 2020 From: david.feuer at gmail.com (David Feuer) Date: Mon, 3 Aug 2020 13:26:46 -0400 Subject: [Haskell-cafe] doctest-extract In-Reply-To: References: Message-ID: See https://stackoverflow.com/questions/8976488/quickcheck-exit-status-on-failures-and-cabal-integration The gist is that you have to get the results of the QuickCheck test(s) and use them outside the QuickCheck context. On Sat, Aug 1, 2020, 6:15 AM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > I have started an alternative implementation of 'doctest'. In contrast to > the original one, doctest-extract extracts Haskell test-modules from > doctest comments. This integrates better with Cabal and its package > version resolution and the tests are compiled, not interpreted in GHCi. > Disadvantage is that doctest-extract does not support all features of > 'doctest', e.g. IO-tests. > > I uploaded a preview as package candidates to Hackage: > > $ cabal install $(for pkg in doctest-extract-0.0 doctest-lib-0.0 > utility-ht-0.0.16 non-empty-0.3.3; do echo > https://hackage.haskell.org/package/$pkg/candidate/$pkg.tar.gz; done) > > > Extract test modules like so: > > $ doctest-extract -i src/ -o test/ --executable-main=Test/Main.hs > --import-tested $$(cat test-module.list) > > > There is still a problem: A failing QuickCheck test does not abort the > whole test-suite. 'cabal test' will report success even if one QuickCheck > property test fails. I wonder what is the proposed way to make a failing > property fail the test-suite? I could use (QC.whenFail exitFailure). Is > this the intended way? > _______________________________________________ > 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 lemming at henning-thielemann.de Mon Aug 3 17:31:13 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 3 Aug 2020 19:31:13 +0200 (CEST) Subject: [Haskell-cafe] doctest-extract In-Reply-To: <631F8B1B-100A-4B34-8033-87050CF62E74@gmail.com> References: <631F8B1B-100A-4B34-8033-87050CF62E74@gmail.com> Message-ID: On Mon, 3 Aug 2020, Levent Erkok wrote: > I’m quite interested in this, especially as doctest on GHC 8.10 has > issues: https://github.com/sol/doctest/issues/264 interesting > Furthermore, compiling doctests would be a huge performance > boost and can speed up CI times significantly. right > I’m curious why your new package does not support IO-tests. Is that a > “current” limitation, or is there a fundamental reason why IO-tests ca > not be supported using your approach. It is a deeper problem. doctest just runs GHCi and GHCi follows the built-in rule: If an expression is IO, then run IO and emit its stdio. If not, print the result of "show". That is, in order to make this distinction, doctest-extract would have to know the type of the test expression. However, doctest-extract extracts purely syntactically, and I prefer to keep it this way for simplicity. For now you may use quickCheck's IO testing. But can it check for stdio data? Alternatively I thought about letting the user mark IO examples in some way. Maybe I could ask the user to give a type signature to IO tests and switch on expressions that end with ":: IO". From lemming at henning-thielemann.de Mon Aug 3 17:34:20 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 3 Aug 2020 19:34:20 +0200 (CEST) Subject: [Haskell-cafe] doctest-extract In-Reply-To: References: Message-ID: On Mon, 3 Aug 2020, David Feuer wrote: > See > https://stackoverflow.com/questions/8976488/quickcheck-exit-status-on-failures-and-cabal-integration > > The gist is that you have to get the results of the QuickCheck test(s) and use them outside the QuickCheck > context. Thank you for the hint! I got a similar hint off-list and already solved the problem this way. From lemming at henning-thielemann.de Mon Aug 3 17:50:06 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 3 Aug 2020 19:50:06 +0200 (CEST) Subject: [Haskell-cafe] doctest-extract In-Reply-To: References: <631F8B1B-100A-4B34-8033-87050CF62E74@gmail.com> Message-ID: On Mon, 3 Aug 2020, Henning Thielemann wrote: > doctest just runs GHCi and GHCi follows the built-in rule: If an expression > is IO, then run IO and emit its stdio. I meant stdout, of course. Certainly also stderr. From guthrie at miu.edu Thu Aug 6 03:23:11 2020 From: guthrie at miu.edu (Gregory Guthrie) Date: Thu, 6 Aug 2020 03:23:11 +0000 Subject: [Haskell-cafe] dates... Message-ID: I don't understand why the Julian conversion are given relative to 2019, instead of 2020, and don't seem to actually show the date index. Must be misreading the library specs? toJulianYearAndDay :: Day -> (Integer, Int) convert to proleptic Julian year and day format. First element of result is year (proleptic Julian calendar), second is the day of the year, with 1 for Jan 1, and 365 toJulian :: Day -> (Integer, Int, Int) Source convert to proleptic Julian calendar. First element of result is year, second month number (1-12), third day (1-31). ---------------------------------------------------------------------------------- ds = "1/8/2020" day = parseTimeOrError True defaultTimeLocale "%-m/%-d/%Y" ds :: UTCTime getDay = toGregorian . utctDay getDayOfYear = toJulian . utctDay getDayYear = toJulianYearAndDay. utctDay main = do print day print $ getDay day print $ getDayYear day print $ getDayOfYear day 2020-01-08 00:00:00 UTC (2020,1,8) (2019,360) (2019,12,26) And; 2020-02-08 00:00:00 UTC (2020,2,8) (2020,26) (2020,1,26) Dr. Gregory Guthrie Maharishi International University ---------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at chordify.net Thu Aug 6 07:14:01 2020 From: jeroen at chordify.net (Jeroen Bransen) Date: Thu, 6 Aug 2020 09:14:01 +0200 Subject: [Haskell-cafe] dates... In-Reply-To: References: Message-ID: Dear Gregory, According to [1]: > For any given event during the years from 1901 to 2099 inclusive, its date according to the Julian calendar is 13 days behind its corresponding Gregorian date. And 13 days before 2020-01-08 is indeed 2019-12-26, which is the 360th day of the year 2019, so I am not sure about your confusion. If you pick a date in the first 13 days of the year, then the Julian conversion will indeed lead to a date in the year before. Maybe you are thinking about August the 1st? Your date parsing, with month coming first, is odd for most parts of the world; the date you are parsing in the example is the 8th of January in the year 2020. Regards, Jeroen Bransen [1] https://en.wikipedia.org/wiki/Julian_calendar Op 6-8-2020 om 05:23 schreef Gregory Guthrie: > > I don’t understand why the Julian conversion are given relative to > 2019, instead of 2020, and don’t seem to actually show the date index. > > Must be misreading the library specs? > > toJulianYearAndDay :: Day > > -> (Integer > , > Int > ) > >      convert to proleptic Julian year and day format. First element of > result is year (proleptic Julian calendar), second is the day of the > year, with 1 for Jan 1, and 365 > > toJulian :: Day > > -> (Integer > , > Int > , > Int > ) > Source > > >     convert to proleptic Julian calendar. First element of result is > year, second month number (1-12), third day (1-31). > > ---------------------------------------------------------------------------------- > >   > > ds = "1/8/2020" > > day = parseTimeOrError True defaultTimeLocale "%-m/%-d/%Y"   ds :: UTCTime > >   > > getDay       = toGregorian       . utctDay > > getDayOfYear = toJulian          . utctDay > > getDayYear   = toJulianYearAndDay. utctDay > >   > > main = do > >       print day > >       print $ getDay       day > >       print $ getDayYear   day > >       print $ getDayOfYear day > >   > > 2020-01-08 00:00:00 UTC > > (2020,1,8) > > (2019,360) > > (2019,12,26) > > And; > > 2020-02-08 00:00:00 UTC > > (2020,2,8) > > (2020,26) > > (2020,1,26) > >   > > Dr. Gregory Guthrie > > Maharishi International University > > ---------------------------------------------------------------- > >   > > > _______________________________________________ > 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. -- Jeroen Bransen Lead Back-end Developer at Chordify -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From eborsboom at fpcomplete.com Thu Aug 6 12:54:53 2020 From: eborsboom at fpcomplete.com (Emanuel Borsboom) Date: Thu, 6 Aug 2020 12:54:53 +0000 Subject: [Haskell-cafe] ANN: stack-2.3.3 In-Reply-To: References: Message-ID: <41F1E065-325A-49FB-BB73-07F5668DEC89@fpcomplete.com> See https://haskellstack.org/ for installation and upgrade instructions. Changes since v2.3.1 Other enhancements: * Add the stack-developer-mode flag Bug fixes: * When using the STACK_YAML env var with Docker, make the path absolute. * Fix the problem of stack repl foo:test:bar failing without a project build before that. See #5213 * Fix stack sdist introducing unneded sublibrary syntax when using pvp-bounds. See #5289 Thanks to all our contributors for this release: * coord.e * Dmitry Dzhus * Emanuel Borsboom * Kirill Zaborsky * Michael Snoyman -------------- next part -------------- An HTML attachment was scrubbed... URL: From compl.yue at gmail.com Thu Aug 6 17:50:17 2020 From: compl.yue at gmail.com (Compl Yue) Date: Fri, 7 Aug 2020 01:50:17 +0800 Subject: [Haskell-cafe] STM friendly TreeMap (or similar with range scan api) ? WAS: Best ways to achieve throughput, for large M:N ratio of STM threads, with hot TVar updates? In-Reply-To: <33DE75B7-F33F-48EC-8D08-825D264F9C78@icloud.com> References: <4CAE51E9-2720-4C2F-9971-00FABACA35BC@icloud.com> <74f14ebd-241b-0b4f-03d5-ea130f69a1c6@icloud.com> <41fc9d8e-2356-f3a7-6f00-c8a51d3b95f7@icloud.com> <8136052f-8b5c-c31f-7487-d03f6a86a5d3@icloud.com> <8d25fa78-9a66-6e24-7771-ba0afa127a04@icloud.com> <87v9i3g62h.fsf@smart-cactus.org> <33DE75B7-F33F-48EC-8D08-825D264F9C78@icloud.com> Message-ID: Hi Devs & Cafe, I would report back my progress on it, actually I've got a rough conclusion that TL;DR: > For data-intensive workloads, x86_64 ISA has its cache of CPU chips being a hardware bottleneck, it's very hard to scale up with added number of cores, so long as they share the cache as being in a single chip. For the details - I developed a minimal script interpreter for diagnostic purpose, dependent only on libraries bundled with GHC, the source repository is at: https://github.com/complyue/txs I benchmarked on my machine with a single 6-core Xeon E5 CPU chip, for contention-free read/write performance scaling, got numbers at: https://github.com/complyue/txs/blob/master/results/baseline.csv conc thread avg tps scale eff populate 1 1741 1.00 1.00 2 1285 1.48 0.74 3 1028 1.77 0.59 4 843 1.94 0.48 5 696 2.00 0.40 6 600 2.07 0.34 scan 1 1565 1.00 1.00 2 1285 1.64 0.82 3 1018 1.95 0.65 4 843 2.15 0.54 5 696 2.22 0.44 6 586 2.25 0.37 The script is at: https://github.com/complyue/txs/blob/master/scripts/scan.txs GHC cmdl is at: https://github.com/complyue/txs/blob/master/metric.bash ghc --make -Wall -threaded -rtsopts -prof -o txs -outputdir . -stubdir . -i../src ../src/Main.hs && ( ./txs +RTS -N10 -A32m -H256m -qg -I0 -M5g -T -s <../scripts/"${SCRIPT}".txs ) I intended to use a single Haskell based process to handle meta data about many ndarrays being crunched, acting as a centralized graph database, as it turned out, many clients queued to query/insert meta data against a single database node, will create such high data throughput that just few CPU chips can't handle well, we didn't expect this but apparently we'll have to deploy more machines as for such a database instance, with data partitioned and distributed to more nodes for load balancing. (A single machine with many sockets for CPU thus many NUMA nodes is neither an option for us.) While the flexibility a central graph database would provide, is not currently a crucial requirement of our business, so we are not interested to further develop this database system. We currently have CPU intensive workloads handled by some cluster of machines running Python processes (crunching numbers with Numpy and C++ tensors), while some Haskell based number crunching software are still under development, it may turn out some day in the future, that some heavier computation be bound with the db access, effectively creating some CPU intensive workloads for the database functionality, then we'll have the opportunity to dive deeper into the database implementation. And in case more flexibility required in near future, I think I'll tend to implement embedded database instances in those worker processes, in contrast to centralized db servers. I wonder if ARM servers will have up scaling of data intensive workloads easier, though that's neither a near feasible option for us. Thanks for everyone that have been helpful! Best regards, Compl > On 2020-07-31, at 22:35, YueCompl via Haskell-Cafe wrote: > > Hi Ben, > > Thanks as always for your great support! And at the moment I'm working on a minimum working example to reproduce the symptoms, I intend to work out a program depends only on libraries bundled with GHC, so it can be easily diagnosed without my complex env, but so far no reprod yet. I'll come with some piece of code once it can reproduce something. > > Thanks in advance. > > Sincerely, > Compl > > >> On 2020-07-31, at 21:36, Ben Gamari wrote: >> >> Simon Peyton Jones via Haskell-Cafe writes: >> >>>> Compl’s problem is (apparently) that execution becomes dominated by >>>> GC. That doesn’t sound like a constant-factor overhead from TVars, no >>>> matter how efficient (or otherwise) they are. It sounds more like a >>>> space leak to me; perhaps you need some strict evaluation or >>>> something. >>> >>> My point is only: before re-engineering STM it would make sense to get >>> a much more detailed insight into what is actually happening, and >>> where the space and time is going. We have tools to do this (heap >>> profiling, Threadscope, …) but I know they need some skill and insight >>> to use well. But we don’t have nearly enough insight to draw >>> meaningful conclusions yet. >>> >>> Maybe someone with experience of performance debugging might feel able >>> to help Compl? >>> >> Compl, >> >> If you want to discuss the issue feel free to get in touch on IRC. I >> would be happy to help. >> >> It would be great if we had something of a decision tree for performance >> tuning of Haskell code in the users guide or Wiki. We have so many tools >> yet there isn't a comprehensive overview of >> >> 1. what factors might affect which runtime characteristics of your >> program >> 2. which tools can be used to measure which factors >> 3. how these factors can be improved >> >> Cheers, >> >> - Ben >> _______________________________________________ >> 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 guthrie at miu.edu Thu Aug 6 19:29:08 2020 From: guthrie at miu.edu (Gregory Guthrie) Date: Thu, 6 Aug 2020 19:29:08 +0000 Subject: [Haskell-cafe] dates... In-Reply-To: References: Message-ID: AH, yes - thanks, that is the missing 13-days mystery? And yes - in us MM/dd/yy is most common. Thanks. Dr. Gregory Guthrie Maharishi International University ---------------------------------------------------------------- Subject: Re: [Haskell-cafe] dates... Dear Gregory, According to [1]: > For any given event during the years from 1901 to 2099 inclusive, its date according to the Julian calendar is 13 days behind its corresponding Gregorian date. Regards, Jeroen Bransen [1] https://en.wikipedia.org/wiki/Julian_calendar Op 6-8-2020 om 05:23 schreef Gregory Guthrie: I don't understand why the Julian conversion are given relative to 2019, instead of 2020, and don't seem to actually show the date index. Must be misreading the library specs? toJulianYearAndDay :: Day -> (Integer, Int) convert to proleptic Julian year and day format. First element of result is year (proleptic Julian calendar), second is the day of the year, with 1 for Jan 1, and 365 toJulian :: Day -> (Integer, Int, Int) Source convert to proleptic Julian calendar. First element of result is year, second month number (1-12), third day (1-31). ---------------------------------------------------------------------------------- ds = "1/8/2020" day = parseTimeOrError True defaultTimeLocale "%-m/%-d/%Y" ds :: UTCTime getDay = toGregorian . utctDay getDayOfYear = toJulian . utctDay getDayYear = toJulianYearAndDay. utctDay main = do print day print $ getDay day print $ getDayYear day print $ getDayOfYear day 2020-01-08 00:00:00 UTC (2020,1,8) (2019,360) (2019,12,26) And; 2020-02-08 00:00:00 UTC (2020,2,8) (2020,26) (2020,1,26) Dr. Gregory Guthrie Maharishi International University ---------------------------------------------------------------- _______________________________________________ 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. -- Jeroen Bransen Lead Back-end Developer at Chordify [https://chordify.net/img/email-signature.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Thu Aug 6 20:13:55 2020 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 06 Aug 2020 22:13:55 +0200 Subject: [Haskell-cafe] stack build exhausts disk space (was: stack: pandoc fails to build as dependency) In-Reply-To: <5bf510ef-4a27-0614-fdd0-6069bde7c704@nh2.me> References: <138031038.250609.1571234245904@webmail.strato.de> <535d93c1-3025-fb5f-e139-23042e1ed34d@users.sourceforge.net> <5bf510ef-4a27-0614-fdd0-6069bde7c704@nh2.me> Message-ID: <432bdac9a3d1dcd78c390eb52796eb94728e477f.camel@aatal-apotheke.de> On Thu, 2019-10-17 at 01:41 +0200, Niklas Hambüchen wrote: > On 16/10/2019 16:22, Neil Mayhew wrote: > > On 2019-10-16 7:57 a.m., Olaf Klinke wrote: > > > pandoc > collect2: error: ld returned 1 exit status > > > pandoc > `gcc' failed in phase `Linker'. (Exit code: 1) > > > > [...] Can you get more info about what the linker error is? > > Indeed, the linker exiting with status 1 without any stderr message > sounds like your linker is crashing. > > Consider `stack build --cabal-verbose`, and if that doesn't provide > the necessary level of detail yet, take the last `ghc` invocation it > makes, run that directly and add `-v` to that to get GHC's verbose > output, which will show you the full linker invocation (which you may > then, again, run directly, thus drilling down to the tool that exits > with an error unexpectedly). > > Alternatively, you may use `strace -fy` on the top-level to get a > full understanding of all IO that any process involved does, but it > will be verbose. I just updated the resolver in my stack.yaml from lts-12.26 to lts- 13.11 and suddenly pandoc broke again, on the very same machine that happily builds pandoc when using lts-12.26. While fiddling with the various ways of keep-tmp-files as suggested above, ghc and stack filled my disk, so I went and cleaned some cache. And suddenly the build worked! Could it be that the linker error, too, is simply due to lack of disk space? The machine I first encountered the error on has an SSD of only 20GB with 2GB for /tmp. I had to temporarily re-locate /tmp to another partition to get ghc installed at all. Occasionally stack build --cabal-verbose gave me explicit errors about no space left on device, only the linker error does not mention it. That said, the stack FAQ [1] mentions changing the temporary directory but then says nothing about the build dir on non-NIX systems. Doesanyone know more? Olaf [1] https://docs.haskellstack.org/en/stable/faq/#can-i-change-stacks-default-temporary-directory From lysxia at gmail.com Fri Aug 7 01:52:22 2020 From: lysxia at gmail.com (Li-yao Xia) Date: Thu, 6 Aug 2020 21:52:22 -0400 Subject: [Haskell-cafe] Core optimizations affected by package provenance Message-ID: <2c5ac73d-4ba1-b2e9-d3ac-3d14898ae30a@gmail.com> Hello Café, I've been testing properties of some optimized Core using the inspection-testing library. Some functions appear to be optimized differently depending on whether one of the package dependencies comes from Hackage or elsewhere. As far as I can tell, the source code is identical, and the only difference is whether or not I add the path to the local package in my cabal.project. Why would a dependency be compiled differently depending on where it comes from? Any suggestions on how to troubleshoot this? To be more concrete, the relevant packages are generic-random and splitmix. The following commands should reproduce the issue: git clone https://github.com/Lysxia/generic-random git clone https://github.com/phadej/splitmix cd generic-random # With local splitmix echo "packages: . ../splitmix" > cabal.project cabal test --flags="enable-inspect" # PASS # With remote splitmix echo "packages: ." > cabal.project cabal test --flags="enable-inspect" # FAIL It would be useful to know whether anyone can reproduce this behavior or not. Cheers, Li-yao PS, link to Github issue: https://github.com/Lysxia/generic-random/issues/22 From icfp.publicity at googlemail.com Fri Aug 7 02:47:37 2020 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Thu, 06 Aug 2020 22:47:37 -0400 Subject: [Haskell-cafe] Second Call for Participation: ICFP 2020 Message-ID: <5f2cc0c98f82b_1e99e29416d0@homer.mail> ===================================================================== Second Call for Participation ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 23 - August 28, 2020 Online http://icfp20.sigplan.org/ Early Registration ends August 8! ==================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. Watch our new video, and Don't Stop ICFP: https://www.youtube.com/watch?v=Fte5wwnwCws Early Registration ends August 8th! Registration for students with an ACM or SIGPLAN membership is free, and anyone can apply for a fee waiver at: https://icfp20.sigplan.org/attending/Registration This year, the conference will be a virtual event. All activities will take place online. The main conference will take place from August 24-26, 2020 during two time bands. The first band will be 9AM-5:30PM New York, and will include both technical and social activities. The second band will repeat (with some variation) the technical program and social activities 12 hours later, 9AM-5:30PM Beijing, the following day. We've written a blog post about how conference mirroring will work for ICFP: https://blog.sigplan.org/2020/08/04/come-to-virtual-icfp/ We’re excited to announce our two invited speakers for 2020: Evan Czaplicki, covering the Elm programming language and hard lessons learned on driving adoption of new programming languages; and Audrey Tang, Haskeller and Taiwan’s Digital Minister, on how software developers can contribute to fighting the pandemic. ICFP has officially accepted 37 exciting papers, and (as a fresh experiment this year) there will also be presentations of 8 papers accepted recently to the Journal of Functional Programming. Co-located symposia and workshops will take place the day before and two days immediately after the main conference. Registration is now open. The early registration deadline is August 8th, 2020. Registration is not free, but is significantly lower than usual. Students who are ACM or SIGPLAN members may register for FREE before the early deadline. https://regmaster.com/2020conf/ICFP20/register.php New this year: Attendees will be able to sign-up for the ICFP Mentoring Program (either to be a mentor, receive mentorship or both). * Overview and affiliated events: http://icfp20.sigplan.org/home * Full Schedule: https://icfp20.sigplan.org/program/program-icfp-2020 * Accepted papers: http://icfp20.sigplan.org/track/icfp-2020-papers#event-overview * JFP Talks: https://icfp20.sigplan.org/track/icfp-2020-jfp-talks#event-overview * Registration is available via: https://regmaster.com/2020conf/ICFP20/register.php Early registration ends 8 August, 2020. * Programming contest: https://icfpcontest2020.github.io/ * Student Research Competition: https://icfp20.sigplan.org/track/icfp-2020-Student-Research-Competition * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference This year, there are 10 events co-located with ICFP: * Erlang Workshop (8/23) * Haskell Implementors' Workshop (8/28) * Haskell Symposium (8/27-8/28) * Higher-Order Programming with Effects (8/23) * miniKanren Workshop (8/27) * ML Family Workshop (8/27) * OCaml Workshop (8/28) * Programming Languages Mentoring Workshop (8/23) * Scheme Workshop (8/28) * Type-Driven Development (8/23) ### ICFP Organizers General Chair: Stephanie Weirich (University of Pennsylvania, USA) Program Chair: Adam Chlipala (MIT, USA) Artifact Evaluation Co-Chairs: Brent Yorgey (Hendrix College, USA) Ben Lippmeier (Ghost Locomotion, Australia) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organizer: Igor Lukanin (Kontur, Russia) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Youyou Cong (Tokyo Institute of Technology, Japan) Workshops Co-Chair: Jennifer Hackett (University of Nottingham, UK) Leonidas Lampropoulos (University of Pennsylvania, USA) Video Chair: Leif Andersen (Northeastern University, USA) Student Volunteer Co-Chair: Hanneli Tavante (McGill University, Canada) Victor Lanvin (IRIF, Université Paris Diderot, France) From evan at evan-borden.com Fri Aug 7 14:55:31 2020 From: evan at evan-borden.com (Evan Borden) Date: Fri, 7 Aug 2020 09:55:31 -0500 Subject: [Haskell-cafe] ANN: network 3.1.2.0 Message-ID: I'm happy to announce the release of network 3.1.2.0. https://hackage.haskell.org/package/network-3.1.2.0 This version of network includes many improvements that allow more extensibility, portability, and greater test coverage. See the log below for more information. As well version 3.1.1.0 and 3.1.1.1 have been deprecated as they contain a bug in graceful close, more details below. - Added -f devel for test cases that are known to fail. #471 - Improved precedence-compliant Read/Show instances. Verified via QuickCheck. #465 #466 - Removed the racing graceful close implementation to avoid issues with CLOSE_WAIT. #460 - Gracefully handle binding of UNIX domain sockets. #460 - Replace Socket type and family with extensible CInt pattern and synonyms. #459 - Fixed race conditions in tests. #458 - Removed many legacy uses of undefined. #456 - Defined extensible CustomSockOpt via ViewPatterns. #455 - Defined openSocket in terms of AddrInfo. 5b0987197fe2ed7beddd7b2096522d624e71151e - Improved FreeBSD portability for Control Messages and tests #452 - Support sendMsg and recvMsg #433 #445 #451 - Added sendMsg and recvMsg APIs - Redefined SocketOption as pattern synonym - Implement total Show functions for SockAddr #441 - Improve portability changing u_int32_t to uint32_t. #442 - Removed obsolete CPP statements. d1f4ee60ce6a4a85abb79532f64d4a4e71e2b1ce - Loads of improved test coverage. cbd67cc50a37770432eb978ac8b8eb6da3664817 fcc2d86d53a6bec793f6a979a9e8fdf7fe3f4c22 6db96969b3e8974abbfd50a7f073baa57376fd5e As always, thank you to network's contributors! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lysxia at gmail.com Fri Aug 7 15:09:47 2020 From: lysxia at gmail.com (Li-yao Xia) Date: Fri, 7 Aug 2020 11:09:47 -0400 Subject: [Haskell-cafe] Core optimizations affected by package provenance In-Reply-To: <2c5ac73d-4ba1-b2e9-d3ac-3d14898ae30a@gmail.com> References: <2c5ac73d-4ba1-b2e9-d3ac-3d14898ae30a@gmail.com> Message-ID: <42bae087-2dcb-1cbf-e392-4eeaec05f9f6@gmail.com> Dear Café, The reasonable explanation for this issue is that changing where splitmix comes from changes the version of random. When using only dependencies from Hackage, I got random-1.2 (latest version). When depending on splitmix locally (same version), I got random-1.1. cabal refuses to upgrade to 1.2, presumably because it sees a spurious cyclic dependency: random-1.2 depends on splitmix whose test suite depends on random. So there is a discrepancy in how cabal handles local packages, but at least it's not as weird as my previous hypothesis of building with different compiler flags. Li-yao On 8/6/2020 9:52 PM, Li-yao Xia wrote: > Hello Café, > > I've been testing properties of some optimized Core using the > inspection-testing library. Some functions appear to be optimized > differently depending on whether one of the package dependencies comes > from Hackage or elsewhere. As far as I can tell, the source code is > identical, and the only difference is whether or not I add the path to > the local package in my cabal.project. > > Why would a dependency be compiled differently depending on where it > comes from? > Any suggestions on how to troubleshoot this? > > To be more concrete, the relevant packages are generic-random and > splitmix. The following commands should reproduce the issue: > > > git clone https://github.com/Lysxia/generic-random > git clone https://github.com/phadej/splitmix > cd generic-random > > # With local splitmix > echo "packages: . ../splitmix" > cabal.project > cabal test --flags="enable-inspect" > # PASS > > # With remote splitmix > echo "packages: ." > cabal.project > cabal test --flags="enable-inspect" > # FAIL > > > It would be useful to know whether anyone can reproduce this behavior or > not. > > Cheers, > Li-yao > > PS, link to Github issue: > https://github.com/Lysxia/generic-random/issues/22 From icfp.publicity at googlemail.com Fri Aug 7 16:37:20 2020 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Fri, 07 Aug 2020 12:37:20 -0400 Subject: [Haskell-cafe] Call for Tutorial Participation: ICFP 2020 Message-ID: <5f2d83409ca54_1fbf629416946@homer.mail> CALL FOR TUTORIAL PARTICIPATION ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 23 - 28, 2020 Virtual https://icfp20.sigplan.org/ Early Registration ends August 8! The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 23-28, 2020. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. This year, ICFP features a wide variety of tutorials on topics related to functional programming, including design, education, tools, and more. Tutorials are available to all ICFP participants with registration. Tutorials occur before or after ICFP, co-located with the associated workshops, on August 23 or August 27-28. The schedule of ICFP Tutorials can be found at: https://icfp20.sigplan.org/track/icfp-2020-tutorials#program ICFP Early Registration ends on August 8th, and is available at: https://icfp20.sigplan.org/attending/Registration From lysxia at gmail.com Fri Aug 7 20:14:07 2020 From: lysxia at gmail.com (Li-yao Xia) Date: Fri, 7 Aug 2020 16:14:07 -0400 Subject: [Haskell-cafe] Where does the name "Algebraic data types" come from? Message-ID: Dear Café, What makes "algebraic data types" algebraic? There are at least two common explanations in use: 1. Algebraic data types are defined using sums and products of types, by analogy with, well, concepts from algebra. 2. Algebraic data types are initial algebras. There are numerous blogs online explaining "algebraic data types" that way, with a large majority adopting the more approachable explanation (1). The question is, how did the appellation "algebraic" come about historically? Did it start with one or both of the meanings above? The language feature, independently of the name, seems attributed to the HOPE language[1] (see for instance A History of Haskell: Being Lazy with Class[2]). However, the paper introducing HOPE does not use the word "algebraic" anywhere. Other papers on the topic do not discuss the origins of the word. I am curious about citations regarding the history of the name "algebraic data types" itself. Regards, Li-yao [1]: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.8135 [2]: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf From a.pelenitsyn at gmail.com Fri Aug 7 20:45:23 2020 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Fri, 7 Aug 2020 16:45:23 -0400 Subject: [Haskell-cafe] Where does the name "Algebraic data types" come from? In-Reply-To: References: Message-ID: Hey Li-yao, This sort of questions is really popular in the TYPES mailing list: you might want to ask there, e.g. if nothing comes up here. — Best, Artem On Fri, Aug 7, 2020 at 4:15 PM Li-yao Xia wrote: > Dear Café, > > What makes "algebraic data types" algebraic? There are at least two > common explanations in use: > > 1. Algebraic data types are defined using sums and products of types, by > analogy with, well, concepts from algebra. > > 2. Algebraic data types are initial algebras. > > There are numerous blogs online explaining "algebraic data types" that > way, with a large majority adopting the more approachable explanation (1). > > The question is, how did the appellation "algebraic" come about > historically? Did it start with one or both of the meanings above? > > The language feature, independently of the name, seems attributed to the > HOPE language[1] (see for instance A History of Haskell: Being Lazy with > Class[2]). However, the paper introducing HOPE does not use the word > "algebraic" anywhere. Other papers on the topic do not discuss the > origins of the word. I am curious about citations regarding the history > of the name "algebraic data types" itself. > > Regards, > Li-yao > > [1]: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.8135 > [2]: > > https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf > _______________________________________________ > 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 duke.j.david at gmail.com Fri Aug 7 22:06:28 2020 From: duke.j.david at gmail.com (David Duke) Date: Fri, 7 Aug 2020 23:06:28 +0100 Subject: [Haskell-cafe] Where does the name "Algebraic data types" come from? In-Reply-To: References: Message-ID: Also Have a look at work on algebraic specification e.g. CLEAR, and OBJ, CLU work by Joseph Goguen, Rob Burstall, Jose Meseguer, Liskov and others. The former introduced the idea of using initial algebras. I couldn't state offhand which came first, however there was quite a bit of activity in the 70s that centered on using algebras and ideas from category theory for specification and implementation. cf the ML module system. Apologies to anyone whose name I've omitted, its been sometime since I walked in that space. regards David On Fri, Aug 7, 2020 at 9:46 PM Artem Pelenitsyn wrote: > Hey Li-yao, > > This sort of questions is really popular in the TYPES mailing list: you > might want to ask there, e.g. if nothing comes up here. > > — > Best, Artem > > On Fri, Aug 7, 2020 at 4:15 PM Li-yao Xia wrote: > >> Dear Café, >> >> What makes "algebraic data types" algebraic? There are at least two >> common explanations in use: >> >> 1. Algebraic data types are defined using sums and products of types, by >> analogy with, well, concepts from algebra. >> >> 2. Algebraic data types are initial algebras. >> >> There are numerous blogs online explaining "algebraic data types" that >> way, with a large majority adopting the more approachable explanation (1). >> >> The question is, how did the appellation "algebraic" come about >> historically? Did it start with one or both of the meanings above? >> >> The language feature, independently of the name, seems attributed to the >> HOPE language[1] (see for instance A History of Haskell: Being Lazy with >> Class[2]). However, the paper introducing HOPE does not use the word >> "algebraic" anywhere. Other papers on the topic do not discuss the >> origins of the word. I am curious about citations regarding the history >> of the name "algebraic data types" itself. >> >> Regards, >> Li-yao >> >> [1]: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.8135 >> [2]: >> >> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf >> _______________________________________________ >> 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. -- David Duke Emeritus Professor of Computer Science School of Computing University of Leeds UK E:duke.j.david at gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sat Aug 8 14:45:33 2020 From: ben.franksen at online.de (Ben Franksen) Date: Sat, 8 Aug 2020 16:45:33 +0200 Subject: [Haskell-cafe] [ANN] Darcs 2.14.5 release Message-ID: Hi all, on behalf of the Darcs team, I would like to announce the release of Darcs 2.14.5: https://hackage.haskell.org/package/darcs-2.14.5 This is a bug-fix release and will be the latest release in the 2.14 series. In no way does it reflect the state of our development branch; instead it contains only a very small amount of changes needed to fix an ugly bug we recently discovered and which affects all previous versions in the 2.12 and 2.14 series. Upgrading is advised to avoid future incompatibilities. See the CHANGELOG for details. We will soon release 2.16.1 which will contain the large amount of work that has gone into darcs since the release of 2.14.0 more than two years ago. Cheers Ben From publicityifl at gmail.com Tue Aug 11 18:22:30 2020 From: publicityifl at gmail.com (Jurriaan Hage) Date: Tue, 11 Aug 2020 11:22:30 -0700 Subject: [Haskell-cafe] Third call for draft papers for IFL 2020 (Implementation and Application of Functional Languages) Message-ID: Hello, Please, find below the third call for draft papers for IFL 2020. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ================================================================================ IFL 2020 32nd Symposium on Implementation and Application of Functional Languages venue: online 2nd - 4th September 2020 https://www.cs.kent.ac.uk/events/2020/ifl20/ ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2020 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialisation - run-time code generation - partial evaluation - (abstract) interpretation - meta-programming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Post-symposium peer-review Following IFL tradition, IFL 2020 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. ### Important dates Submission deadline of draft papers: 17 August 2020 Notification of acceptance for presentation: 19 August 2020 Registration deadline: 31 August 2020 IFL Symposium: 2-4 September 2020 Submission of papers for proceedings: 7 December 2020 Notification of acceptance: 3 February 2021 Camera-ready version: 15 March 2021 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Programme committee Kenichi Asai, Ochanomizu University, Japan Olaf Chitil, University of Kent, United Kingdom (chair) Martin Erwig, Oregon State University,United States Daniel Horpacsi, Eotvos Lorand University, Hungary Zhenjiang Hu, Peking University, China Hans-Wolfgang Loidl, Heriot-Watt University, United Kingdom Neil Mitchell, Facebook, UK Marco T. Morazan, Seton Hall University, United States Rinus Plasmeijer, Radboud University, Netherlands Colin Runciman, University of York, United Kingdom Mary Sheeran, Chalmers University of Technology, Sweden Josep Silva, Universitat Politecnica de Valencia, Spain Jurrien Stutterheim, Standard Chartered, Singapore Josef Svenningsson, Facebook, UK Peter Thiemann, University of Freiburg, Germany Kanae Tsushima, National Institute of Informatics, Japan. Marcos Viera, Universidad de la Republica, Montevideo, Uruguay Janis Voigtlander, University of Duisburg-Essen, Germany ### Virtual symposium Because of the Covid-19 pandemic, this year IFL 2020 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Aug 12 00:21:43 2020 From: david.feuer at gmail.com (David Feuer) Date: Tue, 11 Aug 2020 20:21:43 -0400 Subject: [Haskell-cafe] New package: compact-sequences Message-ID: I've gotten the code I wrote for my Haskell Love talk into (just barely) good enough shape to make an initial release. So far, I have implemented stacks and queues that take n + O(log n) space, and whose basic operations take O(log n) time. I hope to add deques soon. More urgently, I need to write a test suite. Furthermore, I have written only "simple" versions, that directly use the mechanism described in my talk. To get decent performance, it will probably be necessary to add a layer on top of that. The package can be found at http://hackage.haskell.org/package/compact-sequences-0.1.0.0 David Feuer From mgajda at mimuw.edu.pl Thu Aug 13 13:18:48 2020 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Thu, 13 Aug 2020 15:18:48 +0200 Subject: [Haskell-cafe] Fwd: Call for participation: Code generation tutorial on ICFP2020 In-Reply-To: References: Message-ID: Hello, I organize tutorial on code generation for ICFP2020. https://icfp20.sigplan.org/details/icfp-2020-tutorials/4/Best-Practices-in-Code-Generation We invite participants interested in large scale code generation, including but not limited to: * large API bindings projects like Amazonka, * transpilers and compilers, * parser and data binding generation. We provide instruction and exercise templates in Haskell, but users of any functional programming language are welcome. After completing this tutorial, participants will be familiar with best current practices: * propagating source positions to final error messages. * useful monad transformers stacks, * tagging code for unidirectional or bidirectional code generation, * making code readable and debuggable by the end-user, * policy on releasing new versions, * techniques for automatic generation of changelogs, * managing version migrations, * reusing parsers for AST construction, * avoiding common issues with generated code. I encourage attendees to register their interests and requirements in advance: https://forms.gle/ETAhPxAprLHFWqyU6 Hope to see you there! -- Cheers Michał -- Pozdrawiam Michał From david.feuer at gmail.com Thu Aug 13 18:32:00 2020 From: david.feuer at gmail.com (David Feuer) Date: Thu, 13 Aug 2020 14:32:00 -0400 Subject: [Haskell-cafe] Is it a thunk? Message-ID: For testing purposes, I'd like to distinguish between thunks and non-thunks, to make sure that everything I require to be forced is. (I'd also like to know that nothing that's supposed to be lazy is forced, but that seems too hard to test in context.) Is there some magic I can use to check? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaro.reinders at gmail.com Thu Aug 13 18:42:16 2020 From: jaro.reinders at gmail.com (Jaro Reinders) Date: Thu, 13 Aug 2020 20:42:16 +0200 Subject: [Haskell-cafe] Is it a thunk? In-Reply-To: References: Message-ID: Maybe StrictCheck fits your needs: https://hackage.haskell.org/package/StrictCheck. I haven't used it. I think there is a paper about it in ICFP 2018. On 8/13/20 8:32 PM, David Feuer wrote: > For testing purposes, I'd like to distinguish between thunks and > non-thunks, to make sure that everything I require to be forced is. (I'd > also like to know that nothing that's supposed to be lazy is forced, but > that seems too hard to test in context.) Is there some magic I can use to > check? > > > _______________________________________________ > 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 profunctor at pm.me Thu Aug 13 18:47:32 2020 From: profunctor at pm.me (Marcin Szamotulski) Date: Thu, 13 Aug 2020 18:47:32 +0000 Subject: [Haskell-cafe] Is it a thunk? In-Reply-To: References: Message-ID: Hi David, At IOHK we are using `ghc-heap` which is bundled with a recent version of ghc. We have a bit of architecture which allow to test for unexpected thunks and it worked very well for us: https://github.com/input-output-hk/cardano-prelude/blob/master/src/Cardano/Prelude/GHC/Heap/NormalForm/Classy.hs#L69 Best regards, Marcin Szamotulski ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, August 13, 2020 8:32 PM, David Feuer wrote: > For testing purposes, I'd like to distinguish between thunks and non-thunks, to make sure that everything I require to be forced is. (I'd also like to know that nothing that's supposed to be lazy is forced, but that seems too hard to test in context.) Is there some magic I can use to check? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From david.feuer at gmail.com Thu Aug 13 18:54:02 2020 From: david.feuer at gmail.com (David Feuer) Date: Thu, 13 Aug 2020 14:54:02 -0400 Subject: [Haskell-cafe] Is it a thunk? In-Reply-To: References: Message-ID: Thanks, Marcin. That looks like what I'm after. On Thu, Aug 13, 2020, 2:47 PM Marcin Szamotulski wrote: > Hi David, > > At IOHK we are using `ghc-heap` which is bundled with a recent version of > ghc. We have a bit of architecture which allow to test for unexpected > thunks and it worked very well for us: > https://github.com/input-output-hk/cardano-prelude/blob/master/src/Cardano/Prelude/GHC/Heap/NormalForm/Classy.hs#L69 > > Best regards, > Marcin Szamotulski > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Thursday, August 13, 2020 8:32 PM, David Feuer > wrote: > > For testing purposes, I'd like to distinguish between thunks and > non-thunks, to make sure that everything I require to be forced is. (I'd > also like to know that nothing that's supposed to be lazy is forced, but > that seems too hard to test in context.) Is there some magic I can use to > check? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Aug 13 18:55:58 2020 From: david.feuer at gmail.com (David Feuer) Date: Thu, 13 Aug 2020 14:55:58 -0400 Subject: [Haskell-cafe] Is it a thunk? In-Reply-To: References: Message-ID: StrictCheck is very useful, but not in this context—the values I'm looking at are nodes in the spine of a data structure, not values it's storing. On Thu, Aug 13, 2020, 2:42 PM Jaro Reinders wrote: > Maybe StrictCheck fits your needs: > https://hackage.haskell.org/package/StrictCheck. I haven't used it. I > think > there is a paper about it in ICFP 2018. > > On 8/13/20 8:32 PM, David Feuer wrote: > > For testing purposes, I'd like to distinguish between thunks and > > non-thunks, to make sure that everything I require to be forced is. (I'd > > also like to know that nothing that's supposed to be lazy is forced, but > > that seems too hard to test in context.) Is there some magic I can use to > > check? > > > > > > _______________________________________________ > > 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 Fri Aug 14 01:02:52 2020 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Fri, 14 Aug 2020 01:02:52 +0000 Subject: [Haskell-cafe] [ANN] base64-bytestring-1.2.0.0 Message-ID: Hi everyone! I’m pleased to announce base64-bytestring-1.2.0.0. In this release, we cleared out the backlog of outstanding feature requests, correctness, and security fixes to present a new stable release. This constituted a major version bump due to the fact that the fixes changed the semantics of the decode function for some inputs, making the decoding process more correct than it was previously. To illustrate one of the changes to correctness, here’s a quick quiz: ``` What are the correct results of Base64-decoding the strings "ZK==“, "Zm9vYE==“, or "Zm9vYmD=" ? ``` The answer is: the decoding should fail. Why? Even though the above strings may look like externally valid Base64 strings, they are technically impossible to construct such string via Base64-encoding from any binary data in the first place. Previously (and historically in every version up until this release), they would pass decoding, but fail to roundtrip: ``` П> decode "ZK==" Right "d" П> encode "d" "ZA==" П> decode "Zm9vYE==" Right "foo`" П> encode "foo`" "Zm9vYA==" П> decode "Zm9vYmD=" Right "foob`" П> encode "foob`" "Zm9vYmA=" ``` This was the result of leaking bits when decoding the final quanta of the bytestring. I caught this, and provided a fix. Now here’s an interesting point: there are very few libraries out there that actually address this problem! In fact, there was only one other library out there that I was able to find that was fully correct-per-RFC-spec, which was the Java Amazon SDK. So I guess we can be proud of Haskell in that sense now? I’ve implemented the same in my `base64` library on hackage using the same bitmasking verification techniques, so that one is up to date as well. Anyway, cheers and happy hacking, Emily -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Fri Aug 14 13:22:51 2020 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 14 Aug 2020 09:22:51 -0400 Subject: [Haskell-cafe] 3rd Call for Papers: REBLS 20: Reactive and Event-Based Languages and Systems Message-ID: Dear all, Apologies if you see this multiple times. Gentle reminder that the REBLS workshop will take place online. The deadline has been extended till next week. Cheers, Ivan CALL FOR PAPERS 7th Workshop on Reactive and Event-based Languages and Systems (REBLS 2020) co-located with the SPLASH Conference *** BOTH EVENTS WILL NOW TAKE PLACE ONLINE *** Sun 15 - Fri 20 November 2020 Website: https://2020.splashcon.org/home/rebls-2020 IMPORTANT DATES Submission Deadline: 21 Aug 2020 (extended) Author Notification: 18 Sep 2020 Camera Ready Deadline: 9 Oct 2020 INTRODUCTION Reactive programming and event-based programming are two closely related programming styles that are becoming more important with the ever increasing requirement for applications to run on the web or on mobile devices, and the advent of advanced High-Performance Computing (HPC) technology. A number of publications on middleware and language design -- so-called reactive and event-based languages and systems (REBLS) -- have already seen the light, but the field still raises several questions. For example, the interaction with mainstream language concepts is poorly understood, implementation technology is still lacking, and modularity mechanisms remain largely unexplored. Moreover, large applications are still to be developed, and, consequently, patterns and tools for developing large reactive applications are still in their infancy. This workshop will gather researchers in reactive and event-based languages and systems. The goal of the workshop is to exchange new technical research results and to better define the field by developing taxonomies and discussing overviews of the existing work. We welcome all submissions on reactive programming, functional reactive programming, and event- and aspect- oriented systems, including but not limited to: * Language design, implementation, runtime systems, program analysis, software metrics, patterns and benchmarks. * Formal models for reactive and event-based programming. * Study of the paradigm: interaction of reactive and event-based programming with existing language features such as object-oriented programming, pure functional programming, mutable state, concurrency. * Modularity and abstraction mechanisms in large systems. * Advanced event systems, event quantification, event composition, aspect-oriented programming for reactive applications. * Functional Reactive Programming (FRP), self-adjusting computation and incremental computing. * Synchronous languages, modeling real-time systems, safety-critical reactive and embedded systems. * Applications, case studies that show the efficacy of reactive programming. * Empirical studies that motivate further research in the field. * Patterns and best-practices. * Related fields, such as complex event processing, reactive data structures, view maintenance, constraint-based languages, and their integration with reactive programming. * Implementation technology, language runtimes, virtual machine support, compilers. * IDEs, Tools. The format of the workshop is that of a mini-conference. Participants can present their work in slots of 30 mins with Q&A included. Because of the declarative nature of reactive programs, it is often hard to understand their semantics just by looking at the code. We therefore also encourage authors to use their slots for presenting their work based on live demos. SUBMISSIONS REBLS encourages submissions of two types of papers: * Full papers: papers that describe complete research results. These papers will be published in the ACM digital library. * In-progress papers: papers that have the potential of triggering an interesting discussion at the workshop or present new ideas that require further systematic investigation. These papers will not be published in the ACM digital library. Format: * Submissions should use the ACM SIGPLAN Conference acmart Format with the two-column, sigplan Subformat, 10 point font, using Biolinum as sans-serif font and Libertine as serif font. All submissions should be in PDF format. If you use LaTeX or Word, please use the ACM SIGPLAN acmart Templates. The page http://www.sigplan.org/Resources/Author/#acmart-format contains instructions for authors, and a package that includes an example file acmart-sigplan.tex. * Authors are required to explicitly specify the type of paper in the submission (i.e., full paper, in-progress paper). * Full papers can be *up to* 12 pages in length, excluding references. In-progress papers can be *up to* 6 pages, excluding references. Papers do not need to make use of all pages, but they will be summarily rejected if they exceed the page limits. Instructions for the Authors: * Papers should be submitted through: https://rebls20.hotcrp.com/ * For fairness reasons, all submitted papers should conform to the formatting instructions. Submissions that violate these instructions will be summarily rejected. * Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. * Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy (http://www.sigplan.org/Resources/Policies/Republication). Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism. * All submissions are expected to comply with the ACM Policies for Authorship detailed at https://www.acm.org/publications/authors/information-for-authors. PROGRAM COMMITTEE Ivan Perez (PC Chair; NIA) Alan Jeffrey, Mozilla Research. Christiaan Baaij, QBayLogic. César Sánchez, IMDEA Software. Daniel Winograd-Cort, Target Corp. Edward Amsden, Black River Software, LLC. Guerric Chupin, University of Nottingham. Heinrich Apfelmus. Jonathan Thaler, University of Applied Sciences Vorarlberg. Louis Mandel, IBM Research. Manuel Bärenz, sonnen eServices GmbH. Marc Pouzet, Université Pierre et Marie Curie. Mark Santolucito, University of Yale. Neil Sculthorpe, University of Nottingham Trent. Noemi Rodriguez, Pontifícia Universidade Católica do Rio de Janeiro Oleksandra Bulgakova, Sukhomlynsky Mykolaiv National University Patrick Bahr, University of Copenhagen Takuo Watanabe, Tokyo Institute of Technology Tetsuo Kamina, Oita University Tom Van Cutsem, Nokia Bell Labs Yoshiki Ohshima, HARC / Y Combinator Research STEERING COMMITTEE Guido Salvaneschi, TU Darmstadt, Germany Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium Patrick Eugster, Universita della Svizzera Italiana, Switzerland Francisco Sant'Anna, Rio de Janeiro State University, Brazil Lukasz Ziarek, SUNY Buffalo, United States For any questions, please use the form on the website or contact the Chair at ivan.perezdominguez at nasa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch.gosch at googlemail.com Sat Aug 15 03:35:07 2020 From: ch.gosch at googlemail.com (Christian Gosch) Date: Fri, 14 Aug 2020 20:35:07 -0700 Subject: [Haskell-cafe] Library for serial communications? Message-ID: <25f088f8-bdb3-0a37-c9ba-0b3531f2e821@gmail.com> Hi Haskellers, I was wondering if there is a "canonical" choice of library for using serial interfaces from within Haskell. I found a few in Hackage, but all of them seem to not have seen updates in a few years. Any hint is much appreciated. Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1765 bytes Desc: not available URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Aug 16 12:17:11 2020 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 16 Aug 2020 13:17:11 +0100 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour Message-ID: <20200816121711.GE27294@cloudinit-builder> I have just noticed that with ScopedTypeVariables one can write the following bizarre definition -- Inferred signature: -- add :: Num a => a -> a -> a add (x :: a) (y :: b) = x + y The reason for this behaviour is that > in all patterns other than pattern bindings, a pattern type > signature may mention a type variable that is not in scope; in this > case, the signature brings that type variable into scope. https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#pattern-type-signatures and the justification is that > Bringing type variables into scope is particularly important for > existential data constructors But this leads to a rather puzzling user experience. Was it really not possible to design this extension in a way that would allow bringing new type variables into scope locally but not allow them to unify with other type variables from outer scopes? To be more concrete, what I would like to see is a design where `k` is allowed because the type `a` (bound within a pattern) does not need to unify with anything but `k2` is not allowed because `a` is forbidden to unify with `b`. `k3` would also be forbidden (the type variables called `a` are actually distinct) as would `k4` (the type variable for the inferred signature would be fresh and distinct from `a`). I believe this design might lead to much less puzzling behaviour. Would it be possible (within a new extension, of course) or have I overlooked something? Tom data T = forall a. MkT [a] k :: T -> T k (MkT [t::a]) = MkT t3 where (t3::[a]) = [t,t,t] data T2 a = MkT2 [a] k2 :: T2 b -> T2 b k2 (MkT2 [t::a]) = MkT2 t3 where (t3::[a]) = [t,t,t] k3 :: T2 a -> T2 a k3 (MkT2 [t::a]) = MkT2 t3 where (t3::[a]) = [t,t,t] k4 (MkT2 [t::a]) = MkT2 t3 where (t3::[a]) = [t,t,t] From anthony_clayden at clear.net.nz Mon Aug 17 05:08:10 2020 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 17 Aug 2020 17:08:10 +1200 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour Message-ID: Hi Tom, I see nothing bizarre nor counterintuitive. Perhaps you need to retrain your intuitions ;-) > I have just noticed that with ScopedTypeVariables one can write the > following bizarre definition > > -- Inferred signature: > -- add :: Num a => a -> a -> a > add (x :: a) (y :: b) = x + y What do you think is bizarre? GHC makes a reasonable attempt to use the tyvar names you put in a signature -- remembering that alpha-renaming means the name is not really significant. I can get `add :: Num c => c -> c -> c`, etc. > The reason for this behaviour is that > >>* in all patterns other than pattern bindings, a pattern type *>>* signature may mention a type variable that is not in scope; in this *>>* case, the signature brings that type variable into scope. * OK so your `PatternSignatures` (a part of `ScopedTypeVariables` that existed long before the more dubious parts of that extension) are bringing `a`, `b`, into scope. It might have been clearer if you'd used `b`, `c`, to avoid confusing yours with some `a` that might have been lurking in the environment. Anyhoo your definition is equivalent to this, by eta-reduction: add = (+) and `(+) :: Num a => a -> a -> a` from the Prelude. So the inferred signature for `add` must be the same, possibly alpha-renamed. Perhaps you think you could add an Int to a Float, as you can in languages (COBOL, Algol 68) with implicit type coercion? That's not what the signatures from the Prelude Num methods support. And with Haskell's proclivity for partial application, type inference would rapidly become incoherent; so we don't do that. > But this leads to a rather puzzling user experience. Was it really > not possible to design this extension in a way that would allow > bringing new type variables into scope locally but not allow them to > unify with other type variables from outer scopes? > > To be more concrete, what I would like to see is a design where `k` is > allowed because the type `a` (bound within a pattern) does not need to > unify with anything but `k2` is not allowed because `a` is forbidden > to unify with `b`. ... No: any tyvar might unify with any other. You can't ban tyvars from unifying. Unification would be useless if you can't unify globally. That's why all tyvars are (implicitly) universally quantified. (With the exception of existentially-quantified tyvars as you quote, which is another can of worms and we don't want to go there.) You can use as many distinct tyvars as you like, but if type inference resolves them to the same type, it must use the same tyvar in the inferred signature. > I believe this design might lead to much less puzzling behaviour. > Would it be possible (within a new extension, of course) or have I > overlooked something? There's the `GADTs` or `TypeFamilies` extensions that introduce `~` as a constraint-level equality on types. I suppose we might use that, but (thinking creatively) any of these would be a legitimate resulting signature; how should GHC choose amongst them? add :: (Num a, a ~ b) => a -> b -> a add :: (Num b, a ~ b) => a -> b -> b add :: (Num a, Num b, a ~ b) => a -> b -> a The point is: the return type for `add` aka `(+)` must be the same as the first argument type must be the same as the second argument type must be the same as the `Num` constraint applies to. Any of those three signatures I've given (and there could be several more in the same vein) obfuscates what's going on. Actually, thinking a bit more: we want to infer a 'Principal type' (see wikipedia). Precisely because there's no good reason to choose amongst those I gave, none of them can be Principal. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Mon Aug 17 10:50:54 2020 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 17 Aug 2020 22:50:54 +1200 Subject: [Haskell-cafe] Constraints as a moveable feast? Message-ID: There's the makings of a cute feature in a very old Haskell Language report. (With thanks to the 'Partial Type Constructors' 2019 paper for ferreting this out.) type Num a => Point a = (a, a) 1990 v1.0 Haskell report. Yes that's a type synonym with a constraint. I'll give their examples, though they don't really demonstrate the potential: origin :: Point Integer -- we get Num a => wanted then discharged for free origin = (0, 0) -- although the appearance of zero wants Num a anyway scale :: (Num a) => a -> Point a -> Point a -- seems wrong to give explicit Num a scale w (x,y) = (w*x, w*y) -- the above sig would be inferred anyway The feature disappeared without trace in the next year's Language report. I'm thinking we should be able to write scale :: a -> Point a -> Point a -- get Num a for free by: scale :: a -> (Num a => (a, a)) -> (Num a => (a, a)) -- expand the synonym -- this sig currently illegal scale :: Num a => a -> (a, a) -> (a, a) -- float the constraints out to the implicit forall So this isn't specific to type synonyms: in general allow prefixing constraints to any sub-term in a type; type inference floats them to the front of the signature. You can kinda get the effect today (so I don't think this is entirely whacky), by cunning use of dummies and term-level combinators: typePoint :: Num a => (a, a) typePoint = undefined scale w xy = const (undefined `asTypeOf` xy `asTypeOf` typePoint) (w `asTypeOf` fst xy) -- inferred scale :: Num a => a -> (a,a) -> (a,a) (Putting a dummy undefined on RHS to show there's nothing up my sleeves, because the actual expression would unify to the right type anyway.) You can get maybe cleaner code with PatternSignatures. But it's all workarounds in terms/expressions. I want to do the Right Thing and get it accepted as a stand-alone signature. A couple of caveats: * Haskell 1990 didn't have MultiParam Type Classes; * nor existential quant. So if a nested constraint mentions both an existential tyvar with narrow scope and a universally quant'd tyvar, can't float out that constraint, have to reject the sig. The constraint in `type Num a => Point a = ...` appearing to the left of the introduced type syn, is also reminiscent of DatatypeContexts, so we could similarly float out the constraints from those appearing within a sig(?) And this would be a way to put constraints on newtypes similarly(?) (Can't put constraints on those currently, because there's not really a data constructor to bind the class dictionary to. Haskell 1990 didn't have newtypes.) Or is there something deeply anti-System FC here? AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Mon Aug 17 13:30:59 2020 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 17 Aug 2020 15:30:59 +0200 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: References: Message-ID: On Mon, 17 Aug 2020 at 07:10, Anthony Clayden wrote: > Hi Tom, I see nothing bizarre nor counterintuitive. Perhaps you need to retrain your intuitions ;-) > > > I have just noticed that with ScopedTypeVariables one can write the > > following bizarre definition > > > > -- Inferred signature: > > -- add :: Num a => a -> a -> a > > add (x :: a) (y :: b) = x + y > > What do you think is bizarre? GHC makes a reasonable attempt to use the tyvar names you put in a signature -- remembering that alpha-renaming means the name is not really significant. I can get `add :: Num c => c -> c -> c`, etc. > > I can't speak for Tom, but to me the above feels very similar to writing something like: add :: _ => a -> b -> _ add x y = x + y But that doesn't type check, since the types `a` and `b` are not the same, but `+` needs them to be. Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Aug 17 16:32:31 2020 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 17 Aug 2020 17:32:31 +0100 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: References: Message-ID: <20200817163231.GG27294@cloudinit-builder> On Mon, Aug 17, 2020 at 05:08:10PM +1200, Anthony Clayden wrote: > Hi Tom, I see nothing bizarre nor counterintuitive. Perhaps you need > to retrain your intuitions ;-) Perhaps, but I think my intuitions are fairly sound. > > I have just noticed that with ScopedTypeVariables one can write the > > following bizarre definition > > > > -- Inferred signature: > > -- add :: Num a => a -> a -> a > > add (x :: a) (y :: b) = x + y > > What do you think is bizarre? Erik in his sibling post gave the reason: x and y are given types that appear not to match, but for the function to type check the types do indeed need to match. (My objection is really nothing to do with the choice of "a" for the inferred signature; I only put the inferred signature there to confirm that's indeed what it is.) > > But this leads to a rather puzzling user experience. Was it really > > not possible to design this extension in a way that would allow > > bringing new type variables into scope locally but not allow them to > > unify with other type variables from outer scopes? > > > > To be more concrete, what I would like to see is a design where `k` is > > allowed because the type `a` (bound within a pattern) does not need to > > unify with anything but `k2` is not allowed because `a` is forbidden > > to unify with `b`. ... > > No: any tyvar might unify with any other. You can't ban tyvars from > unifying. Unification would be useless if you can't unify globally. > That's why all tyvars are (implicitly) universally quantified. (With > the exception of existentially-quantified tyvars as you quote, which > is another can of worms and we don't want to go there.) [...] I think that's exactly where we (or I at least) want to go! It feels that what I'm asking for is very similar to the typechecking rules for existentials, although I'm not familiar enough with that part of the typechecker to say for sure. Tom From lexi.lambda at gmail.com Mon Aug 17 20:52:22 2020 From: lexi.lambda at gmail.com (Alexis King) Date: Mon, 17 Aug 2020 15:52:22 -0500 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: <20200816121711.GE27294@cloudinit-builder> References: <20200816121711.GE27294@cloudinit-builder> Message-ID: <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> I think this behavior is obscured by the way Haskell uses the term “type variable” to refer to three different things: Variables that refer to types and are bound within the type namespace. Skolem type constants introduced by a `forall`. Solver/unification variables, aka “metavariables”, which aren’t really types at all but holes to be filled in with types. These are all subtly different, but they are so frequently treated as if they were the same that I suspect listing them out is not actually enough for many people to understand the distinctions! So let me elaborate. Suppose we view `forall` like a type-level lambda, so `forall a. a -> a` is analogous to this term: \a -> a :-> a Clearly, there is a difference between the variable `a` in the above expression and the value we eventually substitute for it when we apply the lambda. When we instantiate the function by doing, say, `id @Int`, we substitute `Int` for `a` to get `Int -> Int`. So `a` itself isn’t a type, it’s a name that refers to a type—a type variable. Under this interpretation, there’s nothing wrong with your example. In add (x :: a) (y :: b) = x + y the variable `a` names `x`’s type, and the variable `b` names `y`’s type, and there’s nothing at all wrong with having two different names that refer to the same thing. It would be like writing this term: \t -> let { a = t; b = t } in a :-> b So why does it seem confusing? Well, because if we write add :: Num t => a -> b -> t we get a type error, not two aliases for t. This is because GHC will implicitly quantify all the variables in the type signature to get add :: forall t a b. Num t => a -> b -> t so `a` and `b` are now distinct, “lambda-bound” variables, not aliases for `t`. This implicit quantification means we don’t often think about the type variables we write in type signatures as being like term variables, which are just names that reference other things. Rather, we think of type variables as being like type constants, and in fact GHC encourages this interpretation in its error reporting. To explain, consider what happens when GHC checks `add` against the type we wrote above. Somehow, it needs to figure out the types of `x` and `y`, but it can’t just say x :: a y :: b because those variables were bound by the `forall` (they are “lambda-bound”), and if we move them into some other context where they appear free, they no longer have any meaning. GHC has to somehow pick actual types for x and y, not type variables. A naïve idea would be to invent two new solver variables, aka “holes to be filled in with inferred types”, yielding something like a1, b1 fresh x :: a1 y :: b1 but this doesn’t work. Imagine we did that while typechecking this function: bad :: a -> a bad _ = True If we invented a new solver variable to use in place of `a` while typechecking `bad`, GHC would just say “oh, I can fill in the hole with Bool” and carry on, which would be quite bad! The whole point of parametricity is that the function must work with any type. So GHC actually does something else. Behind the scenes, it creates two new type definitions, distinct from all other types in the program: data FakeTypeA data FakeTypeB Now it typechecks the function using these fake types substituted for `a` and `b`: x :: FakeTypeA y :: FakeTypeB Now when GHC goes to typecheck `x + y`, it will raise a type error, since FakeTypeA and FakeTypeB are obviously not the same type. This enforces parametricity. Of course, it would be very confusing to the user to see names like “FakeTypeA” in their type errors. So GHC pulls some sleight of hand, and it prints the new types it generates as just “a” and “b”, the same as the forall-bound variables it created them for. These don’t look like type constants, because in source Haskell, all type constants start with UpperCase. But behind the scenes, they really are type constants, not type variables. GHC calls these fake type constants “rigid variables” or “skolem variables,” but don’t be fooled: they’re not variables at all, they’re constants. GHC tells this white lie to keep programmers from having to think about all this behind the scenes business. When GHC says “could not match ‘a’ with ‘b’,” it’s natural for programmers to think “ah, these are the ‘a’ and ‘b’ I wrote in my type signature,” and they learn to treat “type variables” and “rigid type constants” as one and the same. They don’t think about how this is a meaningfully different definition of “variable” than what they’re used to at the term level. This works out okay because the only way to bind type variables in source Haskell 98/2010 is universal quantification. But now ScopedTypeVariables and ExistentialQuantification enter the picture, and there’s a problem: we suddenly need to be able to bind type variables in a place that isn’t `forall`. Now we have type variable binding sites that look just like type variable uses, but they aren’t implicitly-quantified the way they are in standalone type signatures, and confusion ensues. This confusion actually goes much deeper than you might expect. Because Haskell historically hasn’t syntactically distinguished type variable uses from binding sites, we have new ambiguous situations like this: \(x :: Maybe a) -> ... Is this a type annotation on x, which states that x should have type `Maybe a`, where `a` is a type variable already in scope? Or is it a pattern binding that matches against x’s type, which asserts that it has the shape `Maybe t` and binds a new variable `a` to the type `t`? And it gets even worse! Suppose we have this: f (Foo @a x) = ... Is `@a` a visible type application of `Foo` to the in-scope type `a`, instantiating the (universally-quantified) `Foo` constructor at a particular type? Or is it a binder for an existential variable “stored inside” `Foo`? Both are reasonable (and useful) interpretations. A GHC proposal that presents a design that sorts all these ambiguities out would be most welcome. To my knowledge, no such proposal currently exists, but I could be wrong—I know this issue has been discussed on some proposals (such as visible type applications in patterns), so maybe someone has come up with something I’m not aware of. Alexis > On Aug 16, 2020, at 07:17, Tom Ellis wrote: > > I have just noticed that with ScopedTypeVariables one can write the > following bizarre definition > > -- Inferred signature: > -- add :: Num a => a -> a -> a > add (x :: a) (y :: b) = x + y > > The reason for this behaviour is that > >> in all patterns other than pattern bindings, a pattern type >> signature may mention a type variable that is not in scope; in this >> case, the signature brings that type variable into scope. > > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#pattern-type-signatures > > and the justification is that > >> Bringing type variables into scope is particularly important for >> existential data constructors > > But this leads to a rather puzzling user experience. Was it really > not possible to design this extension in a way that would allow > bringing new type variables into scope locally but not allow them to > unify with other type variables from outer scopes? > > To be more concrete, what I would like to see is a design where `k` is > allowed because the type `a` (bound within a pattern) does not need to > unify with anything but `k2` is not allowed because `a` is forbidden > to unify with `b`. `k3` would also be forbidden (the type variables > called `a` are actually distinct) as would `k4` (the type variable for > the inferred signature would be fresh and distinct from `a`). > > I believe this design might lead to much less puzzling behaviour. > Would it be possible (within a new extension, of course) or have I > overlooked something? > > Tom > > > data T = forall a. MkT [a] > > k :: T -> T > k (MkT [t::a]) = > MkT t3 > where > (t3::[a]) = [t,t,t] > > data T2 a = MkT2 [a] > > k2 :: T2 b -> T2 b > k2 (MkT2 [t::a]) = > MkT2 t3 > where > (t3::[a]) = [t,t,t] > > k3 :: T2 a -> T2 a > k3 (MkT2 [t::a]) = > MkT2 t3 > where > (t3::[a]) = [t,t,t] > > k4 (MkT2 [t::a]) = > MkT2 t3 > where > (t3::[a]) = [t,t,t] -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Tue Aug 18 00:25:16 2020 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Tue, 18 Aug 2020 12:25:16 +1200 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: References: Message-ID: Well I'll go to 'foot of our stairs! > [Erik] the above feels very similar to writing something like: > add :: _ => a -> b -> _ > add x y = x + y > > But that doesn't type check, since the types `a` and `b` are not the same, > but `+` needs them to be. Replying to both Erik's and Tom's replies. I'm afraid Alexis' went completely over my head. As I mentioned, the `PatternSignatures` part of `ScopedTypeVariables` has been around a long time. So long that it's in Hugs 2006. The same? Not quite. If I try Tom's O.P. add (x :: aa) (y :: b) = x + y Hugs complains 'Type annotation uses distinct variables aa and b where a single variable was inferred'. So the short answer is: if that's how your intuitions go, use Hugs. My explanation was going to be (this now only applies for GHC): just as using `x, y` as the dummy arguments to `add` doesn't come with any guarantees they're distinct values; so using `aa, b` as the dummy variables doesn't come with any guarantees they're distinct types. Specifying distinct tyvars in a stand-alone signature is different: you're giving the most general type to which `add` must conform. And using distinct tyvars means `add` must cope with those being distinct types. (Which it's equation doesn't.) BTW GHC accepts: add (x :: aa) (y :: b) = (x + y :: aa) :: b which shows how happy it is to use distinct tyvars for the same type. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshchia at gmail.com Wed Aug 19 06:50:12 2020 From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=) Date: Wed, 19 Aug 2020 14:50:12 +0800 Subject: [Haskell-cafe] Dhall for Word8, Word16, Double, etc Message-ID: Hi, Let's say I have a record type: data Foo = Foo { v :: Word16 } I want to have a FromDhall instance for Foo. I know this is easy to do if v is Integer instead of Word16. But v is Word16. Does Dhall enable the user to cleanly express how to input a Word16 with the requisite range checks, or is the user expected to only use Integer and do his own conversion and range checks within Haskell after inputting the Integer from Dhall? I have a record with Word32, Word16, Word8 & Double fields instead of Integer & Scientific. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshchia at gmail.com Wed Aug 19 06:55:03 2020 From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=) Date: Wed, 19 Aug 2020 14:55:03 +0800 Subject: [Haskell-cafe] Dhall for Word8, Word16, Double, etc In-Reply-To: References: Message-ID: Correction to my original message: No problems for Double, which already has a FromDhall instance, but I'm trying to solve the problem for Word8, Word16 & Word32. Interestingly, Word8, Word16 & Word32 have ToDhall instances but no FromDhall instances. On Wed, Aug 19, 2020 at 2:50 PM ☂Josh Chia (謝任中) wrote: > Hi, > > Let's say I have a record type: > data Foo = Foo { v :: Word16 } > > I want to have a FromDhall instance for Foo. I know this is easy to do if > v is Integer instead of Word16. But v is Word16. Does Dhall enable the user > to cleanly express how to input a Word16 with the requisite range checks, > or is the user expected to only use Integer and do his own conversion and > range checks within Haskell after inputting the Integer from Dhall? I have > a record with Word32, Word16, Word8 & Double fields instead of Integer & > Scientific. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Wed Aug 19 15:05:24 2020 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Wed, 19 Aug 2020 10:05:24 -0500 Subject: [Haskell-cafe] Third Call for Participation: ICFP 2020 Message-ID: <5f3d3fb4d37a2_3df75294169f@homer.mail> ===================================================================== Third Call for Participation ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 23 - August 28, 2020 Online http://icfp20.sigplan.org/ Pre-registration ends August 21! ==================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. Watch our new video, and Don't Stop ICFP: https://www.youtube.com/watch?v=Fte5wwnwCws Pre-registration ends August 21st! https://icfp20.sigplan.org/attending/Registration This year, the conference will be a virtual event. All activities will take place online. There are training sessions for Clowdr, our new online platform, on August 20 and 21. https://icfp20.sigplan.org/track/icfp-2020-clowdr-training#program The main conference will take place from August 24-26, 2020 during two time bands. The first band will be 9AM-5:30PM New York, and will include both technical and social activities. The second band will repeat (with some variation) the technical program and social activities 12 hours later, 9AM-5:30PM Beijing, the following day. We've written a blog post about how conference mirroring will work for ICFP: https://blog.sigplan.org/2020/08/04/come-to-virtual-icfp/ We’re excited to announce our two invited speakers for 2020: Evan Czaplicki, covering the Elm programming language and hard lessons learned on driving adoption of new programming languages; and Audrey Tang, Haskeller and Taiwan’s Digital Minister, on how software developers can contribute to fighting the pandemic. ICFP has officially accepted 37 exciting papers, and (as a fresh experiment this year) there will also be presentations of 8 papers accepted recently to the Journal of Functional Programming. Co-located symposia and workshops will take place the day before and two days immediately after the main conference. Registration is now open. The early registration deadline is August 8th, 2020. Registration is not free, but is significantly lower than usual. Students who are ACM or SIGPLAN members may register for FREE before the early deadline. https://regmaster.com/2020conf/ICFP20/register.php New this year: Attendees will be able to sign-up for the ICFP Mentoring Program (either to be a mentor, receive mentorship or both). * Overview and affiliated events: http://icfp20.sigplan.org/home * Full Schedule: https://icfp20.sigplan.org/program/program-icfp-2020 * Accepted papers: http://icfp20.sigplan.org/track/icfp-2020-papers#event-overview * JFP Talks: https://icfp20.sigplan.org/track/icfp-2020-jfp-talks#event-overview * Registration is available via: https://regmaster.com/2020conf/ICFP20/register.php Early registration ends 8 August, 2020. * Programming contest: https://icfpcontest2020.github.io/ * Student Research Competition: https://icfp20.sigplan.org/track/icfp-2020-Student-Research-Competition * Tutorials https://icfp20.sigplan.org/track/icfp-2020-tutorials#program * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference This year, there are 10 events co-located with ICFP: * Erlang Workshop (8/23) * Haskell Implementors' Workshop (8/28) * Haskell Symposium (8/27-8/28) * Higher-Order Programming with Effects (8/23) * miniKanren Workshop (8/27) * ML Family Workshop (8/27) * OCaml Workshop (8/28) * Programming Languages Mentoring Workshop (8/23) * Scheme Workshop (8/28) * Type-Driven Development (8/23) As well as tutorials on 8/23, 8/27, and 8/28. ### ICFP Organizers General Chair: Stephanie Weirich (University of Pennsylvania, USA) Program Chair: Adam Chlipala (MIT, USA) Artifact Evaluation Co-Chairs: Brent Yorgey (Hendrix College, USA) Ben Lippmeier (Ghost Locomotion, Australia) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organizer: Igor Lukanin (Kontur, Russia) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Youyou Cong (Tokyo Institute of Technology, Japan) Workshops Co-Chair: Jennifer Hackett (University of Nottingham, UK) Leonidas Lampropoulos (University of Pennsylvania, USA) Video Chair: Leif Andersen (Northeastern University, USA) Student Volunteer Co-Chair: Hanneli Tavante (McGill University, Canada) Victor Lanvin (IRIF, Université Paris Diderot, France) From vamchale at gmail.com Wed Aug 19 16:21:35 2020 From: vamchale at gmail.com (Vanessa McHale) Date: Wed, 19 Aug 2020 11:21:35 -0500 Subject: [Haskell-cafe] Dhall for Word8, Word16, Double, etc In-Reply-To: References: Message-ID: <513D3A10-2209-491C-8FCB-568AB1A1D924@gmail.com> I guess if one had FromDhall instances you would need to fail sometimes! What I have done in such situations is make separate TypeDhallVersion types which I convert by hand. Cheers, Vanessa McHale > On Aug 19, 2020, at 1:55 AM, ☂Josh Chia (謝任中) wrote: > > Correction to my original message: No problems for Double, which already has a FromDhall instance, but I'm trying to solve the problem for Word8, Word16 & Word32. > > Interestingly, Word8, Word16 & Word32 have ToDhall instances but no FromDhall instances. > > On Wed, Aug 19, 2020 at 2:50 PM ☂Josh Chia (謝任中) > wrote: > Hi, > > Let's say I have a record type: > data Foo = Foo { v :: Word16 } > > I want to have a FromDhall instance for Foo. I know this is easy to do if v is Integer instead of Word16. But v is Word16. Does Dhall enable the user to cleanly express how to input a Word16 with the requisite range checks, or is the user expected to only use Integer and do his own conversion and range checks within Haskell after inputting the Integer from Dhall? I have a record with Word32, Word16, Word8 & Double fields instead of Integer & Scientific. > > _______________________________________________ > 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 lexi.lambda at gmail.com Wed Aug 19 17:12:54 2020 From: lexi.lambda at gmail.com (Alexis King) Date: Wed, 19 Aug 2020 12:12:54 -0500 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> References: <20200816121711.GE27294@cloudinit-builder> <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> Message-ID: Adding to my previous email, I’ve noticed that the behavior I’ve described appears to be inconsistent with the documentation. From the GHC 8.10.1 User’s Guide § 9.17.1, Lexically scoped type variables » Overview : > The design follows the following principles > A scoped type variable stands for a type variable, and not for a type. (This is a change from GHC’s earlier design.) > Furthermore, distinct lexical type variables stand for distinct type variables. This means that every programmer-written type signature (including one that contains free scoped type variables) denotes a rigid type; that is, the type is fully known to the type checker, and no inference is involved. > Lexical type variables may be alpha-renamed freely, without changing the program. Emphasis mine. This suggests that your program should not be accepted (and that GHC shouldn’t work the way I describe, even if that’s how it works in practice today), so either the current implementation is buggy, or the documentation is buggy. I am not sure which. I have opened GHC issue #18591 to track this inconsistency. Alexis -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.jakobi at googlemail.com Wed Aug 19 17:15:26 2020 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Wed, 19 Aug 2020 19:15:26 +0200 Subject: [Haskell-cafe] Dhall for Word8, Word16, Double, etc In-Reply-To: References: Message-ID: Hi Josh! dhall already provides FromDhall instances for Set and HashSet, which fail when the input Dhall list contains duplicates. Adding instances for e.g. Word8 that would fail when the source Natural is greater than 255 doesn't seem like a stretch. Please do open an issue at https://github.com/dhall-lang/dhall-haskell/issues so we can discuss the idea with the other maintainers. Cheers, Simon Am Mi., 19. Aug. 2020 um 08:56 Uhr schrieb ☂Josh Chia (謝任中) : > > Correction to my original message: No problems for Double, which already has a FromDhall instance, but I'm trying to solve the problem for Word8, Word16 & Word32. > > Interestingly, Word8, Word16 & Word32 have ToDhall instances but no FromDhall instances. > > On Wed, Aug 19, 2020 at 2:50 PM ☂Josh Chia (謝任中) wrote: >> >> Hi, >> >> Let's say I have a record type: >> data Foo = Foo { v :: Word16 } >> >> I want to have a FromDhall instance for Foo. I know this is easy to do if v is Integer instead of Word16. But v is Word16. Does Dhall enable the user to cleanly express how to input a Word16 with the requisite range checks, or is the user expected to only use Integer and do his own conversion and range checks within Haskell after inputting the Integer from Dhall? I have a record with Word32, Word16, Word8 & Double fields instead of Integer & Scientific. >> > _______________________________________________ > 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 lexi.lambda at gmail.com Wed Aug 19 17:41:13 2020 From: lexi.lambda at gmail.com (Alexis King) Date: Wed, 19 Aug 2020 12:41:13 -0500 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: References: <20200816121711.GE27294@cloudinit-builder> <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> Message-ID: <0A56F6F5-F7CA-4BE3-B060-69CDE56CB91D@gmail.com> …and now Krzysztof Gogolewski has already chimed in with an explanation: > The documentation is outdated (it was written in 2006). Scoped type variables can use arbitrary types since #15050 (closed), https://github.com/ghc-proposals/ghc-proposals/blob/scoped-type-variables-types/proposals/scoped-type-variables-types.rst . So the issue is a documentation bug, and my explanation is how GHC is intended to operate. The linked proposal includes a little additional context, including a short paper, Type variables in patterns (published at Haskell ’18). Mystery resolved—though the docs still need fixing. Alexis -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Wed Aug 19 19:53:32 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 19 Aug 2020 15:53:32 -0400 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: <0A56F6F5-F7CA-4BE3-B060-69CDE56CB91D@gmail.com> References: <20200816121711.GE27294@cloudinit-builder> <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> <0A56F6F5-F7CA-4BE3-B060-69CDE56CB91D@gmail.com> Message-ID: <20200819195332.GG86346@straasha.imrryr.org> On Wed, Aug 19, 2020 at 12:41:13PM -0500, Alexis King wrote: > …and now Krzysztof Gogolewski has already chimed in with an explanation: > > > The documentation is outdated (it was written in 2006). Scoped type > > variables can use arbitrary types since #15050 (closed), > > https://github.com/ghc-proposals/ghc-proposals/blob/scoped-type-variables-types/proposals/scoped-type-variables-types.rst > > . > > So the issue is a documentation bug, and my explanation is how GHC is > intended to operate. The linked proposal includes a little additional > context, including a short paper, Type variables in patterns > (published at Haskell ’18). > Mystery resolved—though the docs still need fixing. I added some follow up comments to the ticket you opened. I don't agree with the analysis. Best I can tell (with some confidence after also testing with GHC 8.0 which predates the above proposal), is that instead what's happening is: 1. The function has no explicit type signature, the below is just a term-level formula for its value: add (x :: a) (y :: a) = x + y 2. The type signature is inferred as usual: add :: Num c => c -> c -> c unifying the type `c` with the types of both of the terms `x` and `y`. 3. But the formula contains two Pattern Type Signatures, binding the lexical type variable `a` to the type of `x` and the lexical type variable `b` to the type of `y`. 4. However the types of `x` and `y` are both `c` (really some arbitrary fixed type variable, modulo alpha-renaming). 5. Therefore, `a` and `b` are both the same type, not by virtue of type inference between `a` and `b`, but by virtue of simple pattern matching to an ultimately common type. The only thing that changed after the proposal was broadening of the acceptable pattern matching to allow the pattern to match something other than a type *variable*: Before: f :: a -> Int f (x :: b) = 1 -- OK b ~ a f :: Int -> Int f (x :: b) = 1 -- Bad b ~ Int, not a type variable! After: f :: a -> Int f (x :: b) = 1 -- OK b ~ a f :: Int -> Int f (x :: b) = 1 -- OK b ~ Int However, Tom's example works both with GHC 8.0.x -- 8.6.x which fall into the *before* case, and with GHC 8.8 and up, which are in the *after* case. -- Viktor. From ietf-dane at dukhovni.org Wed Aug 19 20:13:53 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 19 Aug 2020 16:13:53 -0400 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: <20200816121711.GE27294@cloudinit-builder> References: <20200816121711.GE27294@cloudinit-builder> Message-ID: <20200819201353.GH86346@straasha.imrryr.org> On Sun, Aug 16, 2020 at 01:17:11PM +0100, Tom Ellis wrote: > -- Inferred signature: > -- add :: Num a => a -> a -> a > add (x :: a) (y :: b) = x + y > [...] > > But this leads to a rather puzzling user experience. Was it really > not possible to design this extension in a way that would allow > bringing new type variables into scope locally but not allow them to > unify with other type variables from outer scopes? Back to Tom's original question, the answer is "no" because in fact no unification of `a` and `b` is taking place. The type variables `a` and `b` in the above lexical Pattern Type Signatures are not "generalised": http://downloads.haskell.org/ghc/8.10.1/docs/html/users_guide/glasgow_exts.html#pattern-type-signatures Unlike expression and declaration type signatures, pattern type signatures are not implicitly generalised. So what the example definition of `add` says (beyond giving a formula for add x y) is that also the lexical type variables `a` and `b` satisfy: a ~ TypeOf(x) b ~ TypeOf(y) but since we've already inferred: TypeOf(x) ~ TypeOf(y), bringing `a` and `b` into scope does not change that in any way. -- Viktor. From lexi.lambda at gmail.com Wed Aug 19 21:58:00 2020 From: lexi.lambda at gmail.com (Alexis King) Date: Wed, 19 Aug 2020 16:58:00 -0500 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: <20200819195332.GG86346@straasha.imrryr.org> References: <20200816121711.GE27294@cloudinit-builder> <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> <0A56F6F5-F7CA-4BE3-B060-69CDE56CB91D@gmail.com> <20200819195332.GG86346@straasha.imrryr.org> Message-ID: <8D7A8866-A09E-423A-91B4-C88BB9554173@gmail.com> What you say may be true, but the behavior you describe is still inconsistent with the documentation. After all, the documentation states these things must all be simultaneously true: Scoped type variables stand for type variables, not arbitrary types. Distinct scoped type variables correspond to distinct type variables. The type variables are always rigid. Tom’s program can’t possibly obey all three of these things because that would imply that `x :: a` and `y :: b` where `a` and `b` are distinct skolems, so `add` could not possibly typecheck. But it does—so it sounds like older versions of GHC just diverged from the documentation in other, less significant ways. Alexis > On Aug 19, 2020, at 14:53, Viktor Dukhovni wrote: > > I added some follow up comments to the ticket you opened. I don't agree > with the analysis. Best I can tell (with some confidence after also > testing with GHC 8.0 which predates the above proposal), is that instead > what's happening is: > > 1. The function has no explicit type signature, the below is > just a term-level formula for its value: > > add (x :: a) (y :: a) = x + y > > 2. The type signature is inferred as usual: > > add :: Num c => c -> c -> c > > unifying the type `c` with the types of both of the terms `x` > and `y`. > > 3. But the formula contains two Pattern Type Signatures, binding > the lexical type variable `a` to the type of `x` and the lexical > type variable `b` to the type of `y`. > > 4. However the types of `x` and `y` are both `c` (really some > arbitrary fixed type variable, modulo alpha-renaming). > > 5. Therefore, `a` and `b` are both the same type, not by virtue > of type inference between `a` and `b`, but by virtue of simple > pattern matching to an ultimately common type. > > The only thing that changed after the proposal was broadening of the > acceptable pattern matching to allow the pattern to match something > other than a type *variable*: > > Before: > > f :: a -> Int > f (x :: b) = 1 -- OK b ~ a > > f :: Int -> Int > f (x :: b) = 1 -- Bad b ~ Int, not a type variable! > > After: > > f :: a -> Int > f (x :: b) = 1 -- OK b ~ a > f :: Int -> Int > f (x :: b) = 1 -- OK b ~ Int > > However, Tom's example works both with GHC 8.0.x -- 8.6.x which fall > into the *before* case, and with GHC 8.8 and up, which are in the > *after* case. > > -- > Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Wed Aug 19 23:22:56 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 19 Aug 2020 19:22:56 -0400 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: <8D7A8866-A09E-423A-91B4-C88BB9554173@gmail.com> References: <20200816121711.GE27294@cloudinit-builder> <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> <0A56F6F5-F7CA-4BE3-B060-69CDE56CB91D@gmail.com> <20200819195332.GG86346@straasha.imrryr.org> <8D7A8866-A09E-423A-91B4-C88BB9554173@gmail.com> Message-ID: <20200819232256.GI86346@straasha.imrryr.org> On Wed, Aug 19, 2020 at 04:58:00PM -0500, Alexis King wrote: > What you say may be true, but the behavior you describe is still > inconsistent with the documentation. After all, the documentation > states these things must all be simultaneously true: > > 1. Scoped type variables stand for type variables, not arbitrary types. > 2. Distinct scoped type variables correspond to distinct type variables. > 3. The type variables are always rigid. Though perhaps much too careful/complete a read of the documentation is needed to see support in the documentation for the conclusions I ultimately reached, I do believe that the text is on some level there (that is, the behaviour essentially matches the documentation when all of it is read with some care, to some extent "between the lines"), but it could/should be much more explicit. Specifically, though reading the high-level overview indeed leads to your summary above: The design follows the following principles * A scoped type variable stands for a type variable, and not for a type. (This is a change from GHC’s earlier design.) [ This is the part that's later relaxed in 15050 ] * Furthermore, distinct lexical type variables stand for distinct type variables. This means that every programmer-written type signature (including one that contains free scoped type variables) denotes a rigid type; that is, the type is fully known to the type checker, and no inference is involved. [ Item 2 + 3 ] * Lexical type variables may be alpha-renamed freely, without changing the program. [ More of 3. ] These are later refined in a way that reduces the universality of 2 and 3. First we have: A declaration type signature that has explicit quantification (using forall) brings into scope the explicitly-quantified type variables, in the definition of the named function. that shows that scoped type variables are typically introduced via an explicit "forall", and of course in this case, given "forall a b. ..." the "a" and "b" in question are distinct. But when we get to "9.17.4. Pattern type signatures": http://downloads.haskell.org/ghc/8.10.1/docs/html/users_guide/glasgow_exts.html#pattern-type-signatures In the case where all the type variables in the pattern type signature are already in scope (i.e. bound by the enclosing context), matters are simple: the signature simply constrains the type of the pattern in the obvious way. Unlike expression and declaration type signatures, pattern type signatures are not implicitly generalised. The pattern in a pattern binding may only mention type variables that are already in scope. ... However, in all patterns other than pattern bindings, a pattern type signature may mention a type variable that is not in scope; in this case, the signature brings that type variable into scope. we see that are they are rather different beasts, that deviate from the description in the overview. In particular, "2" no longer holds, because these are neither generalised, nor universally quantified. Instead, most of the time they are just references to allready bound lexical variables constraining the type of the term to be the type of some variable already in scope. These are different provided the earlier definitions are different (e.g. forall a b. ...). However, when a Pattern Type Signature brings a new variable into scope, it is simply a type alias for the type of the term, and by virtue of not being univsally quantified or generalised, ... is a mere alias of whatever type variable (after 15050, relaxed to also allow actual types) is associated with the term in question. Now admittedly, this involves some "reading between the lines" to infer that the crucial thing that (unavoidably) gives us "2" and "3" is introduction via universal quantification. And that the overview does not adequately carve out an exemption from that far more common case to the case where instead a Pattern Type Signature just pattern matches the existing type of a term and gives a name so we can reuse that name in other terms. And it is these pattern matched type aliases, that while not directly unified, might under various conditions refer to the same actual type even if bound to different lexical names, because their bindings at the point of introduction are not to new universally quantified types, but are to known (possibly inferred) types of the terms in the pattern. So my conclusion is that enough information is present in the documentation to understand the observed behaviour as consistent with the detailed case-by-case breakdown, even while not matching the general overview. > Tom’s program can’t possibly obey all three of these things because > that would imply that `x :: a` and `y :: b` where `a` and `b` are > distinct skolems, so `add` could not possibly typecheck. But it > does—so it sounds like older versions of GHC just diverged from the > documentation in other, less significant ways. Well, in fact the major deviations from the overview are there even even as far back as GHC 7.10. All that changed more recently (GHC 8.8) is a more minor shift to allow the "aliased" term type to be a concrete type, rather than just a type variable. I do agree that the documentation should be more clear, in particular the overview is NOT a good (correct) description of lexicals brought into scope via Pattern Type Signatures. -- Viktor. From nikhil at acm.org Thu Aug 20 13:36:26 2020 From: nikhil at acm.org (Rishiyur Nikhil) Date: Thu, 20 Aug 2020 09:36:26 -0400 Subject: [Haskell-cafe] ICFP tutorial on hardware design using BH (Bluespec Haskell) In-Reply-To: References: Message-ID: REMINDER: My tutorial "Designing Hardware Systems and Accelerators with Open-Source BH (Bluespec Haskell)" on Aug 23 at #ICFP2020 (online). Please pre-install tools; instructions in tutorial repo README: https://tinyurl.com/y29zxrow . ICFP web page: https://icfp20.sigplan.org . #RISCV #Bluespec #BSV #BH. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Thu Aug 20 17:38:15 2020 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu, 20 Aug 2020 13:38:15 -0400 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: <20200819232256.GI86346@straasha.imrryr.org> References: <20200816121711.GE27294@cloudinit-builder> <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> <0A56F6F5-F7CA-4BE3-B060-69CDE56CB91D@gmail.com> <20200819195332.GG86346@straasha.imrryr.org> <8D7A8866-A09E-423A-91B4-C88BB9554173@gmail.com> <20200819232256.GI86346@straasha.imrryr.org> Message-ID: <55e6ab45-96ef-4fa8-2d6f-073dc130e0db@vex.net> I wonder if the rule comes down to simply this? To every variable, or rather name or identifier (term level, type level, meta level, state variables, any subject matter that lets you create names), you always want to do two things: * Define it, or at least introduce it (e.g., quantifier, lambda). * Use it, and it refers to something you defined/introduced. Perhaps the rule is simply: When LHS has (pattern :: typevar), this defines typevar to be [an alias of] the type of the term that matches that pattern. (BTW, this also introduces term-level vars in the pattern.) When RHS has (termexpr :: typeexpr), type variables in typeexpr are references, use sites. (BTW, term-level vars in termexpr are also references, use sites.) I guess the latter is marred by the Haskell Report (or NoScopedTypeVariables) rule, e.g., (termexpr :: [t]) is like (termexpr :: forall t. [t]). Still, a reference is involved, it just refers to something else. Here is an example of my view. Given ScopedTypeVariables, f :: forall a. a -> [a] f ((x :: b) :: c) = [x :: a, x :: b, x :: c] I introduce 1 var and define 2 aliases, and go on to use all 3 in chorus. From thomas.dubuisson at gmail.com Thu Aug 20 17:41:24 2020 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Thu, 20 Aug 2020 10:41:24 -0700 Subject: [Haskell-cafe] doctest-extract In-Reply-To: References: <631F8B1B-100A-4B34-8033-87050CF62E74@gmail.com> Message-ID: Is there movement on doctest-extract? I'd really like doctest with my v2 cabal projects. On Mon, Aug 3, 2020 at 10:51 AM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Mon, 3 Aug 2020, Henning Thielemann wrote: > > > doctest just runs GHCi and GHCi follows the built-in rule: If an > expression > > is IO, then run IO and emit its stdio. > > I meant stdout, of course. Certainly also stderr. > _______________________________________________ > 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 lexi.lambda at gmail.com Fri Aug 21 23:13:23 2020 From: lexi.lambda at gmail.com (Alexis King) Date: Fri, 21 Aug 2020 18:13:23 -0500 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: <20200819232256.GI86346@straasha.imrryr.org> References: <20200816121711.GE27294@cloudinit-builder> <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> <0A56F6F5-F7CA-4BE3-B060-69CDE56CB91D@gmail.com> <20200819195332.GG86346@straasha.imrryr.org> <8D7A8866-A09E-423A-91B4-C88BB9554173@gmail.com> <20200819232256.GI86346@straasha.imrryr.org> Message-ID: <9A94EEB4-AF8D-45DD-8814-B5AA42537239@gmail.com> > On Aug 19, 2020, at 18:22, Viktor Dukhovni wrote: > > Though perhaps much too careful/complete a read of the documentation is > needed to see support in the documentation for the conclusions I > ultimately reached, I do believe that the text is on some level there I do not agree with your interpretation. :) > But when we get to "9.17.4. Pattern type signatures" […] we see that are they are rather different beasts, that deviate from the description in the overview. In particular, "2" no longer holds, because these are neither generalised, nor universally quantified. It is true that such variables are not generalized, but the documentation does not say “generalized”—it says rigid. If we consider that the primary purpose of this feature is to bring existentials into scope, then there is no violation of the principle when used in the intended way. After all, existentials brought into scope via `case` are very much rigid (and distinct from all other variables). It is true that GHC implements a much more flexible behavior that allows entirely different things to be brought into scope. But that is just part of the divergence from the documentation—there’s nothing that says pattern signatures are exempt from that restriction. It only states that pattern signatures that refer to unbound variables bring those variables into scope, nothing more. Of course, this is all somewhat immaterial—there is no way to objectively determine which interpretation is “correct,” and the docs are unambiguously unclear regardless, so they should be changed. But purely as a matter of friendly debate, I stand by my interpretation. Alexis -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sat Aug 22 00:29:23 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 21 Aug 2020 20:29:23 -0400 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: <9A94EEB4-AF8D-45DD-8814-B5AA42537239@gmail.com> References: <20200816121711.GE27294@cloudinit-builder> <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> <0A56F6F5-F7CA-4BE3-B060-69CDE56CB91D@gmail.com> <20200819195332.GG86346@straasha.imrryr.org> <8D7A8866-A09E-423A-91B4-C88BB9554173@gmail.com> <20200819232256.GI86346@straasha.imrryr.org> <9A94EEB4-AF8D-45DD-8814-B5AA42537239@gmail.com> Message-ID: <20200822002923.GH37427@straasha.imrryr.org> On Fri, Aug 21, 2020 at 06:13:23PM -0500, Alexis King wrote: > > On Aug 19, 2020, at 18:22, Viktor Dukhovni wrote: > > > > Though perhaps much too careful/complete a read of the documentation is > > needed to see support in the documentation for the conclusions I > > ultimately reached, I do believe that the text is on some level there > > I do not agree with your interpretation. :) Fair enough, the text is ultimately not clear. [ TL;DR the rest is inessential detail for the morbidly curious. ] > > But when we get to "9.17.4. Pattern type signatures" […] we see that > > are they are rather different beasts, that deviate from the > > description in the overview. In particular, "2" no longer holds, > > because these are neither generalised, nor universally quantified. > > It is true that such variables are not generalized, but the > documentation does not say “generalized”—it says rigid. If we consider > that the primary purpose of this feature is to bring existentials into > scope, then there is no violation of the principle when used in the > intended way. After all, existentials brought into scope via `case` > are very much rigid (and distinct from all other variables). The leap I was making is that it is specifically universal quantification that leaves the design no choice but to make the variables rigid. With "forall a b." naturally "a" and "b" vary *independently*, and so must be kept distinct. On the other hand, given that Pattern Type Signatures are not universally quantified, there is no longer a *prior requirement* to keep them distinct, and so I am ultimately not surprised that they may not be rigid in the same way as those brought into scope via "forall", indeed we can now (as of GHC 8.8) write: foo :: Int -> Int -> String foo (x :: a) (y :: b) = "(" ++ (show @a x) ++ ", " ++ (show @b y) ++ ")" λ> foo 1 2 "(1, 2)" where "a" becomes a synonym for "Int" and so does "b", and so are surely not distinct types. But even with GHC 8.0 (7.10 and perhaps older would also be OK were this example changed to avoid TypeApplications), we can write: foo :: Show c => c -> c -> String foo (x :: a) (y :: b) = "(" ++ (show @a x) ++ ", " ++ (show @b y) ++ ")" λ> foo 1 2 "(1, 2)" where "a" and "b" are aliases for "c". I don't think you disagree that this is what the actual implementation is doing. My point was just that with some effort one might read the actual behaviour as consistent with the spirit of the documentation, and that the leap required to read it that way may not be too great. > It is true that GHC implements a much more flexible behavior that > allows entirely different things to be brought into scope. But that is > just part of the divergence from the documentation—there’s nothing > that says pattern signatures are exempt from that restriction. It only > states that pattern signatures that refer to unbound variables bring > those variables into scope, nothing more. Yes, the literal text does not actually carve out an exception, I'm making a retroactive extrapolation from the inferred constraints on the implementation given the context. > Of course, this is all somewhat immaterial—there is no way to > objectively determine which interpretation is “correct,” and the docs > are unambiguously unclear regardless, so they should be changed. But > purely as a matter of friendly debate, I stand by my interpretation. Yes it would be nice for someone to craft a proposed change to the docs. Any volunteers? My attempt to read the docs liberally was largely in order to better understand the actual implementation and to intuit how and why the actual choice was made, and might be seen to be consistent with the overall design. -- Viktor. From lemming at henning-thielemann.de Sat Aug 22 10:40:43 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 22 Aug 2020 12:40:43 +0200 (CEST) Subject: [Haskell-cafe] doctest-extract In-Reply-To: References: <631F8B1B-100A-4B34-8033-87050CF62E74@gmail.com> Message-ID: On Thu, 20 Aug 2020, Thomas DuBuisson wrote: > Is there movement on doctest-extract?  I'd really like doctest with my v2 cabal projects. I have solved the problem with letting the testsuite fail when a single test fails. To this end I implemented a Writer Monad that counts the failures and put this in the new package doctest-exitcode-stdio: $ cabal install $(for pkg in doctest-extract-0.1 doctest-lib-0.1 doctest-exitcode-stdio-0.0 utility-ht-0.0.16 non-empty-0.3.3; do echo https://hackage.haskell.org/package/$pkg/candidate/$pkg.tar.gz; done) I could also write an extractor for Cabal's 'detailed' test framework. From rae at richarde.dev Mon Aug 24 02:22:55 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 24 Aug 2020 02:22:55 +0000 Subject: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour In-Reply-To: <20200822002923.GH37427@straasha.imrryr.org> References: <20200816121711.GE27294@cloudinit-builder> <1EECAE7D-3678-4CD6-83D0-5FC8F7CE9A55@gmail.com> <0A56F6F5-F7CA-4BE3-B060-69CDE56CB91D@gmail.com> <20200819195332.GG86346@straasha.imrryr.org> <8D7A8866-A09E-423A-91B4-C88BB9554173@gmail.com> <20200819232256.GI86346@straasha.imrryr.org> <9A94EEB4-AF8D-45DD-8814-B5AA42537239@gmail.com> <20200822002923.GH37427@straasha.imrryr.org> Message-ID: <010f01741e4692a0-03c01b68-5997-41e6-9754-9a773749535c-000000@us-east-2.amazonses.com> The intended semantics here is from the paper (https://richarde.dev/papers/2018/pat-tyvars/pat-tyvars.pdf). See the paragraph right before section 5.6, which describes the change from the outdated documentation (saying that each scoped type variable must refer to a distinct variable) to the current implementation (where a scoped type variable can stand for any type). The idea behind the change is that, when we write f x = not x, we intend for x to stand for any Bool. So, when we write f (x :: a) = not x, we should allow a to stand for any type -- in this case, it will stand for Bool. Going back to Tom's original post, suggesting a refinement: consider data Ex2 = forall a. Ex2 a a f (Ex2 (x :: b) (y :: c)) = False Is that accepted or rejected? I think Tom's rules would accept, because neither b nor c are bound to a variable from an outer scope. Yet this suggests that b and c are different. Or what about data Eql = forall a. (a ~ Int) => Eql a g :: Eql -> Int g (Eql (x :: b)) = x + x Hrm. Now it seems we can allow `b` to stand for `a`... but `a` is also the same as Int. So that's confusing. We could also have `a` equal a type variable from an outer scope, thus circumventing the check Tom wants to introduce. It all gets very murky. Simplest to allow variables in that position unify with any type, as GHC is today. Regardless, the documentation must be updated. Thanks for making the ticket. Richard > On Aug 21, 2020, at 8:29 PM, Viktor Dukhovni wrote: > > On Fri, Aug 21, 2020 at 06:13:23PM -0500, Alexis King wrote: > >>> On Aug 19, 2020, at 18:22, Viktor Dukhovni wrote: >>> >>> Though perhaps much too careful/complete a read of the documentation is >>> needed to see support in the documentation for the conclusions I >>> ultimately reached, I do believe that the text is on some level there >> >> I do not agree with your interpretation. :) > > Fair enough, the text is ultimately not clear. [ TL;DR the rest is > inessential detail for the morbidly curious. ] > >>> But when we get to "9.17.4. Pattern type signatures" […] we see that >>> are they are rather different beasts, that deviate from the >>> description in the overview. In particular, "2" no longer holds, >>> because these are neither generalised, nor universally quantified. >> >> It is true that such variables are not generalized, but the >> documentation does not say “generalized”—it says rigid. If we consider >> that the primary purpose of this feature is to bring existentials into >> scope, then there is no violation of the principle when used in the >> intended way. After all, existentials brought into scope via `case` >> are very much rigid (and distinct from all other variables). > > The leap I was making is that it is specifically universal > quantification that leaves the design no choice but to make the > variables rigid. With "forall a b." naturally "a" and "b" vary > *independently*, and so must be kept distinct. > > On the other hand, given that Pattern Type Signatures are not > universally quantified, there is no longer a *prior requirement* to keep > them distinct, and so I am ultimately not surprised that they may not be > rigid in the same way as those brought into scope via "forall", indeed > we can now (as of GHC 8.8) write: > > foo :: Int -> Int -> String > foo (x :: a) (y :: b) = "(" ++ (show @a x) ++ ", " ++ (show @b y) ++ ")" > > λ> foo 1 2 > "(1, 2)" > > where "a" becomes a synonym for "Int" and so does "b", and so are surely > not distinct types. But even with GHC 8.0 (7.10 and perhaps older would > also be OK were this example changed to avoid TypeApplications), we can > write: > > foo :: Show c => c -> c -> String > foo (x :: a) (y :: b) = "(" ++ (show @a x) ++ ", " ++ (show @b y) ++ ")" > > λ> foo 1 2 > "(1, 2)" > > where "a" and "b" are aliases for "c". I don't think you disagree that > this is what the actual implementation is doing. My point was just that > with some effort one might read the actual behaviour as consistent with > the spirit of the documentation, and that the leap required to read it > that way may not be too great. > >> It is true that GHC implements a much more flexible behavior that >> allows entirely different things to be brought into scope. But that is >> just part of the divergence from the documentation—there’s nothing >> that says pattern signatures are exempt from that restriction. It only >> states that pattern signatures that refer to unbound variables bring >> those variables into scope, nothing more. > > Yes, the literal text does not actually carve out an exception, I'm > making a retroactive extrapolation from the inferred constraints on > the implementation given the context. > >> Of course, this is all somewhat immaterial—there is no way to >> objectively determine which interpretation is “correct,” and the docs >> are unambiguously unclear regardless, so they should be changed. But >> purely as a matter of friendly debate, I stand by my interpretation. > > Yes it would be nice for someone to craft a proposed change to the docs. > Any volunteers? > > My attempt to read the docs liberally was largely in order to better > understand the actual implementation and to intuit how and why the > actual choice was made, and might be seen to be consistent with the > overall design. > > -- > 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. From leah at vuxu.org Wed Aug 26 08:14:24 2020 From: leah at vuxu.org (Leah Neukirchen) Date: Wed, 26 Aug 2020 10:14:24 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2020-08-27 @ 19:30 Message-ID: <87r1rtsu1r.fsf@vuxu.org> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, August 27 at Hirschgarten at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html Please add yourself here if you want to come so we know who to look out for: https://dudle.inf.tu-dresden.de/haskell-munich-aug-2020/ Unfortunately, I almost forgot about the meeting tomorrow, please excuse the short notice. I'm also at Hirschgarten for other reasons, so I may drop by only for a short time. Everybody is welcome! cu, -- Leah Neukirchen https://leahneukirchen.org/ From publicityifl at gmail.com Wed Aug 26 12:41:29 2020 From: publicityifl at gmail.com (Jurriaan Hage) Date: Wed, 26 Aug 2020 07:41:29 -0500 Subject: [Haskell-cafe] First and Only Call for Participation for IFL 2020 (Implementation and Application of Functional Languages) Message-ID: Hello, Please, find below the first and final call for participation for IFL 2020. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ======================================================= IFL 2020 32nd Symposium on Implementation and Application of Functional Languages Call for Participation venue: online 2nd - 4th September 2020 https://www.cs.kent.ac.uk/events/2020/ifl20/ ======================================================== ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2020 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. ### Registration The symposium will be run via Zoom (zoom.us). If you can use Zoom, then you can participate. Please register for free via Eventbrite on the symposium webpage: https://www.cs.kent.ac.uk/events/2020/ifl20/ ### Programme Day 1: Wednesday, 2 September 12:45 Welcome 13:00 Nico Naus and Johan Jeuring: End-user feedback in multi-user workflow systems 13:30 Mart Lubbers, Haye Böhm, Pieter Koopman and Rinus Plasmeijer: Asynchronous Shared Data Sources 14:00 Pieter Koopman, Steffen Michels and Rinus Plasmeijer: Dynamic Editors for Well-Typed Expressions 14:30 Bas Lijnse and Rinus Plasmeijer: Asymmetric Composable Web Editors in iTasks 15:00 Social break 15:30 Sven-Olof Nyström: A subtyping system for Erlang 16:00 Andrew Marmaduke, Christopher Jenkins and Aaron Stump: Generic Zero-Cost Constructor Subtyping 16:30 Joris Burgers, Jurriaan Hage and Alejandro Serrano: Heuristics-based Type Error Diagnosis for Haskell - The case of GADTs and local reasoning 17:00 Social break 17:30 Kavon Farvardin and John Reppy: A New Backend for Standard ML of New Jersey 18:00 Chaitanya Koparkar, Mike Rainey, Michael Vollmer, Milind Kulkarni and Ryan R. Newton: A Compiler Approach Reconciling Parallelism and Dense Representations for Irregular Trees 18:30 Hans-Nikolai Vießmann and Sven-Bodo Scholz: Effective Host-GPU Memory Mangement Through Code Generation 20:00 Virtual Pub Day 2: Thursday, 3 September 10:00 Virtual Breakfast 13:00 Michal Gajda: Less Arbitrary waiting time 13:30 Sólrún Halla Einarsdóttir and Nicholas Smallbone: Template-based Theory Exploration: Discovering Properties of Functional Programs by Testing 14:00 Péter Bereczky, Dániel Horpácsi, Judit Kőszegi, Soma Szeier and Simon Thompson: Validating Formal Semantics by Comparative Testing 14:30 Social break 15:00 Gergo Erdi: An Adventure in Symbolic Execution 15:30 Joshua M. Schappel, Sachin Mahashabde and Marco T. Morazan: Using OO Design Patterns in a Functional Programming Setting 16:00 Filipe Varjão: Functional Programming and Interval Arithmetic with High Accuracy 16:30 Social break 17:00 Laith Sakka, Chaitanya Koparkar, Michael Vollmer, Vidush Singhal, Sam Tobin-Hochstadt, Ryan R. Newton and Milind Kulkarni: General Deforestation Using Fusion, Tupling and Intensive Redundancy Analysis 17:30 Benjamin Mourad and Matteo Cimini: A Declarative Gradualizer with Lang-n-Change 18:00 Maheen Riaz Contractor and Matthew Fluet: Type- and Control-Flow Directed Defunctionalization 19:30 Virtual Pub Day 3: Friday, 4 September 10:00 Virtual Breakfast 13:00 Michal Gajda: Towards a more perfect union type 13:30 Folkert de Vries, Sjaak Smetsers and Sven-Bodo Scholz: Container Unification for Uniqueness Types 14:00 Alejandro Díaz-Caro, Pablo E. Martínez López and Cristian Sottile: Polymorphic System I 14:30 Social break 15:00 Michal Gajda: Schema-driven mutation of datatype with multiple representations 15:30 Alexandre Garcia de Oliveira, Mauro Jaskelioff and Ana Cristina Vieira de Melo: On Structuring Pure Functional Programs with Monoidal Profunctors 16:00 Sara Moreira, Pedro Vasconcelos and Mário Florido: Resource Analysis for Lazy Evaluation with Polynomial Potential 16:30 Social break 17:00 Neil Mitchell, Moritz Kiefer, Pepe Iborra, Luke Lau, Zubin Duggal, Hannes Siebenhandl, Matthew Pickering and Alan Zimmerman: Building an Integrated Development Environment (IDE) on top of a Build System 17:30 Evan Sitt, Xiaotian Su, Beka Grdzelishvili, Zurab Tsinadze, Zongpu Xie, Hossameldin Abdin, Giorgi Botkoveli, Nikola Cenikj, Tringa Sylaj and Viktoria Zsok: Functional Programming Application for Digital Synthesis Implementation 18:00 Jocelyn Serot: HoCL: High level specification of dataflow graphs 19:30 Virtual Pub All times are in British Summer Time (BST), the local time in Canterbury, UK. So please translate these into your own time zone, using a service such as time and date. -------------- next part -------------- An HTML attachment was scrubbed... URL: From S.J.Thompson at kent.ac.uk Wed Aug 26 13:39:38 2020 From: S.J.Thompson at kent.ac.uk (Simon Thompson) Date: Wed, 26 Aug 2020 13:39:38 +0000 Subject: [Haskell-cafe] Call for participation for IFL 2020: 32nd Symposium on Implementation and Application of Functional Languages Message-ID: <87BD5E1D-8432-44B5-AACD-FDE852F7FABF@kent.ac.uk> [apologies for any multiple copies] ======================================================= IFL 2020 32nd Symposium on Implementation and Application of Functional Languages Call for Participation venue: online 2nd - 4th September 2020 https://www.cs.kent.ac.uk/events/2020/ifl20/ ======================================================== ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2020 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. ### Registration The symposium will be run via Zoom (zoom.us). If you can use Zoom, then you can participate. Please register for free via Eventbrite on the symposium webpage: https://www.cs.kent.ac.uk/events/2020/ifl20/ ### Programme Day 1: Wednesday, 2 September 12:45 Welcome 13:00 Nico Naus and Johan Jeuring: End-user feedback in multi-user workflow systems 13:30 Mart Lubbers, Haye Böhm, Pieter Koopman and Rinus Plasmeijer: Asynchronous Shared Data Sources 14:00 Pieter Koopman, Steffen Michels and Rinus Plasmeijer: Dynamic Editors for Well-Typed Expressions 14:30 Bas Lijnse and Rinus Plasmeijer: Asymmetric Composable Web Editors in iTasks 15:00 Social break 15:30 Sven-Olof Nyström: A subtyping system for Erlang 16:00 Andrew Marmaduke, Christopher Jenkins and Aaron Stump: Generic Zero-Cost Constructor Subtyping 16:30 Joris Burgers, Jurriaan Hage and Alejandro Serrano: Heuristics-based Type Error Diagnosis for Haskell - The case of GADTs and local reasoning 17:00 Social break 17:30 Kavon Farvardin and John Reppy: A New Backend for Standard ML of New Jersey 18:00 Chaitanya Koparkar, Mike Rainey, Michael Vollmer, Milind Kulkarni and Ryan R. Newton: A Compiler Approach Reconciling Parallelism and Dense Representations for Irregular Trees 18:30 Hans-Nikolai Vießmann and Sven-Bodo Scholz: Effective Host-GPU Memory Mangement Through Code Generation 20:00 Virtual Pub Day 2: Thursday, 3 September 10:00 Virtual Breakfast 13:00 Michal Gajda: Less Arbitrary waiting time 13:30 Sólrún Halla Einarsdóttir and Nicholas Smallbone: Template-based Theory Exploration: Discovering Properties of Functional Programs by Testing 14:00 Péter Bereczky, Dániel Horpácsi, Judit Kőszegi, Soma Szeier and Simon Thompson: Validating Formal Semantics by Comparative Testing 14:30 Social break 15:00 Gergo Erdi: An Adventure in Symbolic Execution 15:30 Joshua M. Schappel, Sachin Mahashabde and Marco T. Morazan: Using OO Design Patterns in a Functional Programming Setting 16:00 Filipe Varjão: Functional Programming and Interval Arithmetic with High Accuracy 16:30 Social break 17:00 Laith Sakka, Chaitanya Koparkar, Michael Vollmer, Vidush Singhal, Sam Tobin-Hochstadt, Ryan R. Newton and Milind Kulkarni: General Deforestation Using Fusion, Tupling and Intensive Redundancy Analysis 17:30 Benjamin Mourad and Matteo Cimini: A Declarative Gradualizer with Lang-n-Change 18:00 Maheen Riaz Contractor and Matthew Fluet: Type- and Control-Flow Directed Defunctionalization 19:30 Virtual Pub Day 3: Friday, 4 September 10:00 Virtual Breakfast 13:00 Michal Gajda: Towards a more perfect union type 13:30 Folkert de Vries, Sjaak Smetsers and Sven-Bodo Scholz: Container Unification for Uniqueness Types 14:00 Alejandro Díaz-Caro, Pablo E. Martínez López and Cristian Sottile: Polymorphic System I 14:30 Social break 15:00 Michal Gajda: Schema-driven mutation of datatype with multiple representations 15:30 Alexandre Garcia de Oliveira, Mauro Jaskelioff and Ana Cristina Vieira de Melo: On Structuring Pure Functional Programs with Monoidal Profunctors 16:00 Sara Moreira, Pedro Vasconcelos and Mário Florido: Resource Analysis for Lazy Evaluation with Polynomial Potential 16:30 Social break 17:00 Neil Mitchell, Moritz Kiefer, Pepe Iborra, Luke Lau, Zubin Duggal, Hannes Siebenhandl, Matthew Pickering and Alan Zimmerman: Building an Integrated Development Environment (IDE) on top of a Build System 17:30 Evan Sitt, Xiaotian Su, Beka Grdzelishvili, Zurab Tsinadze, Zongpu Xie, Hossameldin Abdin, Giorgi Botkoveli, Nikola Cenikj, Tringa Sylaj and Viktoria Zsok: Functional Programming Application for Digital Synthesis Implementation 18:00 Jocelyn Serot: HoCL: High level specification of dataflow graphs 19:30 Virtual Pub All times are in British Summer Time (BST), the local time in Canterbury, UK. So please translate these into your own time zone, using a service such as time and date. Simon Thompson | Professor Emeritus of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Wed Aug 26 16:54:28 2020 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Wed, 26 Aug 2020 11:54:28 -0500 Subject: [Haskell-cafe] Munich Haskell Meeting, 2020-08-27 @ 19:30 In-Reply-To: <87r1rtsu1r.fsf@vuxu.org> References: <87r1rtsu1r.fsf@vuxu.org> Message-ID: Will this be online or in person? In English or in German? On Wed, Aug 26, 2020 at 3:15 AM Leah Neukirchen wrote: > Dear all, > > This week, our monthly Munich Haskell Meeting will take place again on > Thursday, August 27 at Hirschgarten at 19h30. For details see here: > > http://muenchen.haskell.bayern/dates.html > > Please add yourself here if you want to come so we know who to look > out for: > > https://dudle.inf.tu-dresden.de/haskell-munich-aug-2020/ > > Unfortunately, I almost forgot about the meeting tomorrow, please > excuse the short notice. I'm also at Hirschgarten for other reasons, > so I may drop by only for a short time. > > Everybody is welcome! > > cu, > -- > Leah Neukirchen https://leahneukirchen.org/ > _______________________________________________ > 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. -- Jeff Brown | Jeffrey Benjamin Brown Website | Facebook | LinkedIn (spammy, so I often miss messages here) | Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Wed Aug 26 20:24:11 2020 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 26 Aug 2020 22:24:11 +0200 Subject: [Haskell-cafe] writing wizards in Yesod Message-ID: Dear Café, TL;DR: What is the canonical way to deal with state in Yesod? IORef? StateT? Routes? Subsites? The Yesod book [1,2] gives examples where state is encoded in an IORef inside the foundational type, like so: data AppState = ... data App = App {appState :: IORef AppState} All handlers would then first read the AppState via getsYesod appState >>= (liftIO . readIORef) and branch on the result. I wonder if there are other ways to deal with state that changes through user interaction. After all, we have instance MonadHandler m => MonadHandler (StateT s m) in Yesod.Core. What is this useful for? From [1]: "By just providing you with a readable environment, you’re able to recreate a StateT transformer by relying on mutable references." also: "In order to run these [monad transformer actions], we can use the standard [...] unwrap functions [...] to run the action and get back a normal Handler." I interpret quote 1 as "StateT is to be emulated (via IORef), not used literally" and quote 2 as "real StateT can not be used directly, but must be unwrapped to be used in a handler". Context for my question: I found that Kleisli maps model wizards nicely as a sequence of fragments, e.g. Program User f :: () -> m a g :: a -> m b h :: b -> m c i :: c -> m d j :: d -> m () wizard :: m () wizard = (f >=> g >=> h >=> i >=> j) () The intermediate types a, c are questions and b, d are answers, and all types together form the program states. If the user side of the wizard is to be provided by websites, we need to model these states explicitly somehow. My current approach is to use the union type AppState = Start | Answer1 b | Answer2 d that tells the handler what step to serve next. Olaf [1] https://www.yesodweb.com/book/yesods-monads#yesods-monads_adding_a_new_monad_transformer [2] https://www.yesodweb.com/book/visitor-counter From lemming at henning-thielemann.de Wed Aug 26 22:01:00 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 27 Aug 2020 00:01:00 +0200 (CEST) Subject: [Haskell-cafe] writing wizards in Yesod In-Reply-To: References: Message-ID: On Wed, 26 Aug 2020, Olaf Klinke wrote: > The Yesod book [1,2] gives examples where state is encoded in an IORef > inside the foundational type, like so: > > data AppState = ... > data App = App {appState :: IORef AppState} IORef sounds mighty wrong, because a web server is highly concurrent. From godzbanebane at gmail.com Wed Aug 26 22:20:30 2020 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Thu, 27 Aug 2020 01:20:30 +0300 Subject: [Haskell-cafe] writing wizards in Yesod In-Reply-To: References: Message-ID: Hi! I believe the canonical way to handle this in Yesod is the "reader pattern" (https://www.fpcomplete.com/blog/2017/06/readert-design-pattern): * it's by the same author * yesod is a ReaderT and I'm not aware of a way to replace this monad with one of your own (e.g. some effects systems State monad, which you can then run as a MVar, so that you have concurrent writing/reading possible between the different threads spawned by yesod for handling each request) ====== Georgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Thu Aug 27 10:04:52 2020 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 27 Aug 2020 12:04:52 +0200 Subject: [Haskell-cafe] writing wizards in Yesod In-Reply-To: References: Message-ID: <4fe4995b9386a2a3995316f64b57796b4437a48a.camel@aatal-apotheke.de> On Thu, 2020-08-27 at 01:20 +0300, Georgi Lyubenov wrote: > Hi! > > I believe the canonical way to handle this in Yesod is the "reader > pattern" > (https://www.fpcomplete.com/blog/2017/06/readert-design-pattern): > * it's by the same author >From the top of that post: "If you must have some mutable state, put it in Env as a mutable reference (IORef, TVar, etc)." So the official guideline is exactly as I detailed in my original post. > * yesod is a ReaderT Yes, but it's MonadReader (HandlerData site site) (HandlerFor site) So I'd have to encode my state in one of HandlerData handlerRequest :: !YesodRequest handlerEnv :: !(RunHandlerEnv child site) handlerState :: !(IORef GHState) handlerResource :: !InternalState which has no fields for holding arbitrary data. And I centainly don't want to encode several Kilobytes of loaded data in the request URL. Olaf > and I'm not aware of a way to replace this monad with > one of your own (e.g. some effects systems State monad, which you can > then > run as a MVar, so that you have concurrent writing/reading possible > between > the different threads spawned by yesod for handling each request) > > ====== > Georgi From olf at aatal-apotheke.de Thu Aug 27 10:15:43 2020 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 27 Aug 2020 12:15:43 +0200 Subject: [Haskell-cafe] writing wizards in Yesod In-Reply-To: References: Message-ID: On Thu, 2020-08-27 at 00:01 +0200, Henning Thielemann wrote: > On Wed, 26 Aug 2020, Olaf Klinke wrote: > > > The Yesod book [1,2] gives examples where state is encoded in an > > IORef > > inside the foundational type, like so: > > > > data AppState = ... > > data App = App {appState :: IORef AppState} > > IORef sounds mighty wrong, because a web server is highly concurrent. I agree that this is a potential data leak and security risk. That is one of the reasons why I am seeking alternatives. I experimented, and it seems when the webserver forks to serve a new client, it does not copy the other client's current IORef state. Don't know how that works. In another webserver an IORef's content persisted from one session to the next, though. So the actual internal workings are a mystery to me. Can somebody shed light on this? Olaf From olf at aatal-apotheke.de Thu Aug 27 11:55:57 2020 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 27 Aug 2020 13:55:57 +0200 Subject: [Haskell-cafe] writing wizards in Yesod In-Reply-To: References: Message-ID: <34bd7d8adaafb1f9c648bf42707b9a4f95d556d8.camel@aatal-apotheke.de> On Thu, 2020-08-27 at 01:20 +0300, Georgi Lyubenov wrote: > Hi! > > I believe the canonical way to handle this in Yesod is the "reader > pattern" > (https://www.fpcomplete.com/blog/2017/06/readert-design-pattern): > * it's by the same author > I think the essence of the above blog post concerning state is the following. The overlapping instance hints at why this is not in Yesod in this generality. It is probably fine to declare such a MonadState instance for any concrete reader monad, though. Olaf {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} import Control.Monad.Reader import Control.Monad.State.Class import Data.IORef class Monad m => Ref m var where readRef :: var a -> m a writeRef :: var a -> a -> m () modifyRef :: var a -> (a -> a) -> m () modifyRef v f = readRef v >>= (writeRef v . f) instance Ref IO IORef where readRef = readIORef writeRef = writeIORef modifyRef = modifyIORef getRef :: Ref m var => ReaderT (var a) m a getRef = ReaderT readRef putRef :: Ref m var => a -> ReaderT (var a) m () putRef = ReaderT . flip writeRef instance {-# OVERLAPPING #-} Ref m var => MonadState a (ReaderT (var a) m) where get = getRef put = putRef From lemming at henning-thielemann.de Thu Aug 27 12:59:16 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 27 Aug 2020 14:59:16 +0200 (CEST) Subject: [Haskell-cafe] writing wizards in Yesod In-Reply-To: <34bd7d8adaafb1f9c648bf42707b9a4f95d556d8.camel@aatal-apotheke.de> References: <34bd7d8adaafb1f9c648bf42707b9a4f95d556d8.camel@aatal-apotheke.de> Message-ID: On Thu, 27 Aug 2020, Olaf Klinke wrote: > {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} > import Control.Monad.Reader > import Control.Monad.State.Class > import Data.IORef > > class Monad m => Ref m var where > readRef :: var a -> m a > writeRef :: var a -> a -> m () > modifyRef :: var a -> (a -> a) -> m () > modifyRef v f = readRef v >>= (writeRef v . f) > > instance Ref IO IORef where > readRef = readIORef > writeRef = writeIORef > modifyRef = modifyIORef > > getRef :: Ref m var => ReaderT (var a) m a > getRef = ReaderT readRef > > putRef :: Ref m var => a -> ReaderT (var a) m () > putRef = ReaderT . flip writeRef > > instance {-# OVERLAPPING #-} Ref m var => > MonadState a (ReaderT (var a) m) where > get = getRef > put = putRef I guess, with the "explicit dictionary" trick you do not need an (overlapping) instance at all: http://hackage.haskell.org/package/data-ref-0.0.2/docs/Data-Ref.html From sylvester.hazel at googlemail.com Thu Aug 27 20:57:40 2020 From: sylvester.hazel at googlemail.com (Sylvester Hazel) Date: Thu, 27 Aug 2020 22:57:40 +0200 Subject: [Haskell-cafe] augmenting GHC package database Message-ID: Hi Haskellers, Cabal couldn't resolve dependencies for a generated package so I used Stack that used 2 different GHC versions to build library from this package. Stack stored the library as libHSclient-something.a , HSclient-something.o and helper ".hi" files The dependent libraries Stack stored and registered at C:\sr..\lib\ How to add this information to GHC or Cabal database to be able to use this new library? This is on Chocolatey managed Windows platform;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Thu Aug 27 21:37:05 2020 From: vamchale at gmail.com (Vanessa McHale) Date: Thu, 27 Aug 2020 16:37:05 -0500 Subject: [Haskell-cafe] augmenting GHC package database In-Reply-To: References: Message-ID: Technically I think GHC doesn’t support .hi files built with different GHCs, unfortunately. I don’t think that cabal-install supports binary packages as far as I know :( > On Aug 27, 2020, at 3:57 PM, Sylvester Hazel via Haskell-Cafe wrote: > > Hi Haskellers, > Cabal couldn't resolve dependencies for a generated package so I used Stack that used 2 different GHC versions to build library from this package. Stack stored the library as libHSclient-something.a , HSclient-something.o and helper ".hi" files > > The dependent libraries Stack stored and registered at C:\sr..\lib\ > > How to add this information to GHC or Cabal database to be able to use this new library? This is on Chocolatey managed Windows platform;-) > > _______________________________________________ > 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 sylvester.hazel at googlemail.com Thu Aug 27 23:06:06 2020 From: sylvester.hazel at googlemail.com (Sylvester Hazel) Date: Fri, 28 Aug 2020 01:06:06 +0200 Subject: [Haskell-cafe] augmenting GHC package database In-Reply-To: References: Message-ID: The command 'stack ghci' configured older GHCi version 8.6.3 with all the needed packages. It is possible to reason about this library now. However, how to extend/modify this library and incorporate in my target (non-trivial) project is still beyond me. There must be some way of reverse engineering this binary library to .hs scripts, so I could add this modified to my project? On Thu, Aug 27, 2020 at 11:37 PM Vanessa McHale wrote: > Technically I think GHC doesn’t support .hi files built with different > GHCs, unfortunately. > > I don’t think that cabal-install supports binary packages as far as I know > :( > > On Aug 27, 2020, at 3:57 PM, Sylvester Hazel via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > > Hi Haskellers, > > Cabal couldn't resolve dependencies for a generated package so I used > Stack that used 2 different GHC versions to build library from this > package. Stack stored the library as libHSclient-something.a , > HSclient-something.o and helper ".hi" files > > The dependent libraries Stack stored and registered at C:\sr..\lib\ > > How to add this information to GHC or Cabal database to be able to use > this new library? This is on Chocolatey managed Windows platform;-) > _______________________________________________ > 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 lemming at henning-thielemann.de Thu Aug 27 23:14:32 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 28 Aug 2020 01:14:32 +0200 (CEST) Subject: [Haskell-cafe] augmenting GHC package database In-Reply-To: References: Message-ID: On Fri, 28 Aug 2020, Sylvester Hazel via Haskell-Cafe wrote: > The command 'stack ghci' configured older GHCi version 8.6.3 with all the needed packages. > It is possible to reason about this library now. > However, how to extend/modify this library and incorporate in my target (non-trivial) project is still beyond me. > There must be some way of reverse engineering this binary library to .hs scripts, so I could add this modified to > my project? There might be a set of versions of all libraries to build your project, but one library may have too restrictive version bounds. Cabal is more flexible than Stack in choosing sets of versions. You may use cabal's option --allow-newer=pkg1,pkg2,pkg3 and check whether Cabal can build your project anyway. From sylvester.hazel at googlemail.com Fri Aug 28 16:27:58 2020 From: sylvester.hazel at googlemail.com (Sylvester Hazel) Date: Fri, 28 Aug 2020 18:27:58 +0200 Subject: [Haskell-cafe] augmenting GHC package database In-Reply-To: References: Message-ID: Dear Henning, Your advice indeed forced Cabal to perform but it choked on 'mingw/bin/ld.exe' when building 'zlib'. So, I cannot comment whether that merry run is able to produce working library, just because of ignoring dependency constraints. Stack has built zlib in ghc-8.8.3 which for the above purpose is useless ...unless somebody will offer a solution to my main question: how to include old GHC Stack builds in current GHC work? Cabal: Building library for zlib-0.6.2.2.. [1 of 5] Compiling Codec.Compression.Zlib.Stream ( dist\build\Codec\Compression\Zlib\Stream.hs, dist\build\Codec\Compression\Zlib\Stream.o ) ghc.exe: could not execute: C:/GitLabRunner/builds/2WeHDSFP/0/ghc/ghc/inplace/mingw/bin/ld.exe cabal.exe: Failed to build zlib-0.6.2.2 Regards:-) On Fri, Aug 28, 2020 at 1:14 AM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Fri, 28 Aug 2020, Sylvester Hazel via Haskell-Cafe wrote: > > > The command 'stack ghci' configured older GHCi version 8.6.3 with all > the needed packages. > > It is possible to reason about this library now. > > However, how to extend/modify this library and incorporate in my target > (non-trivial) project is still beyond me. > > There must be some way of reverse engineering this binary library to .hs > scripts, so I could add this modified to > > my project? > > There might be a set of versions of all libraries to build your project, > but one library may have too restrictive version bounds. > > Cabal is more flexible than Stack in choosing sets of versions. You may > use cabal's option --allow-newer=pkg1,pkg2,pkg3 and check whether Cabal > can build your project anyway. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Fri Aug 28 17:47:28 2020 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 28 Aug 2020 19:47:28 +0200 Subject: [Haskell-cafe] augmenting GHC package database In-Reply-To: References: Message-ID: On 28/08/2020 01.06, Sylvester Hazel via Haskell-Cafe wrote: > The command 'stack ghci' configured older GHCi version 8.6.3 with all > the needed packages. > It is possible to reason about this library now. > However, how to extend/modify this library and incorporate in my target > (non-trivial) project is still beyond me. > There must be some way of reverse engineering this binary library to .hs > scripts, so I could add this modified to my project? > Is your project using Cabal or Stack or something else? Either way, I don't think you're going to have any luck trying to 'port' or register stack-built libraries with the system's GHC or with Cabal. Regards, From nadine.and.henry at pobox.com Mon Aug 31 14:12:31 2020 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Mon, 31 Aug 2020 07:12:31 -0700 Subject: [Haskell-cafe] RebindableSyntax Strangeness Message-ID: <24397.1359.107618.472491@gargle.gargle.HOWL> Hi Cafe, I have encountered the following puzzling behaviour from a very simple program: Consider -- {-# LANGUAGE RebindableSyntax #-} module A where import Data.Time running this with ghci gives: A> :i UTCTime type UTCTime :: * data UTCTime = UTCTime {utctDay :: Day, utctDayTime :: DiffTime} -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ instance [safe] Eq UTCTime -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ instance [safe] Ord UTCTime -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ instance [safe] Show UTCTime -- Defined in ‘time-1.9.3:Data.Time.LocalTime.Internal.ZonedTime’ instance [safe] FormatTime UTCTime -- Defined in ‘time-1.9.3:Data.Time.Format.Format.Instances’ instance [safe] Read UTCTime -- Defined in ‘time-1.9.3:Data.Time.Format.Parse’ instance [safe] ParseTime UTCTime -- Defined in ‘time-1.9.3:Data.Time.Format.Parse.Instances’ Now uncomment the first line (RebindableSyntax) and rerun it: A> :i UTCTime type UTCTime :: * data UTCTime = UTCTime {utctDay :: Day, utctDayTime :: DiffTime} -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ instance [safe] FormatTime UTCTime -- Defined in ‘time-1.9.3:Data.Time.Format.Format.Instances’ instance [safe] ParseTime UTCTime -- Defined in ‘time-1.9.3:Data.Time.Format.Parse.Instances’ And all of the nice instances for UTCTime have disappeared. Why? Best wishes, Henry Laxen From lysxia at gmail.com Mon Aug 31 14:23:44 2020 From: lysxia at gmail.com (Li-yao Xia) Date: Mon, 31 Aug 2020 10:23:44 -0400 Subject: [Haskell-cafe] RebindableSyntax Strangeness In-Reply-To: <24397.1359.107618.472491@gargle.gargle.HOWL> References: <24397.1359.107618.472491@gargle.gargle.HOWL> Message-ID: <545fbc8c-61e8-dc21-17f0-1e55df905cca@gmail.com> Hi Henry, RebindableSyntax implies NoImplicitPrelude, which puts Eq, Ord, Show, and Read out of scope. Cheers, Li-yao On 8/31/2020 10:12 AM, Henry Laxen wrote: > Hi Cafe, > > I have encountered the following puzzling behaviour from a very simple > program: > > Consider > > -- {-# LANGUAGE RebindableSyntax #-} > module A where > import Data.Time > > running this with ghci gives: > > A> :i UTCTime > type UTCTime :: * > data UTCTime = UTCTime {utctDay :: Day, utctDayTime :: DiffTime} > -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ > instance [safe] Eq UTCTime > -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ > instance [safe] Ord UTCTime > -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ > instance [safe] Show UTCTime > -- Defined in ‘time-1.9.3:Data.Time.LocalTime.Internal.ZonedTime’ > instance [safe] FormatTime UTCTime > -- Defined in ‘time-1.9.3:Data.Time.Format.Format.Instances’ > instance [safe] Read UTCTime > -- Defined in ‘time-1.9.3:Data.Time.Format.Parse’ > instance [safe] ParseTime UTCTime > -- Defined in ‘time-1.9.3:Data.Time.Format.Parse.Instances’ > > Now uncomment the first line (RebindableSyntax) and rerun it: > > A> :i UTCTime > type UTCTime :: * > data UTCTime = UTCTime {utctDay :: Day, utctDayTime :: DiffTime} > -- Defined in ‘time-1.9.3:Data.Time.Clock.Internal.UTCTime’ > instance [safe] FormatTime UTCTime > -- Defined in ‘time-1.9.3:Data.Time.Format.Format.Instances’ > instance [safe] ParseTime UTCTime > -- Defined in ‘time-1.9.3:Data.Time.Format.Parse.Instances’ > > And all of the nice instances for UTCTime have disappeared. Why? > > Best wishes, > Henry Laxen > _______________________________________________ > 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 rae at richarde.dev Mon Aug 31 19:50:20 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 31 Aug 2020 19:50:20 +0000 Subject: [Haskell-cafe] contribute to GHC by adding documentation Message-ID: <010f0174461204c6-fd983115-412d-4c1b-b048-23b970f054d6-000000@us-east-2.amazonses.com> Hi all, Occasionally I get emails asking how a newcomer can best contribute to GHC. I have some stock answers (find a feature in Haskell and implement it in Template Haskell; find an unimplemented proposal and implement it), but these sometimes don't work out. Wait no longer! If you'd like to contribute to GHC, there is a great chance in https://gitlab.haskell.org/ghc/ghc/-/issues/18633, which links to a file listing scores of undocumented compiler flags. Your task, if you choose to accept it: document these flags! Along the way, you will get to learn about various dark corners of GHC (and who doesn't love to lurk in dark corners?) and prod other GHC folks to produce answers to esoteric questions. Hours of fun to be had here! And along the way, you would do us all a wonderful service. Thanks, Richard