From simon at joyful.com Mon Oct 1 06:46:45 2018 From: simon at joyful.com (Simon Michael) Date: Sun, 30 Sep 2018 20:46:45 -1000 Subject: [Haskell-cafe] ANN: hledger-1.11 released Message-ID: <4409353E-75B6-46F3-9E5D-C8BA634FD554@joyful.com> Short announcement this quarter. Pleased to announce the release of hledger 1.11 on schedule! Thanks to release contributors Joseph Weston, Dmitry Astapov, Gaith Hallak, Jakub Zárybnický, Luca Molteni, and SpicyCat. stack users will need to get a copy of hledger source and do stack install from there, due to the recent GHC 8.6 release. cabal install hledger-1.11 should work normally. From http://hledger.org/release-notes.html#hledger-1.11 : hledger 1.11 The default display order of accounts is now influenced by the order of account directives. Accounts declared by account directives are displayed first (top-most), in declaration order, followed by undeclared accounts in alphabetical order. Numeric account codes are no longer used, and are ignored and considered deprecated. So if your accounts are displaying in a weird order after upgrading, and you want them alphabetical like before, just sort your account directives alphabetically. Account sorting (by name, by declaration, by amount) is now more robust and supported consistently by all commands (accounts, balance, bs..) in all modes (tree & flat, tabular & non-tabular). close: new –opening/–closing flags to print only the opening or closing transaction files: a new command to list included files prices: query arguments are now supported. Prices can be filtered by date, and postings providing transaction prices can also be filtered. rewrite: help clarifies relation to print –auto (#745) roi: a new command to compute return on investment, based on hledger-irr test: has more verbose output, more informative failure messages, and no longer tries to read the journal csv: We use a more robust CSV lib (cassava) and now support non-comma separators, eg –separator ‘;’ (experimental, this flag will probably become a CSV rule) (#829) csv: interpolated field names in values are now properly case insensitive, so this works: fields …,Transaction_Date,… date %Transaction_Date journal: D (default commodity) directives no longer break multiplier amounts in transaction modifiers (AKA automated postings) (#860) journal: “Automated Postings” have been renamed to “Transaction Modifiers”. journal: transaction comments in transaction modifier rules are now parsed correctly. (#745) journal: when include files form a cycle, we give an error instead of hanging. upper-case day/month names in period expressions no longer give an error (#847, #852) -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at joyful.com Mon Oct 1 22:35:40 2018 From: simon at joyful.com (Simon Michael) Date: Mon, 1 Oct 2018 12:35:40 -1000 Subject: [Haskell-cafe] ANN: hledger-1.11 released In-Reply-To: <4409353E-75B6-46F3-9E5D-C8BA634FD554@joyful.com> References: <4409353E-75B6-46F3-9E5D-C8BA634FD554@joyful.com> Message-ID: <081CF6AA-93AB-425B-8C63-43DA118BB311@joyful.com> Corrections: - http://hledger.org has been updated with the latest install methods. - hledger-install.sh now ensures a new-enough stack. - stack users don't need to fetch hledger source, but do need to specify an extra dep on the command line, eg like so: stack install --resolver=lts-12 cassava-megaparsec-1.0.0 hledger-lib-1.11 hledger-1.11 hledger-ui-1.11 hledger-web-1.11 hledger-api-1.11 > On Sep 30, 2018, at 8:46 PM, Simon Michael wrote: > > Short announcement this quarter. Pleased to announce the release of hledger 1.11 on schedule! > > Thanks to release contributors Joseph Weston, Dmitry Astapov, Gaith Hallak, Jakub Zárybnický, Luca Molteni, and SpicyCat. > > stack users will need to get a copy of hledger source and do stack install from there, due to the recent GHC 8.6 release. cabal install hledger-1.11 should work normally. > > From http://hledger.org/release-notes.html#hledger-1.11 : > hledger 1.11 > > The default display order of accounts is now influenced by the order of account directives. Accounts declared by account directives are displayed first (top-most), in declaration order, followed by undeclared accounts in alphabetical order. Numeric account codes are no longer used, and are ignored and considered deprecated. > > So if your accounts are displaying in a weird order after upgrading, and you want them alphabetical like before, just sort your account directives alphabetically. > > Account sorting (by name, by declaration, by amount) is now more robust and supported consistently by all commands (accounts, balance, bs..) in all modes (tree & flat, tabular & non-tabular). > > close: new –opening/–closing flags to print only the opening or closing transaction > > files: a new command to list included files > > prices: query arguments are now supported. Prices can be filtered by date, and postings providing transaction prices can also be filtered. > > rewrite: help clarifies relation to print –auto (#745) > > roi: a new command to compute return on investment, based on hledger-irr > > test: has more verbose output, more informative failure messages, and no longer tries to read the journal > > csv: We use a more robust CSV lib (cassava) and now support non-comma separators, eg –separator ‘;’ (experimental, this flag will probably become a CSV rule) (#829) > > csv: interpolated field names in values are now properly case insensitive, so this works: > > fields …,Transaction_Date,… date %Transaction_Date > > journal: D (default commodity) directives no longer break multiplier amounts in transaction modifiers (AKA automated postings) (#860) > > journal: “Automated Postings” have been renamed to “Transaction Modifiers”. > > journal: transaction comments in transaction modifier rules are now parsed correctly. (#745) > > journal: when include files form a cycle, we give an error instead of hanging. > > upper-case day/month names in period expressions no longer give an error (#847, #852) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasu at yasuaki.com Tue Oct 2 00:25:28 2018 From: yasu at yasuaki.com (Yasuaki Kudo) Date: Tue, 2 Oct 2018 09:25:28 +0900 Subject: [Haskell-cafe] Natural Deduction Message-ID: <3A37223D-A6B3-4323-AF4C-2EECDDB0478E@yasuaki.com> Hi, I have already sent similar questions to other forums but am still looking. Would you please advise where I can find a good explanation of Natural Deduction? I have been reading the link below so far. http://www.cs.cmu.edu/~fp/courses/atp/handouts/ch2-natded.pdf Cheers! Yasu -------------- next part -------------- An HTML attachment was scrubbed... URL: From manpacket at gmail.com Tue Oct 2 05:18:18 2018 From: manpacket at gmail.com (Mikhail Baykov) Date: Tue, 2 Oct 2018 13:18:18 +0800 Subject: [Haskell-cafe] Internship at Tsuru Message-ID: Hi Cafe Tsuru Capital is looking for interns. Haskell knowledge is required, experience with pricing futures/options would be nice but not necessary. Located in Tokyo, company language is English. Casual environment, nice monitors and a big coffee machine. Duration 3-4 months, starting at your convenience. We will help you with visa and looking for a place to stay. There's some salary. Details how to apply are on our website. https://www.reddit.com/r/haskell/comments/9knxtu/tsuru_is_looking_for_more_interns/ Feel free to ask questions here, in email or #tsurucapital on freenode. From marc at lamarciana.com Tue Oct 2 15:14:32 2018 From: marc at lamarciana.com (=?UTF-8?B?TWFyYyBCdXNxdcOp?=) Date: Tue, 2 Oct 2018 17:14:32 +0200 Subject: [Haskell-cafe] [JOB] Haskell job opportunity at RELEX Solutions in Helsinki, Finland In-Reply-To: <20180924130913.v73itjuqzhb7aay2@peitto> References: <20180924130913.v73itjuqzhb7aay2@peitto> Message-ID: Hi! Sorry for the late response, just wanted to know whether, accepting the risk that someone else takes my place, I could send the homework on the 15th of October at most. Quite busy right now with a deadline... About Helsinki, no problem to go there for some weeks. In fact, I'd love that :) Thanks! Marc Busqué http://waiting-for-dev.github.io/about/ El lun., 24 sept. 2018 a las 15:09, Mats Rauhala () escribió: > Would you like to get paid for writing Haskell? And do you live in > Europe, preferably in Helsinki, Finland? If yes, please read on. > > RELEX Solutions is Europe's fastest growing provider of integrated > retail and supply chain planning solutions. We are looking for a few > Haskell developers to join our small, but impactful group of Haskellers > to develop our internal tools. > > In this position you will be exposed to various technologies, such as > Haskell, Servant, Elm, GHCJS, Terraform, Ansible, Nix, RHEL/CentOS, AWS > etc. Your own interests are influential in what your daily work will > consist of. Your main responsiblities will be some mix of development, > operations and support of and around our coordination system. > > Interested in applying? Follow the link: > > https://relex.recruiterbox.com/jobs/fk01gjr/ > > Full remote for this position is negotiable, but you should be able to > be present at the Helsinki office at least for a couple of weeks, > preferably longer. Details of your contract are largely negotiable. > > Please note that the available position will be filled as soon as > suitable candidates are found, so don't wait too long ;). > > I'm also available for questions: > > - 'masser' at functionalprogramming slack > - 'MasseR' at freenode > - 'mats.rauhala at gmail.com' email or on this mailing list. > > > -- > Mats Rauhala > _______________________________________________ > 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. -- Marc Busqué http://waiting-for-dev.github.io/about/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Thu Oct 4 15:48:21 2018 From: johannes.waldmann at htwk-leipzig.de (waldmann) Date: Thu, 4 Oct 2018 17:48:21 +0200 Subject: [Haskell-cafe] Which pretty print library? Message-ID: <257b4626-83e7-0b8c-a881-780f8c75ea6a@htwk-leipzig.de> Dear Cafe, what is today's answer to this old question: https://stackoverflow.com/questions/9761507/which-pretty-print-library In particular, I agree with author's: "The thing that worries me about these [many pretty-printing libraries] is that many of them have many releases. This implies they've had features added, bugs fixed, etc. But have they all had the same bugs fixed?" Meanwhile, there's https://hackage.haskell.org/package/prettyprinter "This package solves all these issues, and then some." (clearly an instance of https://xkcd.com/927/ ) GHC is using pretty-1.1.3.6 ? - J.W. From vanessa.mchale at iohk.io Thu Oct 4 16:30:02 2018 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Thu, 4 Oct 2018 11:30:02 -0500 Subject: [Haskell-cafe] Which pretty print library? In-Reply-To: <257b4626-83e7-0b8c-a881-780f8c75ea6a@htwk-leipzig.de> References: <257b4626-83e7-0b8c-a881-780f8c75ea6a@htwk-leipzig.de> Message-ID: <96e3c915-ee05-994d-f478-5d6a483e85f9@iohk.io> I've used prettyprinter and I've been reasonably happy with it. I'd recommend *not* using ansi-wl-pprint but I don't have much experience with anything beyond those two since I've not had any reason to move on from prettyprinter :) On 10/04/2018 10:48 AM, waldmann wrote: > Dear Cafe, > > what is today's answer to this old question: > https://stackoverflow.com/questions/9761507/which-pretty-print-library > > In particular, I agree with author's: > "The thing that worries me about these [many pretty-printing libraries] > is that many of them have many releases. This implies they've had > features added, bugs fixed, etc. But have they all had the same > bugs fixed?" > > Meanwhile, there's https://hackage.haskell.org/package/prettyprinter > "This package solves all these issues, and then some." > (clearly an instance of https://xkcd.com/927/ ) > > GHC is using pretty-1.1.3.6 ? > > - J.W. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ollie at ocharles.org.uk Thu Oct 4 16:42:41 2018 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 4 Oct 2018 17:42:41 +0100 Subject: [Haskell-cafe] Which pretty print library? In-Reply-To: <96e3c915-ee05-994d-f478-5d6a483e85f9@iohk.io> References: <257b4626-83e7-0b8c-a881-780f8c75ea6a@htwk-leipzig.de> <96e3c915-ee05-994d-f478-5d6a483e85f9@iohk.io> Message-ID: Another happy prettyprinter user here. On Thu, Oct 4, 2018 at 5:30 PM Vanessa McHale wrote: > > I've used prettyprinter and I've been reasonably happy with it. I'd > recommend *not* using ansi-wl-pprint but I don't have much experience > with anything beyond those two since I've not had any reason to move on > from prettyprinter :) > > On 10/04/2018 10:48 AM, waldmann wrote: > > Dear Cafe, > > > > what is today's answer to this old question: > > https://stackoverflow.com/questions/9761507/which-pretty-print-library > > > > In particular, I agree with author's: > > "The thing that worries me about these [many pretty-printing libraries] > > is that many of them have many releases. This implies they've had > > features added, bugs fixed, etc. But have they all had the same > > bugs fixed?" > > > > Meanwhile, there's https://hackage.haskell.org/package/prettyprinter > > "This package solves all these issues, and then some." > > (clearly an instance of https://xkcd.com/927/ ) > > > > GHC is using pretty-1.1.3.6 ? > > > > - J.W. > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > 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 yotam2206 at gmail.com Fri Oct 5 04:36:45 2018 From: yotam2206 at gmail.com (Yotam Ohad) Date: Fri, 5 Oct 2018 07:36:45 +0300 Subject: [Haskell-cafe] Well typed OS Message-ID: Hi, In the last couple of days, I've been toying with the thought of an operating system in which programs (or more accurately, any process) has a distinct type which limits its use of the machine. For example, `echo` (String -> String) won't be able to print an output without a second program which would handle changing stdout. I think it could "break down" the IO monad into other structures that are better at specifying what is changing: A file is read / memory written / etc. I do, however, not sure how to incorporate drivers (which handles IO and external devices) into this. Giving them an `IO a` type feels like cheating. I would be much cooler if there was a way to treat them like the `echo` function from earlier. What are your thoughts/suggestions? I'll be happy to hear them. Yotam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Fri Oct 5 05:40:45 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 5 Oct 2018 07:40:45 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: Am 05.10.2018 um 06:36 schrieb Yotam Ohad: > Hi, > In the last couple of days, I've been toying with the thought of an > operating system in which programs (or more accurately, any process) has > a distinct type which limits > its use of the machine. For example, `echo` (String -> String) won't be > able to print an output without a second program which would handle > changing stdout. > > I think it could "break down" the IO monad into other structures that > are better at specifying what is changing: A file is read / memory > written / etc. > I do, however, not sure how to incorporate drivers (which handles IO and > external devices) into this. Giving them an `IO a` type feels like > cheating. I would be much cooler if there was a way > to treat them like the `echo` function from earlier. > > What are your thoughts/suggestions? I'll be happy to hear them. An OS needs to work for any programming language, so I'm not sure how to get from an IO-based approach to a working OS. Unless you plan to write the OS itself in Haskell and make it so that all programs are Haskell modules, but that's a huge task. The design approach you're after is called "Capabilities". It's not ordinarily described as a type system, and I'm not sure whether it's a good idea to use static types in the first place because there are situations where you want to grant or revoke them dynamically. See https://en.wikipedia.org/wiki/Capability-based_security . This article also has a link to other security models; capabilities are pretty famous, but it's quite possible that a different one would be a better fit. HTH Jo From ivanperezdominguez at gmail.com Fri Oct 5 10:49:42 2018 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 5 Oct 2018 06:49:42 -0400 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: On Fri, 5 Oct 2018 at 01:41, Joachim Durchholz wrote: > Am 05.10.2018 um 06:36 schrieb Yotam Ohad: > > Hi, > > In the last couple of days, I've been toying with the thought of an > > operating system in which programs (or more accurately, any process) has > > a distinct type which limits > > its use of the machine. For example, `echo` (String -> String) won't be > > able to print an output without a second program which would handle > > changing stdout. > > > > I think it could "break down" the IO monad into other structures that > > are better at specifying what is changing: A file is read / memory > > written / etc. > > I do, however, not sure how to incorporate drivers (which handles IO and > > external devices) into this. Giving them an `IO a` type feels like > > cheating. I would be much cooler if there was a way > > to treat them like the `echo` function from earlier. > > > > What are your thoughts/suggestions? I'll be happy to hear them. > > An OS needs to work for any programming language, so I'm not sure how to > get from an IO-based approach to a working OS. Unless you plan to write > the OS itself in Haskell and make it so that all programs are Haskell > modules, but that's a huge task. > He seems to suggest that he is playing around with the idea, more than proposing to write a whole OS. For the sake of the exercise, it makes sense to assume that all programs will carry a type specification. > > The design approach you're after is called "Capabilities". It's not > ordinarily described as a type system, and I'm not sure whether it's a > good idea to use static types in the first place because there are > situations where you want to grant or revoke them dynamically. > In part, isn't specifying this up-front what iOS and Android do with permissions, or docker with capabilities? As an exercise, I think this could be nice. And my intuition would be to use specific effects/monads as well, both to provide the capabilities themselves and to encode the idea that that permission or effect is needed. Type inference might be able to tell you whether a permission may be needed at all or not, so this seems like a potentially good idea. The idea of using a less-than-IO monad to limit possible IO effects is not uncommon. We briefly used it in [1, Section 7.3 - Limiting the Impact of IO] and I seem to recall Thorsten Altenkirsch talking about this (I don't remember if there's a paper and could not find one right now). There's two parts to this problem: can I write Haskell programs with limited-IO type specifications, and I think the answer is yes, and can I ensure that programs will not use resources not declared in their type, and I think the answer depends on kernel and, possibly, hardware support (even if you restrict this to Haskell). Because the type is not included in the program, it would not be included with the executable. It would be interesting to output that too in some form during compilation. This would seem also useful for DSLs. Best wishes, Ivan [1] https://dl.acm.org/citation.cfm?id=2976010 -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at gmail.com Fri Oct 5 11:47:59 2018 From: monkleyon at gmail.com (MarLinn) Date: Fri, 5 Oct 2018 13:47:59 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: <19beff08-c97e-bce6-5662-b7446383efdd@gmail.com> Hi Yotam, one rather small and abstract comment: Permissions and capabilities feel like they are something contravariant. Intuitively it should be easy to "get out" of permissions but hard to "get into" them. (compare 'pure' and 'extract') Resulting actions are probably covariant just like the more general IO. Therefore I conclude that programs in your OS will probably be a profunctor, an arrow, or something similar. I wouldn't even be surprised if one could build an OS on nothing but Optics into the RealWorld. Cheers, MarLinn From vanessa.mchale at iohk.io Fri Oct 5 16:08:12 2018 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Fri, 5 Oct 2018 11:08:12 -0500 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: You'd probably want an ABI for types, no? You'd need a new executable format (among many other things!). The question is: would it be worth it? Types are wonderful in Haskell because they allow us to structure our programs. What would structuring processes via types accomplish? It would improve the situation with shell scripting/pipes as you allude, but that's still an immense amount of effort. As for effect types - the IO monad in Haskell exists primarily to allow side effects in a lazy language, so there's no reason I see to keep it in an operating system. On 10/05/2018 12:40 AM, Joachim Durchholz wrote: > Am 05.10.2018 um 06:36 schrieb Yotam Ohad: >> Hi, >> In the last couple of days, I've been toying with the thought of an >> operating system in which programs (or more accurately, any process) >> has a distinct type which limits >> its use of the machine. For example, `echo` (String -> String) won't >> be able to print an output without a second program which would >> handle changing stdout. >> >> I think it could "break down" the IO monad into other structures that >> are better at specifying what is changing: A file is read / memory >> written / etc. >> I do, however, not sure how to incorporate drivers (which handles IO >> and external devices) into this. Giving them an `IO a` type feels >> like cheating. I would be much cooler if there was a way >> to treat them like the `echo` function from earlier. >> >> What are your thoughts/suggestions? I'll be happy to hear them. > > An OS needs to work for any programming language, so I'm not sure how > to get from an IO-based approach to a working OS. Unless you plan to > write the OS itself in Haskell and make it so that all programs are > Haskell modules, but that's a huge task. > > The design approach you're after is called "Capabilities". It's not > ordinarily described as a type system, and I'm not sure whether it's a > good idea to use static types in the first place because there are > situations where you want to grant or revoke them dynamically. > See https://en.wikipedia.org/wiki/Capability-based_security . This > article also has a link to other security models; capabilities are > pretty famous, but it's quite possible that a different one would be a > better fit. > > HTH > Jo > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From johnz at pleasantnightmare.com Fri Oct 5 17:18:29 2018 From: johnz at pleasantnightmare.com (John Z.) Date: Fri, 5 Oct 2018 13:18:29 -0400 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: <20181005171829.GA26418@johns-machine.localdomain> > Hi, > ... > its use of the machine. For example, `echo` (String -> String) won't be > able to print an output without a second program which would handle > changing stdout. For this specific example, it might be enough to just use something like Turtle from Gabriel Gonzales: http://hackage.haskell.org/package/turtle which -to me- signals that problem doesn't necessarily have to stretch so far as to implement a whole OS. Maybe just fixing smaller pieces here and there would provide much higher bang for the buck. -- "That gum you like is going to come back in style." From jo at durchholz.org Fri Oct 5 18:34:56 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 5 Oct 2018 20:34:56 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: <90b2a425-5508-ea33-fcc6-d55b558f620e@durchholz.org> Am 05.10.2018 um 12:49 schrieb Ivan Perez: > > The design approach you're after is called "Capabilities". It's not > ordinarily described as a type system, and I'm not sure whether it's a > good idea to use static types in the first place because there are > situations where you want to grant or revoke them dynamically. > > In part, isn't specifying this up-front what iOS and Android do with > permissions, or docker with capabilities? Even these grant and revoke permissions based on user actions. What you can describe statically is right relationships - IF the user has given permission such-and-so, THEN this-and-that activity is allowed. Maybe that's the way to go. If not: Any alternative should have spent at least some thought about how to deal with rights being granted and revoked. From monkleyon at gmail.com Fri Oct 5 19:46:25 2018 From: monkleyon at gmail.com (MarLinn) Date: Fri, 5 Oct 2018 21:46:25 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: <97723fad-51d4-4fde-182e-987512f1c4d7@gmail.com> > You'd probably want an ABI for types, no? You'd need a new executable > format (among many other things!). > > The question is: would it be worth it? Types are wonderful in Haskell > because they allow us to structure our programs. What would structuring > processes via types accomplish? It would improve the situation with > shell scripting/pipes as you allude, but that's still an immense amount > of effort. Now that I think about it… having something like an ABI or a "Haskell binary format" with types in it might indeed be useful in more cases than this one. It seems when a Haskell projects gets a bit larger people tend to search for ways to make it more modular. They try plugin frameworks, OS-level dynamic linking, on-the-fly compilation etc. But I repeatedly get the feeling that all these current approaches aren't actually very good. But what if we had some kind of specialized format for compiled, dynamically loadable, typed Haskell libraries? Something between a plain OS library and bytecode. This might help make programs more modular while keeping them type safe. One thing that might be useful to add next would be some kind of centralized registry of types, so that a plugin/library could extend the ways the system could be extended. And going along this line of thought even further leads to… uhm… oh.    OH. Ok, so, it's the month of Halloween, right? Because… OSGi, but in Haskell. Well, maybe there's some sane point in between? Cheers, MarLinn From allbery.b at gmail.com Fri Oct 5 21:04:38 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 5 Oct 2018 17:04:38 -0400 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <97723fad-51d4-4fde-182e-987512f1c4d7@gmail.com> References: <97723fad-51d4-4fde-182e-987512f1c4d7@gmail.com> Message-ID: I was thinking typed LLVM. On Fri, Oct 5, 2018 at 3:46 PM MarLinn wrote: > > > You'd probably want an ABI for types, no? You'd need a new executable > > format (among many other things!). > > > > The question is: would it be worth it? Types are wonderful in Haskell > > because they allow us to structure our programs. What would structuring > > processes via types accomplish? It would improve the situation with > > shell scripting/pipes as you allude, but that's still an immense amount > > of effort. > > Now that I think about it… having something like an ABI or a "Haskell > binary format" with types in it might indeed be useful in more cases > than this one. > > It seems when a Haskell projects gets a bit larger people tend to search > for ways to make it more modular. They try plugin frameworks, OS-level > dynamic linking, on-the-fly compilation etc. But I repeatedly get the > feeling that all these current approaches aren't actually very good. But > what if we had some kind of specialized format for compiled, dynamically > loadable, typed Haskell libraries? Something between a plain OS library > and bytecode. This might help make programs more modular while keeping > them type safe. > > One thing that might be useful to add next would be some kind of > centralized registry of types, so that a plugin/library could extend the > ways the system could be extended. > > And going along this line of thought even further leads to… uhm… oh. OH. > > Ok, so, it's the month of Halloween, right? > > Because… OSGi, but in Haskell. > > Well, maybe there's some sane point in between? > > Cheers, > MarLinn > > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Fri Oct 5 21:09:13 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 5 Oct 2018 23:09:13 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <97723fad-51d4-4fde-182e-987512f1c4d7@gmail.com> References: <97723fad-51d4-4fde-182e-987512f1c4d7@gmail.com> Message-ID: <18e48ac9-c2ba-7117-8c05-a5ec459637b5@durchholz.org> Am 05.10.2018 um 21:46 schrieb MarLinn: > > It seems when a Haskell projects gets a bit larger people tend to search > for ways to make it more modular. They try plugin frameworks, OS-level > dynamic linking, on-the-fly compilation etc. But I repeatedly get the > feeling that all these current approaches aren't actually very good. But > what if we had some kind of specialized format for compiled, dynamically > loadable, typed Haskell libraries? Something between a plain OS library > and bytecode. This might help make programs more modular while keeping > them type safe. I've been believing that having a strict, universally-understood binary format was the one thing that enabled Java's library ecosystem. Which is huge, with a constant evolution of new generations and survival of the fittest. The downside is that compatibility with an established binary format is a pretty restricting design constraint on language evolution - you cannot evolve the language in ways that require a change to the binary format, unless you are willing to give up compatibility with all the precompiled binaries that are around. I think it's doable, if the binary format has been carefully designed to allow the kind of extensions that are being tought about. The other prerequisite is that if a change to the binary format is unavoidable, old formats stay readable. I.e. the loader needs to be able to read old format, indefinitely. Alternatively, code repositories could convert the code at upload time - the compatibility code would then live in the repositories and not in the loader (which makes the code harder to write but keeps the runtime smaller). Well, that's what I can say from the Java and repository perspective. I'm pretty sure there are other, and more important perspectives :-) Regards, JO From vanessa.mchale at iohk.io Sat Oct 6 02:09:15 2018 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Fri, 5 Oct 2018 21:09:15 -0500 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <97723fad-51d4-4fde-182e-987512f1c4d7@gmail.com> References: <97723fad-51d4-4fde-182e-987512f1c4d7@gmail.com> Message-ID: <01d99e7a-8b83-886a-7341-cf232899431f@iohk.io> Another thing that would be different in the OS case would likely be that one could not have programs/processes of type a -> a ...which would make any types stored in an ABI a good deal less flexible than those in Haskell. On 10/05/2018 02:46 PM, MarLinn wrote: > >> You'd probably want an ABI for types, no? You'd need a new executable >> format (among many other things!). >> >> The question is: would it be worth it? Types are wonderful in Haskell >> because they allow us to structure our programs. What would structuring >> processes via types accomplish? It would improve the situation with >> shell scripting/pipes as you allude, but that's still an immense amount >> of effort. > > Now that I think about it… having something like an ABI or a "Haskell > binary format" with types in it might indeed be useful in more cases > than this one. > > It seems when a Haskell projects gets a bit larger people tend to > search for ways to make it more modular. They try plugin frameworks, > OS-level dynamic linking, on-the-fly compilation etc. But I repeatedly > get the feeling that all these current approaches aren't actually very > good. But what if we had some kind of specialized format for compiled, > dynamically loadable, typed Haskell libraries? Something between a > plain OS library and bytecode. This might help make programs more > modular while keeping them type safe. > > One thing that might be useful to add next would be some kind of > centralized registry of types, so that a plugin/library could extend > the ways the system could be extended. > > And going along this line of thought even further leads to… uhm… > oh.    OH. > > Ok, so, it's the month of Halloween, right? > > Because… OSGi, but in Haskell. > > Well, maybe there's some sane point in between? > > Cheers, > MarLinn > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ivanperezdominguez at gmail.com Sat Oct 6 02:24:12 2018 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 5 Oct 2018 22:24:12 -0400 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <01d99e7a-8b83-886a-7341-cf232899431f@iohk.io> References: <97723fad-51d4-4fde-182e-987512f1c4d7@gmail.com> <01d99e7a-8b83-886a-7341-cf232899431f@iohk.io> Message-ID: I sort of see why you might now, but I'm not sure it's what you mean? Could you elaborate? I think you can if you base this in some sort of indexed monad and have a way to join indices. Your process then become a -> (ioM e) a, where e is the neutral element or index for the index join operation. Perhaps indices could denote sets of permissions or capabilities. Ivan On Fri, 5 Oct 2018 at 22:09, Vanessa McHale wrote: > Another thing that would be different in the OS case would likely be > that one could not have programs/processes of type > > a -> a > > ...which would make any types stored in an ABI a good deal less flexible > than those in Haskell. > > > On 10/05/2018 02:46 PM, MarLinn wrote: > > > >> You'd probably want an ABI for types, no? You'd need a new executable > >> format (among many other things!). > >> > >> The question is: would it be worth it? Types are wonderful in Haskell > >> because they allow us to structure our programs. What would structuring > >> processes via types accomplish? It would improve the situation with > >> shell scripting/pipes as you allude, but that's still an immense amount > >> of effort. > > > > Now that I think about it… having something like an ABI or a "Haskell > > binary format" with types in it might indeed be useful in more cases > > than this one. > > > > It seems when a Haskell projects gets a bit larger people tend to > > search for ways to make it more modular. They try plugin frameworks, > > OS-level dynamic linking, on-the-fly compilation etc. But I repeatedly > > get the feeling that all these current approaches aren't actually very > > good. But what if we had some kind of specialized format for compiled, > > dynamically loadable, typed Haskell libraries? Something between a > > plain OS library and bytecode. This might help make programs more > > modular while keeping them type safe. > > > > One thing that might be useful to add next would be some kind of > > centralized registry of types, so that a plugin/library could extend > > the ways the system could be extended. > > > > And going along this line of thought even further leads to… uhm… > > oh. OH. > > > > Ok, so, it's the month of Halloween, right? > > > > Because… OSGi, but in Haskell. > > > > Well, maybe there's some sane point in between? > > > > Cheers, > > MarLinn > > > > _______________________________________________ > > 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 barak at pearlmutter.net Sat Oct 6 15:03:19 2018 From: barak at pearlmutter.net (Barak A. Pearlmutter) Date: Sat, 6 Oct 2018 16:03:19 +0100 Subject: [Haskell-cafe] Well typed OS Message-ID: At a high level, you seem to be proposing encoding and enforcing safety properties of executables using a type system. One instantiation of this idea is proof-carrying-code (Necula and Lee, 1996, see https://en.wikipedia.org/wiki/Proof-carrying_code), which ensures safety properties of machine code. The spin-off Cedilla Systems built a mobile OS (intended for phones) around this, with the idea that third-party apps would run unprotected with safety guaranteed solely by sophisticated use of types. The Fox Project, http://www.cs.cmu.edu/~fox/, was philosophically similar, and their web page contains a bunch of interesting pointers to relevant work. For whatever reason, this stuff never got much penetration. But in today's Internet of Things, with malware being injected into mobile phones and cars and light bulbs and toothbrushes and smart dust, it may deserve another look. From mihai.maruseac at gmail.com Sat Oct 6 16:18:06 2018 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Sat, 6 Oct 2018 09:18:06 -0700 Subject: [Haskell-cafe] [Call for Contributions] Haskell Communities and Activities Report, November 2018 edition (35th edition) Message-ID: Dear all, We would like to collect contributions for the 35th edition of the ============================================================ Haskell Communities & Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 4 November 2018 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format, both are equally accepted) ============================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell us, so that we can contact the project leaders and ask them to submit an entry. * If you are working on a project that is looking for contributors, please write a short entry and submit it, mentioning that your are looking for contributors. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the previous edition --- you will find interesting projects described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Mihai Maruseac FAQ: Q: What format should I write in? A: Any format is ok, I will transpose the submission to the format in use at the time of publication. Previous editions have used a LaTeX format, with the template that is available at: http://haskell.org/communities/11-2018/template.tex And the associated LaTeX style file at http://haskell.org/communities/11-2018/hcar.sty You can use those to edit and preview your entry, but it is very likely that by the time of publication the entire HCAR pipeline would be changed to a more modern one. You will receive a copy of the draft, prior to publication, to ensure that everything looks ok. If you modify an old entry that you have written for an earlier edition of the report, you should soon receive your old entry as a template (provided we have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include Haskell code? A: Yes. If using LaTeX, you can use lhs2tex syntax (http://www.andres-loeh.de/lhs2tex/). The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg or .png format, then. PNG is preferred for simplicity. Q: Should I send files in .zip archives or similar? A: No, plain file attachments are the way. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or "historic" overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also simply ask us. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use HCAR to ask for more contributors to your project, it is a good way to gain visibility and traction. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell us that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. Q: Will I get confirmation if I send an entry? How do I know whether my email has even reached its destination, and not ended up in a spam folder? A: Prior to publication of the final report, we will send a draft to all contributors, for possible corrections. So if you do not hear from us within two weeks after the deadline, it is safer to send another mail and check whether your first one was received. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya From alexander.kjeldaas at gmail.com Sat Oct 6 16:34:05 2018 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Sat, 6 Oct 2018 18:34:05 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: You could consider the compiler for the IO type part of the TCB and execute source code with caching, like nix. Every process could be wrapped in an IO sandbox that is enforcing the types for all IO operations. That just requires being able to implement a->Maybe b i.e. have a fixed binary representation for the data in and out of the inner program. Something like rudimentary programmable scripts that run on kernel system call invocations already exists in Linux, so it could be possible to compile down to that. Alexander 2018, 17:04 Barak A. Pearlmutter wrote: > At a high level, you seem to be proposing encoding and enforcing > safety properties of executables using a type system. One > instantiation of this idea is proof-carrying-code (Necula and Lee, > 1996, see https://en.wikipedia.org/wiki/Proof-carrying_code), which > ensures safety properties of machine code. The spin-off Cedilla > Systems built a mobile OS (intended for phones) around this, with the > idea that third-party apps would run unprotected with safety > guaranteed solely by sophisticated use of types. The Fox Project, > http://www.cs.cmu.edu/~fox/, was philosophically similar, and their > web page contains a bunch of interesting pointers to relevant work. > > For whatever reason, this stuff never got much penetration. But in > today's Internet of Things, with malware being injected into mobile > phones and cars and light bulbs and toothbrushes and smart dust, it > may deserve another look. > _______________________________________________ > 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 will.yager at gmail.com Sun Oct 7 01:31:21 2018 From: will.yager at gmail.com (William Yager) Date: Sun, 7 Oct 2018 09:31:21 +0800 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: On Sat, Oct 6, 2018 at 11:03 PM Barak A. Pearlmutter wrote: > At a high level, you seem to be proposing encoding and enforcing > safety properties of executables using a type system. One > instantiation of this idea is proof-carrying-code (Necula and Lee, > 1996, see https://en.wikipedia.org/wiki/Proof-carrying_code), which > ensures safety properties of machine code. I would guess a factor that prevented something like PCC from taking off is the fact that proofs over binaries are relatively pretty challenging to express and verify, and ISA semantics tend to be really complicated. I think an intermediate approach that might be a lot cheaper to implement is to ship some sort of IR (rather than machine code) that is A) relatively cheap to check and compile and B) carries some variety of safety guarantee. As I recall, A) is already in use. Apple requires developers to submit applications as LLVM IR rather than machine code. LLVM IR definitely isn't designed with B) in mind, however. I could imagine something like Core being useful here. A fully annotated type-checked language with semantics amenable to formal analysis. You could add some sort of effects system to the type system of the IR, as a basis for enforcing security policies. E.g. network access could be an effect. The advantage of doing this over PCC is that we don't have to retrofit the proof system to match the ISA, but instead can design the IR specifically to make the proof system easy. A downside is that you have to compile the application once upon downloading it, but this doesn't seem to cause too much of an issue in practice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgoerzen at complete.org Sun Oct 7 01:57:27 2018 From: jgoerzen at complete.org (John Goerzen) Date: Sat, 06 Oct 2018 20:57:27 -0500 Subject: [Haskell-cafe] Looking for maintainers for all my packages Message-ID: <87d0smwmbc.fsf@complete.org> Hi folks, I would like to hand over my remaining Haskell packages to good hands. Please reply, CCing me, if you would like to volunteer. Thanks! These packages are: Libraries: ConfigFile HSH MissingH MissingPy (looks like MattBrown uploaded it a bit in 2012) anydbm ftphs hslogger magic testpack Programs: datapacker gtkrsync hpodder twidge txt2rtf Obsolete, no maintainer needed: darcs-buildpackage dfsbuild gopherbot hg-buildpackage srcinst - John From barak at pearlmutter.net Sun Oct 7 09:00:25 2018 From: barak at pearlmutter.net (Barak A. Pearlmutter) Date: Sun, 7 Oct 2018 10:00:25 +0100 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: > I would guess a factor that prevented something like PCC from taking off is the fact that proofs over binaries are relatively pretty challenging to express and verify, and ISA semantics tend to be really complicated. The Cedilla folks had a pretty clever way of dealing with that issue. They had a very small proof checker on the embedded device, which used highly compressed information associated with the binary to basically guide a theorem prover, where the information helped the prover make all its choices. This information was generated from a proof generated by a compiler, which compiled a high-level language (C in their case) annotated with extra safety-proof-related information down to both machine code an a proof of that machine code's safety. So they sort of did what you're describing, but partially evaluated away the IR. From ionut.g.stan at gmail.com Sun Oct 7 10:41:33 2018 From: ionut.g.stan at gmail.com (=?UTF-8?Q?Ionu=c8=9b_G=2e_Stan?=) Date: Sun, 7 Oct 2018 13:41:33 +0300 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: <56b4ad66-edcb-3985-e488-2c7ba6399da4@gmail.com> The JVM is also doing something similar. There's a step in the process of loading the .class files called "bytecode verification". Ιt's basically a type checker for the stack language used in the bytecode. This was problematic in Java before version 7, because it was possible to cause denial-of-service attacks by sending malicious bytecode payloads. The verifier would spend O(n^2) time verifying that the bytecode behaves correctly. As of Java 7, compilers are required to add additional info alongside the bytecode instructions. This extra info is called a stackmap table and allows the verifier to complete its verification in O(n) steps, IIRC. So, a certain instantiation of PPC is already used in the wild. On 07/10/2018 12:00, Barak A. Pearlmutter wrote: >> I would guess a factor that prevented something like PCC from taking off is the fact that proofs over binaries are relatively pretty challenging to express and verify, and ISA semantics tend to be really complicated. > > The Cedilla folks had a pretty clever way of dealing with that issue. > They had a very small proof checker on the embedded device, which used > highly compressed information associated with the binary to basically > guide a theorem prover, where the information helped the prover make > all its choices. > > This information was generated from a proof generated by a compiler, > which compiled a high-level language (C in their case) annotated with > extra safety-proof-related information down to both machine code an a > proof of that machine code's safety. So they sort of did what you're > describing, but partially evaluated away the IR. > _______________________________________________ > 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. > -- Ionuț G. Stan | http://igstan.ro | http://bucharestfp.ro From jo at durchholz.org Sun Oct 7 11:10:17 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 7 Oct 2018 13:10:17 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <56b4ad66-edcb-3985-e488-2c7ba6399da4@gmail.com> References: <56b4ad66-edcb-3985-e488-2c7ba6399da4@gmail.com> Message-ID: <7ce076a1-e8d8-0707-96c6-64418f285f02@durchholz.org> Am 07.10.2018 um 12:41 schrieb Ionuț G. Stan: > The JVM is also doing something similar. There's a step in the process > of loading the .class files called "bytecode verification". Ιt's > basically a type checker for the stack language used in the bytecode. It's checking more than just types: * Branch target and exception handler address validity. * Stack offset validity. * Each code branch ends with a return instruction. * Local variables initialized before use in each branch of code. * No stack overflow or underflow along each code path. * Validation of private and protected access. I suspect that all of this can be expressed as a type check, but some of them require that a type be generated for each natural number that's in the class file, and I have yet to see an approach that gives each of these types a printable, humanly understandable representation. From ionut.g.stan at gmail.com Sun Oct 7 11:47:48 2018 From: ionut.g.stan at gmail.com (=?UTF-8?Q?Ionu=c8=9b_G=2e_Stan?=) Date: Sun, 7 Oct 2018 14:47:48 +0300 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <7ce076a1-e8d8-0707-96c6-64418f285f02@durchholz.org> References: <56b4ad66-edcb-3985-e488-2c7ba6399da4@gmail.com> <7ce076a1-e8d8-0707-96c6-64418f285f02@durchholz.org> Message-ID: <91a7ead4-17bd-97b5-35ea-a273446ee624@gmail.com> On 07/10/2018 14:10, Joachim Durchholz wrote: > Am 07.10.2018 um 12:41 schrieb Ionuț G. Stan: >> The JVM is also doing something similar. There's a step in the process >> of loading the .class files called "bytecode verification". Ιt's >> basically a type checker for the stack language used in the bytecode. > > It's checking more than just types: Sure. I used an informal, hand-wavy sense for "type checker". > * Branch target and exception handler address validity. > * Stack offset validity. > * Each code branch ends with a return instruction. > * Local variables initialized before use in each branch of code. > * No stack overflow or underflow along each code path. > * Validation of private and protected access. > > I suspect that all of this can be expressed as a type check, but some of > them require that a type be generated for each natural number that's in > the class file, and I have yet to see an approach that gives each of > these types a printable, humanly understandable representation. Can you give a bit more detail here? Or a pointer to someone who elaborated on this? I got a bit lost on the natural number step, which seems to be some sort of theoretical way to represent those types. On the other hand you say they're in the class file. BTW, I'm quite familiar with the class file format and have even started writing a bytecode verifier for my own compiler pet project. So, be as specific as you can. > _______________________________________________ > 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. > -- Ionuț G. Stan | http://igstan.ro | http://bucharestfp.ro From jo at durchholz.org Sun Oct 7 16:18:50 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 7 Oct 2018 18:18:50 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <91a7ead4-17bd-97b5-35ea-a273446ee624@gmail.com> References: <56b4ad66-edcb-3985-e488-2c7ba6399da4@gmail.com> <7ce076a1-e8d8-0707-96c6-64418f285f02@durchholz.org> <91a7ead4-17bd-97b5-35ea-a273446ee624@gmail.com> Message-ID: Am 07.10.2018 um 13:47 schrieb Ionuț G. Stan: >> a type be generated for each natural number that's in >> the class file, and I have yet to see an approach that gives each of >> these types a printable, humanly understandable representation. > > Can you give a bit more detail here? Or a pointer to someone who > elaborated on this? I got a bit lost on the natural number step, which > seems to be some sort of theoretical way to represent those types. You can make Haskell's type system count, by defining a `Zero` type and a `Succ a` type - well, I think it's a kind (i.e. a type of types). That (and equality) is enough to do natural numbers - you have Zero, One = Succ Zero, Two = Succ Succ Zero, etc. I don't know enough about this stuff to give a recipe, I just saw descriptons of what people were doing. The earliest awesome trick of this kind was somebody who encoded matrix squareness in the type system. (You cannot even define inversion for a non-square matrix, so square matrices are pretty different beasts than non-square ones.) Somebody else (I think) started doing the natural numbers. You can do any kinds of cool tricks with that, such as cleanly expressing that to multiply two matrices, the height of one matrix needs to be the same as the width of the other. In theory, you can express any arithmetic relationships within the type system that way: Addresses, matrix dimension constraints, etc. In practice, any error messages are going to look like "invalid type Succ Succ Succ .... Succ Zero", and you have to count the number of Succs, which sucks (pun intended). I suspect you can also do fractional numbers with that - you essentially translate the axioms some type (or kind) declarations. I'd expect that to be even less usable in practice. However, it's intriguing what you can do with types. Now please take this all with a grain of salt. I never used this kind of stuff in practice, I just saw the reports of people doing this clever insanity, and didn't want to do it myself. The approach never took on if this kind of old lore isn't present in Haskell Café anymore. > BTW, I'm quite familiar with the class file format and have even started > writing a bytecode verifier for my own compiler pet project. So, be as > specific as you can. I was more like handwaving at the possibility of turning all assertions over integral numbers into type constraints. I am definitely not recommending doing this in practice! Regards, Jo From vanessa.mchale at iohk.io Sun Oct 7 23:34:08 2018 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Sun, 7 Oct 2018 18:34:08 -0500 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: Message-ID: <1e225595-64cb-b879-f4c7-15896eaf4d74@iohk.io> The problem with an IR is that some languages would inevitably suffer - LLVM in particular was designed as a backend for a C compiler, and so it is not necessarily well-suited for lazy languages, immutable languages, etc. (not to mention self-modifying assembly and other such pathological beasts...) On 10/06/2018 08:31 PM, William Yager wrote: > > > On Sat, Oct 6, 2018 at 11:03 PM Barak A. Pearlmutter > > wrote: > > At a high level, you seem to be proposing encoding and enforcing > safety properties of executables using a type system. One > instantiation of this idea is proof-carrying-code (Necula and Lee, > 1996, see https://en.wikipedia.org/wiki/Proof-carrying_code), which > ensures safety properties of machine code.  > > > I would guess a factor that prevented something like PCC from taking > off is the fact that proofs over binaries are relatively pretty > challenging to express and verify, and ISA semantics tend to be really > complicated. > > I think an intermediate approach that might be a lot cheaper to > implement is to ship some sort of IR (rather than machine code) that > is A) relatively cheap to check and compile and B) carries some > variety of safety guarantee. > > As I recall, A) is already in use. Apple requires developers to submit > applications as LLVM IR rather than machine code. > > LLVM IR definitely isn't designed with B) in mind, however. I could > imagine something like Core being useful here. A fully annotated > type-checked language with semantics amenable to formal analysis. > > You could add some sort of effects system to the type system of the > IR, as a basis for enforcing security policies. E.g. network access > could be an effect. > > The advantage of doing this over PCC is that we don't have to retrofit > the proof system to match the ISA, but instead can design the IR > specifically to make the proof system easy. A downside is that you > have to compile the application once upon downloading it, but this > doesn't seem to cause too much of an issue in practice. > > >    > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jo at durchholz.org Mon Oct 8 05:53:04 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 8 Oct 2018 07:53:04 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <1e225595-64cb-b879-f4c7-15896eaf4d74@iohk.io> References: <1e225595-64cb-b879-f4c7-15896eaf4d74@iohk.io> Message-ID: <124e69fc-04e8-d877-70e7-8f126ec84271@durchholz.org> Am 08.10.2018 um 01:34 schrieb Vanessa McHale: > The problem with an IR is that some languages would inevitably suffer - > LLVM in particular was designed as a backend for a C compiler, and so it > is not necessarily well-suited for lazy languages, immutable languages, > etc. (not to mention self-modifying assembly and other such pathological > beasts...) Actually LLVM is built for being adaptable to different kinds of languages. It does have a bias towards C-style languages, but you can adapt what doesn't fit your needs *and still keep the rest*. The following was true a few years ago: When I asked, the LLVM IR was intentionally not specified to be reusable across languages, so that different compiler toolchain could adapt the IR to whatever needs their language or backend infrastructure needed. Garbage collection is one area where you have to do a lot of work. There are some primitive instructions that support it, but the semantics is vague and doesn't cover all kinds of write barriers. You'll have to roll your own IR extensions - or maybe I didn't understand the primitives well enough to see how much they cover. Anyway, LLVM does not come with a GC implementation. OTOH, it does not prevent you from doing a GC. In particular, you're free to avoid C-style pointers, so you have the full range of GC algorithms available. Laziness? No problem. If you do tagless/spineless, you'll code the evaluation machine anyway. Just add an IR instructions that calls the interpreter. Immutability? No problem - actually nowhere a problem. Immutability happens at the language level, at the IR level it is pretty irrelevant because compilers try to replace object copying by in-place modification wherever possible, anyway. Self-modifying assembly? No IR really supports that. Mostly it's backends that generate self-modifying code from IR instructions for specific backends. TL;DR: For its generality, LLVM IR is better suited to languages with specific needs in the backend than anything else that I have seen (which means C runtimes, various VM proofs of concept which don't really count, and JVM - in particular I don't know how .net compares). Regards, Jo From arrowd at freebsd.org Mon Oct 8 07:08:40 2018 From: arrowd at freebsd.org (Gleb Popov) Date: Mon, 8 Oct 2018 10:08:40 +0300 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <124e69fc-04e8-d877-70e7-8f126ec84271@durchholz.org> References: <1e225595-64cb-b879-f4c7-15896eaf4d74@iohk.io> <124e69fc-04e8-d877-70e7-8f126ec84271@durchholz.org> Message-ID: On Mon, Oct 8, 2018 at 8:53 AM Joachim Durchholz wrote: > Am 08.10.2018 um 01:34 schrieb Vanessa McHale: > > The problem with an IR is that some languages would inevitably suffer - > > LLVM in particular was designed as a backend for a C compiler, and so it > > is not necessarily well-suited for lazy languages, immutable languages, > > etc. (not to mention self-modifying assembly and other such pathological > > beasts...) > Actually LLVM is built for being adaptable to different kinds of > languages. It does have a bias towards C-style languages, but you can > adapt what doesn't fit your needs *and still keep the rest*. > > The following was true a few years ago: > > When I asked, the LLVM IR was intentionally not specified to be reusable > across languages, so that different compiler toolchain could adapt the > IR to whatever needs their language or backend infrastructure needed. > > Garbage collection is one area where you have to do a lot of work. There > are some primitive instructions that support it, but the semantics is > vague and doesn't cover all kinds of write barriers. You'll have to roll > your own IR extensions - or maybe I didn't understand the primitives > well enough to see how much they cover. > Anyway, LLVM does not come with a GC implementation. > OTOH, it does not prevent you from doing a GC. In particular, you're > free to avoid C-style pointers, so you have the full range of GC > algorithms available. > > Laziness? No problem. If you do tagless/spineless, you'll code the > evaluation machine anyway. Just add an IR instructions that calls the > interpreter. > I'm far from expert in this area, but isn't that "interpreter" a simple yet slow approach to codegen? My understanding is that when you use, say, a global variable as a register for your evaluation machine, it is slower than if you somehow pin real hardware register for that purpose. I think this is what "registerized" GHC build means. In LLVM you can't use, say, RSP in a way you want, but it is doomed to be "stack pointer register", even if you don't use stack at all. As I read in some blog, you can slightly affect LLVM codegen by adding calling conventions, but the real solution would be another algorithm for instruction selection. No one implemented that yet, AFAIK. > Immutability? No problem - actually nowhere a problem. Immutability > happens at the language level, at the IR level it is pretty irrelevant > because compilers try to replace object copying by in-place modification > wherever possible, anyway. > > Self-modifying assembly? No IR really supports that. Mostly it's > backends that generate self-modifying code from IR instructions for > specific backends. > > TL;DR: For its generality, LLVM IR is better suited to languages with > specific needs in the backend than anything else that I have seen (which > means C runtimes, various VM proofs of concept which don't really count, > and JVM - in particular I don't know how .net compares). > > Regards, > Jo > _______________________________________________ > 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 jo at durchholz.org Mon Oct 8 18:14:17 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 8 Oct 2018 20:14:17 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: <1e225595-64cb-b879-f4c7-15896eaf4d74@iohk.io> <124e69fc-04e8-d877-70e7-8f126ec84271@durchholz.org> Message-ID: Am 08.10.2018 um 09:08 schrieb Gleb Popov: > > Laziness? No problem. If you do tagless/spineless, you'll code the > evaluation machine anyway. Just add an IR instructions that calls the > interpreter. > > I'm far from expert in this area, but isn't that "interpreter" a simple > yet slow approach to codegen? My understanding is that when you use, > say, a global variable as a register for your evaluation machine, it is > slower than if you somehow pin real hardware register for that purpose. > I think this is what "registerized" GHC build means. My impression has been that GHC is compiling everything down to machine code. FWIW most mentions I saw were of the kind "we replace tagless/spineless with X", not of the "we build on tagless/spineless doing Y". Not that I have read many papers - I'm awfully behind on these topics. > In LLVM you can't use, say, RSP in a way you want, but it is doomed to > be "stack pointer register", even if you don't use stack at all. Actually it seems possible since some version between 3.4 and 3.6. https://stackoverflow.com/questions/29365198/how-to-use-llvm-intrinsics-llvm-read-register discusses a way of doing exactly that. Not sure about ramifications though. Still, seeing how many wildly varying languages use LLVM for code generation, it seems to be widely considered to be the most flexible available one. If somebody knows of something more flexible, paint me interested :-) Regards, Jo From simon at joyful.com Tue Oct 9 21:41:28 2018 From: simon at joyful.com (Simon Michael) Date: Tue, 9 Oct 2018 14:41:28 -0700 Subject: [Haskell-cafe] What is the best way to search information on Haskell Cafe? In-Reply-To: References: Message-ID: If you want to heavily search and browse past mail list archives in comfort, I highly recommend installing a good newsreader (Earlybird) and pointing it at the Gmane NNTP server (news.gmane.org). There you can search for and subscribe to many of the haskell (and other FOSS) mail lists. Once subscribed to a list, you can have Earlybird download the most recent N or the entire archive of past messages. (Gmane's status is a bit unclear right now, but for now it still works extremely well.) From c at functionx.org Thu Oct 11 14:34:43 2018 From: c at functionx.org (Christopher Lewis) Date: Thu, 11 Oct 2018 10:34:43 -0400 Subject: [Haskell-cafe] NYC Haskell Developer Position Message-ID: Karamaan Group is an investment firm based in Manhattan. We are looking for an outstanding software developer to develop tools for financial analysis and knowledge management. Since we are investors and not traders, our focus is not on building trading systems, but on business and data analysis. We strongly value people who take pride in their work and have a craftsman’s dedication to building bespoke products. Our ideal candidate is an experienced software developer with a penchant for abstraction and analysis, a solid sense of organization, and an ability to communicate and persuade. While we are looking for a candidate who demonstrates an intense focus on quality, she also needs a master engineer’s intuition for how to make trade offs that are a necessary part of day-to-day software development. Candidates should have some formal training in a quantitative field and a keen interest in building robust and elegant software. This is a high-impact, high-visibility position where successful candidates will be entrusted with a lot of responsibility for products that have a direct effect on the P&L of the firm and influence on our workflow. The ideal candidate will have production experience with Haskell or another functional language, relational databases and relational data modeling, Python, and Java. Additionally, as this is a startup environment, the ideal candidate will be comfortable filling many different technology roles, and contributing to the success of the firm wherever they can, not just in agreement with their job description. Karamaan Group is an investment adviser and manager catering to family offices and institutional investors. We value innovative thinking, encourage an entrepreneurial atmosphere, and enjoy spirited discussions. Please send your CV and cover letter to recruitment at karamaan dot com. Please do not reply to the original poster. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Fri Oct 12 03:44:13 2018 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 12 Oct 2018 12:44:13 +0900 (JST) Subject: [Haskell-cafe] Creating the network-bsd package Message-ID: <20181012.124413.2138799962975424489.kazu@iij.ad.jp> Hi, We the network package maintainers are planning to release network v3.0.0.0 which enables extending socket addresses. In this version, we will remove the Network.BSD module which version 2.7 already deprecates. Unfortunately, it appeared that many users use Network.BSD and there is no good alternative. So, I would like to split it into another package, say, network-bsd. Some years ago, the same thing happened to Network.URI, resulting in the network-uri and network-uri-flag packages. Currently, I'm planing to take the same approach: ---- flag network-bsd library -- ... if flag(network-bsd) build-depends: network-bsd >= 3.0, network >= 3.0 else build-depends: network-bsd < 3.0, network < 3.0 --- Or ---- build-depends: network >= 2.5 && < 2.7, network-bsd >= 2.5 && < 2.7, network-bsd-flag == 0.1.* --- Question: is this a correct appoarch? Or are there any better ways to split Netwrok.BSD? --Kazu From fumiexcel at gmail.com Fri Oct 12 05:47:38 2018 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Fri, 12 Oct 2018 14:47:38 +0900 Subject: [Haskell-cafe] Creating the network-bsd package In-Reply-To: <20181012.124413.2138799962975424489.kazu@iij.ad.jp> References: <20181012.124413.2138799962975424489.kazu@iij.ad.jp> Message-ID: I was having trouble because of the deprecation; network-bsd would be really appreciated. As for splitting, I think there's nothing special to do. On users side I'd prefer flags. 2018年10月12日(金) 12:44 Kazu Yamamoto : > Hi, > > We the network package maintainers are planning to release network > v3.0.0.0 which enables extending socket addresses. In this version, we > will remove the Network.BSD module which version 2.7 already > deprecates. > > Unfortunately, it appeared that many users use Network.BSD and there > is no good alternative. So, I would like to split it into another > package, say, network-bsd. > > Some years ago, the same thing happened to Network.URI, resulting in > the network-uri and network-uri-flag packages. Currently, I'm planing > to take the same approach: > > ---- > flag network-bsd > library > -- ... > if flag(network-bsd) > build-depends: network-bsd >= 3.0, network >= 3.0 > else > build-depends: network-bsd < 3.0, network < 3.0 > --- > > Or > > ---- > build-depends: > network >= 2.5 && < 2.7, > network-bsd >= 2.5 && < 2.7, > network-bsd-flag == 0.1.* > --- > > Question: is this a correct appoarch? Or are there any better ways to > split Netwrok.BSD? > > --Kazu > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Sun Oct 14 06:30:35 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sun, 14 Oct 2018 19:30:35 +1300 Subject: [Haskell-cafe] Impossible types [was [Haskell-prime]: A question about run-time errors when class members are undefined] In-Reply-To: References: Message-ID: Transferring from https://mail.haskell.org/pipermail/haskell-prime/2018-October/004396.html On Sat, 13 Oct 2018 at 4:04 AM, wrote: > > Consider for example: > > class F a b where f:: a → b > class X a where x:: a > fx = f x > > The type of fx, (F a b, X a) ⇒ b, should not be ambiguous: in > distinct contexts, fx can have distinct types (if ambiguity, and > 'improvement', are as defined below). [See the -prime message for the "defined below".] I'm just not seeing why you think any Haskell should accept that. What value could inhabit `fx` except bottom? And indeed no Haskell does accept it, not even GHC with all sorts of nasty extensions switched on, including `AllowAmbiguousTypes`. GHC will accept class `F` with a Functional Dependency `b -> a`, but still I can't 'poke' any value into the `x` argument to `f` in the equation for `fx`. Note: agreeing with this view can lead to far-reaching consequences, e.g. > support of > overloaded record fields [1,Section 7], ... There are other ways to support overloaded/duplicate record fields, without doing this much violence to the type system. Look at the `HasField` class using Functional Dependencies, in Adam Gundry's work. polymonads [2] etc. > Note that's from a Trac ticket asking for 'dysfunctional' Functional Dependencies. There's a long discussion from the type-inference brains trust coming to no discernable conclusion as to whether it's broken type safety. (Catching incoherence in the Core lint typecheck is not a good look.) a) You've not shown any detailed working of how your proposal gives the type improvement required without also descending into incoherence. b) The combination of Functional Dependencies+Overlapping Instances+Undecidable Instances might be able to cover just enough, but not too much of the requirements (which were never made clear). See my worked examples on that ticket -- some of which are really quite scary. See some of Oleg's work on his ftp site with multi-directional FunDeps and overlaps to achieve injectivity. To try to tame the scariness while still supporting enough power, see the suggestion here https://ghc.haskell.org/trac/ghc/ticket/15632 > Further examples can be discussed I have yet to see a convincing use case (from the very lengthy discussions) which couldn't be handled already in GHC. I agree the combination of extensions in GHC (including its bogus consistency check/Trac #10675) can give alarming surprises; but they don't quite break type safety. but this example conveys the > main idea that ambiguity should be changed; unlike the example > of (show . read), no type annotation can avoid ambiguity of > polymorphic fx in current Haskell. Since `fx` is not accepted in current Haskell, whether you can put a type annotation seems beside the point. AntC [1] Optional Type Classes for Haskell, Rodrigo Ribeiro, Carlos Camarão, Lucília Figueiredo, Cristiano Vasconcellos, SBLP'2016 (20th Brazilian Symposium on Programming Languages), Marília, SP, September 19-23, 2016. [2] https://github.com/carlos1camarao/ghc-proposals/blob/d81c1f26298961ac635ce0724bb76164b418866b/expression-ambiguity.rst -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikoshaskell at gmail.com Sun Oct 14 16:29:55 2018 From: nikoshaskell at gmail.com (Nikos Karagiannidis) Date: Sun, 14 Oct 2018 19:29:55 +0300 Subject: [Haskell-cafe] =?utf-8?q?ANN=3A_DBFunctor_=E2=80=93_Functional_Da?= =?utf-8?q?ta_Management_/_ETL_Data_Processing_in_Haskell?= Message-ID: Dear all, I am pleased to announce the release on Hackage of a new Haskell ETL Library, namely DBFunctor-0.1.0.0. (“ETL” stands for Extract Transform and Load and is the standard technology for accomplishing data management tasks in Data Warehouses / Data Marts and in general for data migrations, or for preparing data for any analytic purpose (Ad hoc queries, data exploration/data analysis, Reporting and Business Intelligence, feeding Machine Learning algorithms, etc.)) Version 0.1.0.0 can be used for *in-memory data processing* without the need of some external database. It is just a Haskell library linked in your Haskell program that enables full SQL functionality over tabular data (e.g., CSV files) but also the ability to write a full ETL data processing flow. Key features of this release are: 1. *Julius DSL*: A Type-Level Embedded Domain Specific Language (EDSL) for ETL 2. Supports all known relational algebra operations 3. Implements the ETL Mapping and other typical ETL constructs and operations 4. Applicable to all kinds of tabular data 5. In-memory, database-less data processing For more information please check out the project homepage: https://github.com/nkarag/haskell-DBFunctor Also there is a tutorial that can help you to easily get started with Julius DSL: https://github.com/nkarag/haskell-DBFunctor/blob/master/doc/JULIUS-TUTORIAL.md * Learn how to implement your ETL flows with Julius DSL * Learn how to implement common ETL operations (append a delta to some target table, or create a surrogate key column etc.) * Build your own aggregate or analytic functions (string_agg, or a montlhy running total) * Express complex queries with Julius (equivalent to the WITH-clause in SQL) * and many more ... For any issues/problems with the DBFunctor package please open an issue on github. Happy data processing! Thank you. Best Regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Oct 14 22:17:12 2018 From: ben at well-typed.com (Ben Gamari) Date: Sun, 14 Oct 2018 18:17:12 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.4 released Message-ID: <878t30npgc.fsf@smart-cactus.org> Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.4, a patch-level release in the 8.4 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.4 This release fixes several bugs present in 8.4.3 These include, - A bug which could result in memory unsafety with certain uses of `touch#` has been resolved. (#14346) - A compiler panic triggered by some GADT record updates has been fixed (#15499) - The `text` library has been updated, fixing several serious bugs in the version shipped with GHC 8.4.3 (see `text` issues #227, #221, and #197. - A serious code generation bug in the LLVM code generation, potentially resulting in incorrect evaluation of floating point expressions, has been fixed (#14251) As always, the full release notes can be found in the users guide, https://downloads.haskell.org/~ghc/8.4.4/docs/html/users_guide/8.4.4-notes.html Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From anthony_clayden at clear.net.nz Mon Oct 15 04:55:31 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 15 Oct 2018 17:55:31 +1300 Subject: [Haskell-cafe] Impossible types [was [Haskell-prime]: A question about run-time errors when class members are undefined] In-Reply-To: References: Message-ID: Transferring from https://mail.haskell.org/pipermail/haskell-prime/2018-October/004396.html Second instalment. On Sat, 13 Oct 2018 at 4:04 AM, wrote: > ... > Ambiguity should be a property of an expression, defined as > follows: if a constraint set C on the constrained type C∪D⇒t of > an expression has unreachable variables, then satisfiability is > tested for C (a definition of reachable and unreachable type > variables is at the end of this message), and: > > - if there is a single unifying substitution of C with the set > of instances in the current context (module), then C can be > removed (overloading is resolved) and C∪D⇒t 'improved' to > D⇒t; > > - otherwise there is a type error: ambiguity if there are two > or more unifying substitutions of C with the set of instances > in the current context (module), and unsatisfiability > otherwise. > > 2. Allow instances to be imported (all instances are assumed to be > exported): > > import M (instance A τ₁ ⋯ τₙ , … ) > > specifies that the instance of τ₁ ⋯ τₙ for class A is > imported from M, in the module where the import clause > occurs. > > In case of no explicit importation, all instances remain > imported, as currently in Haskell (in order that well-typed > programs remain well-typed). > Consider some typical Read instances from the Haskell Prelude > instance Read a => Read [a] where ... > instance Read a => Read (Maybe a) where ... Suppose I have `show . read` where the 'piggy in the middle' type is unreachable (by your definition below); but I want it to be taken as `(Maybe [Int])`. Then I arrange my imports of instances to make visible only ... what? `(Maybe a)` ? Then how do I read the `[a]`? The only instance in scope is `(Maybe a)`. `(Maybe [Int])` ? Then how do I decompose the structure to call the overloads for `read` of the list and of the `Int`? Instance `(Maybe a)` is not in scope, neither is `[a]` nor `Int`. And what if in the same module/same scope I want `show . read` where 'piggy in the middle' is `[Maybe Int]` or `(Maybe [Bool])` ? Then instead of `Read`, I could create a whole swag of specialised classes/methods: ReadMaybeListInt, ReadListMaybeInt, ReadMaybeListBool, ... ? But those could just be regular functions with an explicit signature. Putting an explicit type annotation on each expression seems a whole lot more convenient than mucking around with specialised classes or scope of instances. Before you answer, consider this very common pattern. It's so common there's a base library operator for it: type-level `==` https://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.12.0.0/src/Data-Type-Equality.html#%3D%3D; but the technique dates back to 2004/the HList paper at least: > class TypeEq a a' (b :: Bool) | a a' -> b > instance TypeEq a a True > instance (b ~ False) => TypeEq a a' b Then an example usage > instance (TypeEq e e' b, TypeIf b This That) => instance Elem e (Cons e' tail) where ... Rubric: `Elem` is searching for type `e` in some type-level heterogeneous list; if found (i.e. `TypeEq` returns `True`), the `TypeIf` despatches to `This`, else to `That`. It's crucial for `TypeEq` that both instances are in scope in all places. Ah, but I see the `TypeEq` example does not contain any "unreachable" tyvars by your definition below. In which case your specification is silent as to how type improvement is to behave. (But you claim your approach is instead of FunDeps; then what is to happen with both instances being able to unify with the type of some expression?) Then do you want to change the spec? This was the experience with the github rounds: the spec kept changing; the examples we'd worked through in earlier rounds then didn't work with the new spec. Therefore the claims were impossible to verify with any certainty. > > (Definition: [Reachable and unreachable type variables in constraints] > Consider a constrainted type C∪D⇒τ. A variable a ∈ tv(C) is reachable > from V = tv(τ) if a ∈ V or if a ∈ tv(π) for some π ∈ C such that there > exists b ∈ tv(π) such that b is reachable from V; otherwise it is > unreachable. > For example, in (F a b, X a) ⇒ b, type variable 'a' is reachable from > { b }, because 'a' occurs in constraint F a b, and b is reachable. > Similarly, if C = (F a b, G b c, X c), then c is reachable from {a}.) > > AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikoshaskell at gmail.com Tue Oct 16 10:23:13 2018 From: nikoshaskell at gmail.com (Nikos Karagiannidis) Date: Tue, 16 Oct 2018 13:23:13 +0300 Subject: [Haskell-cafe] =?utf-8?q?ANN=3A_DBFunctor_=E2=80=93_Functional_Da?= =?utf-8?q?ta_Management_/_ETL_Data_Processing_in_Haskell?= Message-ID: Dear all, I am pleased to announce the release on Hackage of a new Haskell ETL Library, namely DBFunctor-0.1.0.0. (“ETL” stands for Extract Transform and Load and is the standard technology for accomplishing data management tasks in Data Warehouses / Data Marts and in general for data migrations, or for preparing data for any analytic purpose (Ad hoc queries, data exploration/data analysis, Reporting and Business Intelligence, feeding Machine Learning algorithms, etc.)) Version 0.1.0.0 can be used for **in-memory** data processing without the need of some external database. It is just a Haskell library linked in your Haskell program that enables full SQL functionality over tabular data (e.g., CSV files) but also the ability to write a full ETL data processing flow. Key features of this release are: 1. ** Julius DSL ** : A Type-Level Embedded Domain Specific Language (EDSL) for ETL 2. Supports all known relational algebra operations 3. Implements the ETL Mapping and other typical ETL constructs and operations 4. Applicable to all kinds of tabular data 5. In-memory, database-less data processing For more information please check out the project homepage: https://github.com/nkarag/haskell-DBFunctor Also there is a tutorial that can help you to easily get started with Julius DSL: https://github.com/nkarag/haskell-DBFunctor/blob/master/doc/JULIUS-TUTORIAL.md * Learn how to implement your ETL flows with Julius DSL * Learn how to implement common ETL operations (e.g., append a delta to some target table, or create a surrogate key column etc.) * Build your own aggregate or analytic functions (e.g., string_agg, or a montlhy running total) * Express complex queries with Julius (equivalent to the WITH-clause in SQL) * and many more ... For any issues/problems with the DBFunctor package please open an issue on github. Happy data processing! Thank you. Best Regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudy at matela.com.br Wed Oct 17 00:26:06 2018 From: rudy at matela.com.br (Rudy Matela) Date: Tue, 16 Oct 2018 21:26:06 -0300 Subject: [Haskell-cafe] ANN: Extrapolate: generalized QuickCheck-style counterexamples. Message-ID: <20181017002606.GB2024@zero.localdomain> Hello Haskell-Café, A new version of Extrapolate is out: v0.3.5. Since the last announcement here improvements have been made in performance and stability. In addition, the IFL revised accepted paper is finally out (see end of the e-mail). For those who don't know Extrapolate, it is a property testing library capable of reporting generalized counterexamples to properties. Here is a simple example: $ ghci > import Test.Extrapolate > import Data.List (nub) > check $ \xs -> nub xs == (xs :: [Int]) *** Failed! Falsifiable (after 3 tests): [0,0] Generalization: x:x:_ Conditional Generalization: x:xs when elem x xs The above property not only fails for the list `[0,0]` but also for any list of the form `x:x:_`. This hints that the above property fails whenever the argument list has repeated elements. The above example is perhaps artificial: the property is obviously wrong! But it does illustrate what Extrapolate is able to produce: aside from the fully defined counterexample it reports a conjectured generalization with some parts of the counterexample replaced by variables or holes. Generalization is particularly helpful when dealing with bigger counterexamples. The following fully-defined counterexample to one of XMonad's properties StackSet { current = Screen { workspace = Workspace { tag = 0, layout = 0, stack = Just ( Stack { focus = 'a', up = "", down = "" } ) }, screen = 0, screenDetail = 0 }, visible = [], hidden = [], floating = fromList [] } is reported by Extrapolate alongside a much simpler generalization: StackSet (Screen (Workspace _ _ (Just _)) _ _) _ _ _ Full details for the above example are given in the research paper. Get Extrapolate with: $ cabal install extrapolate See the Haddock documentation and the project README for more details. I'm interested in input from the Haskell community about Extrapolate. Please let me know if it works (or not) for you. Links: * Research paper (link 1): https://matela.com.br/paper/extrapolate.pdf * Research paper (link 2): https://dl.acm.org/citation.cfm?id=3205371 * Hackage: https://hackage.haskell.org/package/extrapolate * GitHub: https://github.com/rudymatela/extrapolate Best Regards, Rudy From ben.franksen at online.de Fri Oct 19 07:19:35 2018 From: ben.franksen at online.de (Ben Franksen) Date: Fri, 19 Oct 2018 09:19:35 +0200 Subject: [Haskell-cafe] property testing with context Message-ID: Hi everyone it seems to be the season for new variations on the "property testing" theme, so I would like to chime in... not to announce a new library, sadly, but with a rough idea how the existing ones could perhaps be improved, based on practical experience in Darcs. The problem I have is that there is a tension between (a) stating a property in a clear and simple way, so its code doubles as a formal specification and (b) writing the property in such a way that when it fails, the reported value(s) give enough information about the context to be useful for finding the cause of the problem. Let me give an example to demonstrate what I mean. There is a simple law that says if a sequential pair of patches A;B commutes to B';A' then B';A' commutes back to A;B. In code this looks (more or less) like this: prop_recommute :: Commute p => (p :> p) wA wB -> Bool prop_recommute (x:>y) | Just (y':>x') <- commute (x:>y) = case commute (y':>x')of Just (x'':>y'') -> x==x'' && y==y'' Nothing -> False | otherwise = True This is a bit more verbose than the informal spec but still quite readable. Now suppose this property fails. So quickcheck reports the counter example pair (X:>Y) for some X and Y. But that isn't too useful in itself. We'd like to know a bit more: * did the second commute fail? * or did it succeed but x/=x'' or y/=y''? * and in the latter case, which of the two? So in practice our property code looks more like this: prop_recommute :: (ShowPatch p, Commute p) => (p :> p) wA wB -> Bool prop_recommute (x :> y) | Just (y' :> x') <- commute (x :> y) = case commute (y' :> x') of Nothing -> failed (redText "failed, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x') Just (x'' :> y'') -> if y'' /= y then failed (redText "y'' =/\\= y failed, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x' $$ redText "x''" $$ displayPatch x'' $$ redText ":> y''" $$ displayPatch y'') else if x'' /= x then failed (redText "x'' /= x, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x' $$ redText "x''" $$ displayPatch x'' $$ redText ":> y''" $$ displayPatch y'') else True | otherwise = True Now this code tells us exactly what went wrong when the property fails but it is ugly and repetitive and the additional code obscures the simple logical content. So this is no longer quite as suitable for a (human readable) formal spec. I wonder if displaying (1) all relevant contextual variables and (2) "where in the code it fails" could be automated away, somehow. I guess this is not trivial and may require syntactic analysis, so perhaps expecting a /library/ to solve the problem is unrealistic, except perhaps by using Template Haskell. I'd also go with a separate tool that extracts properties from a module and enriches them with code that displays the additional information. Tackling this problem might be an interesting theme for a master thesis... ;-) Cheers Ben From whosekiteneverfly at gmail.com Fri Oct 19 08:51:04 2018 From: whosekiteneverfly at gmail.com (Yuji Yamamoto) Date: Fri, 19 Oct 2018 17:51:04 +0900 Subject: [Haskell-cafe] Why is the Cabal User's Guide left outdated? Message-ID: Getting interested in the features since Cabal 2.2 (esp. common stanzas), I looked up with the User's Guide , which is (and should be) listed in the search result first, but can't find because the User's Guide is still about Cabal 2.0. Why is it left outdated? Actually User's Guide (HEAD) is kept updated, but it's hard to find, and can include some information too new to release. Thanks in advance. -- 山本悠滋 twitter: @igrep GitHub: https://github.com/igrep GitLab: https://gitlab.com/igrep Facebook: http://www.facebook.com/igrep Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Fri Oct 19 11:55:49 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 19 Oct 2018 20:55:49 +0900 Subject: [Haskell-cafe] Fwd: [Haskell] Help inform GHC's development priorities In-Reply-To: <87va5zjayf.fsf@smart-cactus.org> References: <87va5zjayf.fsf@smart-cactus.org> Message-ID: (It is sending to the correct address of haskell-cafe ML.) ---------- Forwarded message --------- From: Ben Gamari Date: Fri, Oct 19, 2018 at 4:45 AM Subject: [Haskell] Help inform GHC's development priorities To: GHC developers , , Haskell Cafe , GHC users < glasgow-haskell-users at haskell.org> tl;dr. Please a take a minute to express your thoughts on GHC's development priorities via this survey [1]. Hello everyone, The GHC developers want to ensure that we are working on problems that of most importance to you, the Haskell community. To this end we are surveying the community [1], asking how our users interact with GHC and which problems need to be addressed most urgently. We hope you will take a few minutes to give us your thoughts [1]. Thanks in advance for your time and, finally, thanks to the financial supporters that make our work GHC possible. Cheers, - Ben and the rest of the GHC developers [1] https://docs.google.com/forms/d/e/1FAIpQLSdh7sf2MqHoEmjt38r1cxCF-tV76OFCJqU6VabGzlOUKYqo-w/viewform _______________________________________________ Haskell mailing list Haskell at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmwpsh4C13+CdDZRjcVB86Evun78FAlvI4sgACgkQcVB86Evu n78/hwgA1bv/5NI5u4QQwoY181gA+9/YYa/y8Vd+bAjAvHi5cVMjQCwDqHsSoaZE rIN77I+bJ6Hn7krAAuLGQoyvQc9AF0EauJofz4zFhcqkTa5TEeb70gawBxFaLSYS igr2n16HHfLCv0aO31NRksObPnlkOWu791+9UVcWKNiHrU6KgJ/ck5T0Bz8+YRCT qgSs+jT8mbBLT48hXpKa4J8Jf4ILSbZv7yqqcKvCqj1xlnIlY/ebFvSbYXpxvcXS su6ajiro/MfSoXwFcObjteQMyzm9+4wlvPiWkPS9Y/G2mmx96tpkucrz2TQmi6Yd x3hokWZyqiD52C5niDe+9QILvA9Fow== =/4Ro -----END PGP SIGNATURE----- From mikhail.glushenkov at gmail.com Fri Oct 19 15:59:08 2018 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Fri, 19 Oct 2018 16:59:08 +0100 Subject: [Haskell-cafe] Why is the Cabal User's Guide left outdated? In-Reply-To: References: Message-ID: Hi, On Fri, 19 Oct 2018 at 09:51, Yuji Yamamoto wrote: > > Getting interested in the features since Cabal 2.2 (esp. common stanzas), > I looked up with the User's Guide, which is (and should be) listed in the search result first, but can't find because the User's Guide is still about Cabal 2.0. Sorry, it's my fault. I've updated https://www.haskell.org/cabal/release/latest/doc/users-guide/, but forgot to update https://www.haskell.org/cabal/users-guide/. Fixed now. From fis at etc-network.de Fri Oct 19 16:50:20 2018 From: fis at etc-network.de (Matthias Fischmann) Date: Fri, 19 Oct 2018 18:50:20 +0200 Subject: [Haskell-cafe] BOB - Call for Contributions 2019 Message-ID: <20181019165019.otku3j3tnglydakg@localhost.localdomain> Subject: Call for Contributions: BOB 2019 - Berlin, Mar 22, 2019 BOB Conference 2019 "What happens when we use what's best for a change?" http://bobkonf.de/2019/en/cfc.html Berlin, March 22 Call for Contributions Deadline: November 23, 2018 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Speaker Grants BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Shepherding The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - ... everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------- We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) Submit here: https://bobcfc.active-group.de/en/bob2019/cfp Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: November 23, 2018 - Notification: December 7, 2018 - Program: December 21, 2018 Program Committee ----------------- (more information here: http://bobkonf.de/2019/en/programmkomitee.html) - Matthias Fischmann, zerobuzz UG - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg From olf at aatal-apotheke.de Fri Oct 19 20:53:38 2018 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 19 Oct 2018 22:53:38 +0200 Subject: [Haskell-cafe] property testing with context Message-ID: Ben, the solution might be simple: Don't express the property as an atomic function (a -> Bool). This reminds me a bit of the Cutty-Howard correspondence, only that proofs are replaced by counterexamples. A testing library should have an operator for each of the logical connectives, where - a counterexample to True is never found - a counterexample to False is () - a counterexample to (not x) is an example for x - a counterexample to (x && y) is either a counterexample to x or a counterexample to y, whichever is found first - a counterexample to (x || y) is a pair of counterexamples to both x and y - a counterexample to (x ==> y) is an example for x together with a counterexample for y Then, if you build your property out of smaller properties and the connectives above, the counterexample-finder would be able to inform you which part of the property failed. I'm pretty sure at least one of the testing libraries has a system like this. Cheers, Olaf From rx at a-rx.info Fri Oct 19 21:02:12 2018 From: rx at a-rx.info (Andreas Reuleaux) Date: Fri, 19 Oct 2018 22:02:12 +0100 Subject: [Haskell-cafe] Well typed OS In-Reply-To: (Yotam Ohad's message of "Fri, 5 Oct 2018 07:36:45 +0300") References: Message-ID: <87tvlhbqgb.fsf@a-rx.info> While this may not be an answer to your specific question, you may want to have a look at MirageOS, the Operating System written in Ocaml by Anil Madhavapeddy el., https://mirage.io/ We had discussed this some while ago in our seminar, and I learned that Ocaml may be a better fit for writing an operating system than Haskell, due to Ocaml's ability to produce small binaries, smaller than Haskell binaries in any case usually. - Being involved with Haskell personally, I would like to be proven wrong, of course (ie. I would like to see small Haskell binaries), and I have heard of some former efforts of writing an OS in Haskell as well (but I would have to search for links). just my 2 cents, Andreas Yotam Ohad writes: > Hi, > In the last couple of days, I've been toying with the thought of an > operating system in which programs (or more accurately, any process) has a > distinct type which limits > its use of the machine. For example, `echo` (String -> String) won't be > able to print an output without a second program which would handle > changing stdout. > > I think it could "break down" the IO monad into other structures that are > better at specifying what is changing: A file is read / memory written / > etc. > I do, however, not sure how to incorporate drivers (which handles IO and > external devices) into this. Giving them an `IO a` type feels like > cheating. I would be much cooler if there was a way > to treat them like the `echo` function from earlier. > > What are your thoughts/suggestions? I'll be happy to hear them. > > Yotam > _______________________________________________ > 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 ollie at ocharles.org.uk Fri Oct 19 21:25:45 2018 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 19 Oct 2018 22:25:45 +0100 Subject: [Haskell-cafe] property testing with context In-Reply-To: References: Message-ID: Perhaps the work in my "assert-explainer" project is relevant here - https://github.com/ocharles/assert-explainer. The idea is your tests should just be writing "assert someArbitraryExpressionEvaluatingToBool", and then having some compiler magic recover the context for you when it goes wrong. To cite my own README: You write: assert (length xs == 4) No need for lots of special assertEqual etc functions. When the assertion fails, you will get much more context: ✘ Assertion failed! length xs == 4 /= True (at Test.hs:18:12-25) I found the following sub-expressions: - length xs = 3 - xs = [1,2,3] This is done via a GHC source plugin that rewrites "assert (length xs == 4)" into an expression that - if False - prints much more information. It's very early days for this plugin, but the goal is to reach parity with https://docs.pytest.org/en/latest/example/reportingdemo.html#tbreportdemo. Hope this helps, Ollie On Fri, Oct 19, 2018 at 8:20 AM Ben Franksen wrote: > > Hi everyone > > it seems to be the season for new variations on the "property testing" > theme, so I would like to chime in... not to announce a new library, > sadly, but with a rough idea how the existing ones could perhaps be > improved, based on practical experience in Darcs. > > The problem I have is that there is a tension between > > (a) stating a property in a clear and simple way, so its code doubles as > a formal specification > > and > > (b) writing the property in such a way that when it fails, the reported > value(s) give enough information about the context to be useful for > finding the cause of the problem. > > Let me give an example to demonstrate what I mean. > > There is a simple law that says if a sequential pair of patches A;B > commutes to B';A' then B';A' commutes back to A;B. In code this looks > (more or less) like this: > > prop_recommute :: Commute p => (p :> p) wA wB -> Bool > prop_recommute (x:>y) > | Just (y':>x') <- commute (x:>y) = > case commute (y':>x')of > Just (x'':>y'') -> x==x'' && y==y'' > Nothing -> False > | otherwise = True > > This is a bit more verbose than the informal spec but still quite readable. > > Now suppose this property fails. So quickcheck reports the counter > example pair (X:>Y) for some X and Y. But that isn't too useful in > itself. We'd like to know a bit more: > > * did the second commute fail? > * or did it succeed but x/=x'' or y/=y''? > * and in the latter case, which of the two? > > So in practice our property code looks more like this: > > prop_recommute :: (ShowPatch p, Commute p) => (p :> p) wA wB -> Bool > prop_recommute (x :> y) > | Just (y' :> x') <- commute (x :> y) = > case commute (y' :> x') of > Nothing -> > failed (redText "failed, where x" $$ displayPatch x $$ > redText ":> y" $$ displayPatch y $$ > redText "y'" $$ displayPatch y' $$ > redText ":> x'" $$ displayPatch x') > Just (x'' :> y'') -> > if y'' /= y > then > failed (redText "y'' =/\\= y failed, where x" $$ > displayPatch x $$ > redText ":> y" $$ displayPatch y $$ > redText "y'" $$ displayPatch y' $$ > redText ":> x'" $$ displayPatch x' $$ > redText "x''" $$ displayPatch x'' $$ > redText ":> y''" $$ displayPatch y'') > else > if x'' /= x > then > failed (redText "x'' /= x, where x" $$ > displayPatch x $$ > redText ":> y" $$ displayPatch y $$ > redText "y'" $$ displayPatch y' $$ > redText ":> x'" $$ displayPatch x' $$ > redText "x''" $$ displayPatch x'' $$ > redText ":> y''" $$ displayPatch y'') > else True > | otherwise = True > > Now this code tells us exactly what went wrong when the property fails > but it is ugly and repetitive and the additional code obscures the > simple logical content. So this is no longer quite as suitable for a > (human readable) formal spec. > > I wonder if displaying > > (1) all relevant contextual variables and > (2) "where in the code it fails" > > could be automated away, somehow. I guess this is not trivial and may > require syntactic analysis, so perhaps expecting a /library/ to solve > the problem is unrealistic, except perhaps by using Template Haskell. > I'd also go with a separate tool that extracts properties from a module > and enriches them with code that displays the additional information. > > Tackling this problem might be an interesting theme for a master > thesis... ;-) > > 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. From kitttoran at gmail.com Sat Oct 20 00:56:38 2018 From: kitttoran at gmail.com (Nikita Fufaev) Date: Sat, 20 Oct 2018 03:56:38 +0300 Subject: [Haskell-cafe] "Update Message-ID: -- Nikita Fufaev, +7 999 825-95-07 From vanessa.mchale at iohk.io Sat Oct 20 01:11:01 2018 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Fri, 19 Oct 2018 20:11:01 -0500 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <87tvlhbqgb.fsf@a-rx.info> References: <87tvlhbqgb.fsf@a-rx.info> Message-ID: <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> There's a lot of other stuff going on too, not just binary sizes - GHC's runtime, a dynamic memory allocator, etc. I would hesitate to use Haskell in the embedded context or for hardware-level stuff. I presume GHC's approach to laziness has a role in this. I don't have much experience with OCaml but my experience with ATS is that it's very much possible to have functional, ML-style programming without a runtime or even dynamic memory allocation. On 10/19/18 4:02 PM, Andreas Reuleaux wrote: > While this may not be an answer to your specific question, > you may want to have a look at MirageOS, the Operating System > written in Ocaml by Anil Madhavapeddy el., > https://mirage.io/ > > > We had discussed this some while ago in our seminar, > and I learned that Ocaml may be a better fit for > writing an operating system than Haskell, due to Ocaml's > ability to produce small binaries, smaller than Haskell > binaries in any case usually. - Being involved with > Haskell personally, I would like to be proven wrong, > of course (ie. I would like to see small Haskell binaries), > and I have heard of some former efforts of writing an OS in Haskell > as well (but I would have to search for links). > > > just my 2 cents, > Andreas > > > > > Yotam Ohad writes: > >> Hi, >> In the last couple of days, I've been toying with the thought of an >> operating system in which programs (or more accurately, any process) has a >> distinct type which limits >> its use of the machine. For example, `echo` (String -> String) won't be >> able to print an output without a second program which would handle >> changing stdout. >> >> I think it could "break down" the IO monad into other structures that are >> better at specifying what is changing: A file is read / memory written / >> etc. >> I do, however, not sure how to incorporate drivers (which handles IO and >> external devices) into this. Giving them an `IO a` type feels like >> cheating. I would be much cooler if there was a way >> to treat them like the `echo` function from earlier. >> >> What are your thoughts/suggestions? I'll be happy to hear them. >> >> Yotam >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From whosekiteneverfly at gmail.com Sat Oct 20 08:13:43 2018 From: whosekiteneverfly at gmail.com (Yuji Yamamoto) Date: Sat, 20 Oct 2018 17:13:43 +0900 Subject: [Haskell-cafe] Why is the Cabal User's Guide left outdated? In-Reply-To: References: Message-ID: Confirmed. Thanks a lot! 2018年10月20日(土) 0:59 Mikhail Glushenkov : > Hi, > On Fri, 19 Oct 2018 at 09:51, Yuji Yamamoto > wrote: > > > > Getting interested in the features since Cabal 2.2 (esp. common stanzas), > > I looked up with the User's Guide, which is (and should be) listed in > the search result first, but can't find because the User's Guide is still > about Cabal 2.0. > > Sorry, it's my fault. I've updated > https://www.haskell.org/cabal/release/latest/doc/users-guide/, but > forgot to update https://www.haskell.org/cabal/users-guide/. Fixed > now. > -- 山本悠滋 twitter: @igrep GitHub: https://github.com/igrep GitLab: https://gitlab.com/igrep Facebook: http://www.facebook.com/igrep Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Sat Oct 20 17:36:37 2018 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sat, 20 Oct 2018 12:36:37 -0500 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> Message-ID: I don't know whether this is helpful, but Purescript provides a way to specify the kinds of IO a monad can do. For instance, the Extensible Effects section[1] of Purescript by Example includes this code snippet: > :type main forall eff. Eff (console :: CONSOLE, random :: RANDOM | eff) Unit [1] https://leanpub.com/purescript/read#leanpub-auto-extensible-effects On Fri, Oct 19, 2018 at 8:11 PM Vanessa McHale wrote: > There's a lot of other stuff going on too, not just binary sizes - GHC's > runtime, a dynamic memory allocator, etc. I would hesitate to use > Haskell in the embedded context or for hardware-level stuff. I presume > GHC's approach to laziness has a role in this. > > I don't have much experience with OCaml but my experience with ATS is > that it's very much possible to have functional, ML-style programming > without a runtime or even dynamic memory allocation. > > On 10/19/18 4:02 PM, Andreas Reuleaux wrote: > > While this may not be an answer to your specific question, > > you may want to have a look at MirageOS, the Operating System > > written in Ocaml by Anil Madhavapeddy el., > > https://mirage.io/ > > > > > > We had discussed this some while ago in our seminar, > > and I learned that Ocaml may be a better fit for > > writing an operating system than Haskell, due to Ocaml's > > ability to produce small binaries, smaller than Haskell > > binaries in any case usually. - Being involved with > > Haskell personally, I would like to be proven wrong, > > of course (ie. I would like to see small Haskell binaries), > > and I have heard of some former efforts of writing an OS in Haskell > > as well (but I would have to search for links). > > > > > > just my 2 cents, > > Andreas > > > > > > > > > > Yotam Ohad writes: > > > >> Hi, > >> In the last couple of days, I've been toying with the thought of an > >> operating system in which programs (or more accurately, any process) > has a > >> distinct type which limits > >> its use of the machine. For example, `echo` (String -> String) won't be > >> able to print an output without a second program which would handle > >> changing stdout. > >> > >> I think it could "break down" the IO monad into other structures that > are > >> better at specifying what is changing: A file is read / memory written / > >> etc. > >> I do, however, not sure how to incorporate drivers (which handles IO and > >> external devices) into this. Giving them an `IO a` type feels like > >> cheating. I would be much cooler if there was a way > >> to treat them like the `echo` function from earlier. > >> > >> What are your thoughts/suggestions? I'll be happy to hear them. > >> > >> Yotam > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> To (un)subscribe, modify options or view archives go to: > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- 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 will.yager at gmail.com Sun Oct 21 02:52:12 2018 From: will.yager at gmail.com (Will Yager) Date: Sun, 21 Oct 2018 10:52:12 +0800 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> Message-ID: <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> > On Oct 20, 2018, at 09:11, Vanessa McHale wrote: > I would hesitate to use > Haskell in the embedded context or for hardware-level stuff. I presume > GHC's approach to laziness has a role in this. There’s a bit of a complication here. It’s true that standard GHC generated code is unsuitable for hard-real-time/embedded environments (although I would argue that it’s actually fine for general purpose OS programming). However, as far as hardware goes, the semantics of (a non-monomorphically-recursive subset of) Haskell is actually a surprisingly close match for the semantics of hardware (as in LUTs and flip-flops, not as in random microcontrollers). This is the basis of projects like Clash (Haskell to HDLs). I imagine one could extend the clash approach to generate allocation-free assembly from the same (large) subset of Haskell. > > I don't have much experience with OCaml but my experience with ATS is > that it's very much possible to have functional, ML-style programming > without a runtime or even dynamic memory allocation. >> It’s possible to write low-allocation (I wouldn’t call it “allocation free” - usually just the hot loops don’t allocate) OCaml with the standard tools. However, it requires a fairly non-idiomatic style. —Will From vanessa.mchale at iohk.io Sun Oct 21 03:13:12 2018 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Sat, 20 Oct 2018 22:13:12 -0500 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> Message-ID: Interesting! It's been awhile since I've worked on FPGAs :) ATS is the only language I've seen that advertises stack-allocated closures, and I think GHC's approach to laziness requires heap allocation, so there's still a few targets (AVR off the top of my head) that GHC would need significant modification to work on. On 10/20/18 9:52 PM, Will Yager wrote: > >> On Oct 20, 2018, at 09:11, Vanessa McHale wrote: >> I would hesitate to use >> Haskell in the embedded context or for hardware-level stuff. I presume >> GHC's approach to laziness has a role in this. > There’s a bit of a complication here. It’s true that standard GHC generated code is unsuitable for hard-real-time/embedded environments (although I would argue that it’s actually fine for general purpose OS programming). However, as far as hardware goes, the semantics of (a non-monomorphically-recursive subset of) Haskell is actually a surprisingly close match for the semantics of hardware (as in LUTs and flip-flops, not as in random microcontrollers). > > This is the basis of projects like Clash (Haskell to HDLs). I imagine one could extend the clash approach to generate allocation-free assembly from the same (large) subset of Haskell. > >> I don't have much experience with OCaml but my experience with ATS is >> that it's very much possible to have functional, ML-style programming >> without a runtime or even dynamic memory allocation. > It’s possible to write low-allocation (I wouldn’t call it “allocation free” - usually just the hot loops don’t allocate) OCaml with the standard tools. However, it requires a fairly non-idiomatic style. > > —Will > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From raould at gmail.com Sun Oct 21 03:17:53 2018 From: raould at gmail.com (Raoul Duke) Date: Sat, 20 Oct 2018 20:17:53 -0700 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> Message-ID: tower? atom? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sun Oct 21 07:04:27 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 21 Oct 2018 09:04:27 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> Message-ID: <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> Am 21.10.18 um 04:52 schrieb Will Yager: > > This is the basis of projects like Clash (Haskell to HDLs). I imagine one could extend the clash approach to generate allocation-free assembly from the same (large) subset of Haskell. Is that subset described somewhere? Regards, Jo From siddu.druid at gmail.com Sun Oct 21 07:59:33 2018 From: siddu.druid at gmail.com (Siddharth Bhat) Date: Sun, 21 Oct 2018 13:29:33 +0530 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> Message-ID: Kind of tangential, but bluespev verilog is a "Haskell inspired" version of verilog that has a strong Haskell flavour (typeclasses, purity, a rudimentary effect system that tracks combinational versus state based logic, clock domains embedded into the type, width polymorphic functions, etc). It's a really great way to see what a haskell-like-hardware description language could look like :) Cheers siddharth On Sun 21 Oct, 2018, 12:34 Joachim Durchholz, wrote: > Am 21.10.18 um 04:52 schrieb Will Yager: > > > > This is the basis of projects like Clash (Haskell to HDLs). I imagine > one could extend the clash approach to generate allocation-free assembly > from the same (large) subset of Haskell. > > Is that subset described somewhere? > > Regards, > Jo > _______________________________________________ > 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. -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Sun Oct 21 09:16:49 2018 From: will.yager at gmail.com (William Yager) Date: Sun, 21 Oct 2018 17:16:49 +0800 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> Message-ID: On Sun, Oct 21, 2018 at 3:04 PM Joachim Durchholz wrote: > > Is that subset described somewhere? > > So there are two possible answers to this: 1. The subset that Clash supports is a bit complicated and increases from time to time, depending mostly on the internal details of the clash compiler 2. The subset that Clash *could* support with (roughly) its current approach, which I think I can answer a bit better: I gave a brief hand-wavy description earlier - "non-monomorphically-recursive" That is, any recursion has to be unrolled at the hardware level, and monomorphically (i.e. normally) recursive functions cannot (generally) stop being unrolled after a finite number of iterations. Sure, you can sometimes use fancy tricks (an SMT solver or something) to prove termination, but these come with a number of other challenges. For hardware you want a small, concrete number of recursions, which leads to lots of complications (e.g. need for dependent types to relate input values and recursion depth). Much simpler is to simply disallow monomorphic recursion, and then you shift the work of proving finite recursion depth to the type level. There's then a simple (constructive) rule for proving termination and calculating the number of recursive calls. Given F :: * -> * f :: a = ... (f :: F a) ... used at some site ... f ... 0. let seen_types = ∅ 1. let t = the type of "f" 2. If t ∈ seen_types, fail - unbounded recursion 3. Add t to seen_types 4. Inline the definition of "f" 5. Goto 1, with any newly introduced call to "f" This construction inlines every recursive call, which gives you a hardware-friendly representation without recursion at the end. This also supports multiple recursion, like over a binary tree (important for efficient hardware). To give a concrete example of how this works, consider sum :: ∀ n . Vec n Int -> Int sum :: Vec 0 Int -> Int = \Empty -> 0 -- Non-recursive sum :: Vec (n+1) Int -> Int = \(hd:tl) -> hd + (sum :: Vec n Int -> Int) tl This function is polymorphically recursive and perfectly reasonable to instantiate in hardware. The rule above succeeds in synthesizing the "sum" function, but will reject monomorphically recursive functions like "sum :: [Int] -> Int" or functions that end up being monomorphically recursive through a few polymorphically recursive "layers". One downside of this approach is that if F is divergent (i.e. the type of "f" never cycles back on itself but it always changes), this will either hang the compiler or you have to have an upper bound on the allowed number of inlines. This is probably fine - if you're trying to represent a function with a huge recursion depth in hardware, your design sucks and will be slow anyway. Again, reiterating that Clash doesn't *actually* support the entire subset mentioned above. That is just what one *could* support with the same conceptual approach. Instead, Clash has a few hard-coded things that it knows how to recurse over, like fixed-length vectors. There are probably some errors in the above - I'm not an expert on the internals of the clash compiler and this is just a brain-dump of my vague thoughts on synthesis. --Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sun Oct 21 14:08:42 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 21 Oct 2018 16:08:42 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> Message-ID: <4d978b01-4326-ca6f-1a3b-10ba4f685178@durchholz.org> Am 21.10.18 um 11:16 schrieb William Yager: > 2. The subset that Clash *could* support with (roughly) its current > approach, which I think I can answer a bit better: Thanks - that's exactly what I was after. From vanessa.mchale at iohk.io Sun Oct 21 17:39:26 2018 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Sun, 21 Oct 2018 12:39:26 -0500 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> Message-ID: <33f66818-11d7-f311-40de-77f92b8421bc@iohk.io> Others know more than I but the gist of it is that you can compile functions to circuits. Haskell's functions are fundamentally different from C's functions (which are basically procedures that sometimes have a return value), but there's no reason you can't compile a non-strict function to a circuit. On 10/21/18 2:04 AM, Joachim Durchholz wrote: > Am 21.10.18 um 04:52 schrieb Will Yager: >> >> This is the basis of projects like Clash (Haskell to HDLs).  I >> imagine one could extend the clash approach to generate >> allocation-free assembly from the same (large) subset of Haskell. > > Is that subset described somewhere? > > Regards, > Jo > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From vanessa.mchale at iohk.io Sun Oct 21 17:43:26 2018 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Sun, 21 Oct 2018 12:43:26 -0500 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> Message-ID: <80cb05b5-758a-def4-62a7-ec7b13776267@iohk.io> I've never understood why functional (and in particular Haskell-influenced) approaches to hardware never took off. I suspect it was political (Haskell is too academic, etc.), or perhaps the companies using it are just quiet about it :) I think you could use monads for clock domains. Once something has a clocked input, its output will be clocked too - it fits well with the "lift anything unclocked to clocked, but once clocked it is *always* clocked". On 10/21/18 2:59 AM, Siddharth Bhat wrote: > Kind of tangential, but bluespev verilog is a "Haskell inspired" > version of verilog that has a strong Haskell flavour (typeclasses, > purity, a rudimentary effect system that tracks combinational versus > state based logic, clock domains embedded into the type, width > polymorphic functions, etc). > > It's a really great way to see what a haskell-like-hardware > description language could look like :) > > Cheers > siddharth > > On Sun 21 Oct, 2018, 12:34 Joachim Durchholz, > wrote: > > Am 21.10.18 um 04:52 schrieb Will Yager: > > > > This is the basis of projects like Clash (Haskell to HDLs).  I > imagine one could extend the clash approach to generate > allocation-free assembly from the same (large) subset of Haskell. > > Is that subset described somewhere? > > Regards, > Jo > _______________________________________________ > 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. > > -- > Sending this from my phone, please excuse any typos! > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From vanessa.mchale at iohk.io Sun Oct 21 17:48:29 2018 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Sun, 21 Oct 2018 12:48:29 -0500 Subject: [Haskell-cafe] Well typed OS In-Reply-To: References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> Message-ID: Anything that's tail recursive could be converted to a while loop and then clocked, no? You could for instance compile fact :: Int -> Int fact 0 = 1 fact n = n * fact (n - 1) to hardware even if it would not be a good idea. On 10/21/18 4:16 AM, William Yager wrote: > > > On Sun, Oct 21, 2018 at 3:04 PM Joachim Durchholz > wrote: > > > Is that subset described somewhere? > > > So there are two possible answers to this: > > 1. The subset that Clash supports is a bit complicated and increases > from time to time, depending mostly on the internal details of the > clash compiler > > 2. The subset that Clash *could* support with (roughly) its current > approach, which I think I can answer a bit better:  > > I gave a brief hand-wavy description earlier - > "non-monomorphically-recursive" > > That is, any recursion has to be unrolled at the hardware level, and > monomorphically (i.e. normally) recursive functions cannot (generally) > stop being unrolled after a finite number of iterations. Sure, you can > sometimes use fancy tricks (an SMT solver or something) to prove > termination, but these come with a number of other challenges. For > hardware you want a small, concrete number of recursions, which leads > to lots of complications (e.g. need for dependent types to relate > input values and recursion depth). > > Much simpler is to simply disallow monomorphic recursion, and then you > shift the work of proving finite recursion depth to the type level.  > > There's then a simple (constructive) rule for proving termination and > calculating the number of recursive calls. > > Given > > F :: * -> * > f :: a = ... (f :: F a) ... > > used at some site > > ... f ... > > 0. let seen_types = ∅ > 1. let t = the type of "f" > 2. If t ∈ seen_types, fail - unbounded recursion > 3. Add t to seen_types > 4. Inline the definition of "f" > 5. Goto 1, with any newly introduced call to "f" > > This construction inlines every recursive call, which gives you a > hardware-friendly representation without recursion at the end. This > also supports multiple recursion, like over a binary tree (important > for efficient hardware).  > > To give a concrete example of how this works, consider > > sum :: ∀ n . Vec n Int -> Int > sum :: Vec 0       Int -> Int = \Empty -> 0 -- Non-recursive > sum :: Vec (n+1) Int -> Int = \(hd:tl) -> hd + (sum :: Vec n Int -> > Int) tl > > This function is polymorphically recursive and perfectly reasonable to > instantiate in hardware. The rule above succeeds in synthesizing the > "sum" function, but will reject monomorphically recursive functions > like "sum :: [Int] -> Int" or functions that end up being > monomorphically recursive through a few polymorphically recursive > "layers". > > One downside of this approach is that if F is divergent (i.e. the type > of "f" never cycles back on itself but it always changes), this will > either hang the compiler or you have to have an upper bound on the > allowed number of inlines. This is probably fine - if you're trying to > represent a function with a huge recursion depth in hardware, your > design sucks and will be slow anyway. > > Again, reiterating that Clash doesn't *actually* support the entire > subset mentioned above. That is just what one *could* support with the > same conceptual approach. Instead, Clash has a few hard-coded things > that it knows how to recurse over, like fixed-length vectors. > > There are probably some errors in the above - I'm not an expert on the > internals of the clash compiler and this is just a brain-dump of my > vague thoughts on synthesis. > > --Will  > > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jo at durchholz.org Sun Oct 21 20:19:01 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 21 Oct 2018 22:19:01 +0200 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <80cb05b5-758a-def4-62a7-ec7b13776267@iohk.io> References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> <80cb05b5-758a-def4-62a7-ec7b13776267@iohk.io> Message-ID: <57b794d9-df62-9f17-ea53-c30a8a413ba0@durchholz.org> Am 21.10.18 um 19:43 schrieb Vanessa McHale: > I've never understood why functional (and in particular > Haskell-influenced) approaches to hardware never took off. I suspect it > was political (Haskell is too academic, etc.), or perhaps the companies > using it are just quiet about it :) The usual reason is that they simply haven't seen it work, and are not sure whether it will work. Also, retraining your engineers is VERY expensive: expect a few weeks of training, plus a few months of reduced effectivity; multiply with an engineer's cost per month, and you arrive at really impressive figures. If a company is successful, it sees no reason to go into that risk. If a company is at the brink of defaulting, it cannot afford to try. It's usually the second-in-line companies that try this kind of stuff, and only if they have some risk appetite and need/want to catch up. In these companies, there's room for experiment - but the experiment needs to show success to be adopted, which is by no means guaranteed (you can easily fail with a better methodology if you don't do it right). And maybe functional really isn't a good match for hardware. I don't expect that to be reality, but I have too little experience with functional and almost zero with hardware, so I may be overlooking stuff - the design space for hardware is pretty different than the design space for software, pretty restrictive in some ways and unexpectedly flexible in others. Which brings me to another possible reason: Maybe functional isn't solving any of the real problems in hardware design. That would then be the "meh, nice but useless" reaction. Just speculating about possibilities here; as I said: too little hardware design experience here. Regards, Jo From will.yager at gmail.com Mon Oct 22 01:58:26 2018 From: will.yager at gmail.com (Will Yager) Date: Mon, 22 Oct 2018 09:58:26 +0800 Subject: [Haskell-cafe] Well typed OS In-Reply-To: <80cb05b5-758a-def4-62a7-ec7b13776267@iohk.io> References: <87tvlhbqgb.fsf@a-rx.info> <9bdf44cd-3701-2fa5-7abb-bd3888ab8eab@iohk.io> <5BB333DE-1E67-474A-8AA0-43426357FBE2@gmail.com> <2a00b4fc-7489-7c24-67c0-4d69a5f15a97@durchholz.org> <80cb05b5-758a-def4-62a7-ec7b13776267@iohk.io> Message-ID: > On Oct 22, 2018, at 01:43, Vanessa McHale wrote: > > or perhaps the companies using it are just quiet about it :) > It’s this. There are some companies you’ve heard of who are using it quietly :) > Anything that's tail recursive could be converted to a while loop and then clocked, no? Yes, but the semantics of this are very different and the translation is much less straightforward (eg how many iterations will it take?). Better to do this “manually”, imo. Construct a mealy machine or something. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Mon Oct 22 08:07:34 2018 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Mon, 22 Oct 2018 03:07:34 -0500 Subject: [Haskell-cafe] (Sample) bioinformatics applications Message-ID: Hello, Do any of these beasts exist for reference? Regards, Vasily -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Mon Oct 22 08:57:49 2018 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Mon, 22 Oct 2018 04:57:49 -0400 Subject: [Haskell-cafe] ANN: Yampa-0.12 and yampa-test (QuickCheck-based FRP testing) Message-ID: Dear all, I am please to announce version 0.12 of Yampa! Yampa is a mature and robust FRP implementation that has been used to create mobile, desktop, and web games and applications, including commercial mobile games available on iTunes and Google Play, and open source games that use devices like wiimotes and kinect [1-2]. This version comes with an accompanying library, yampa-test, which includes QuickCheck-based testing with LTL-based signal predicates. These features are described in the ICFP 2017 paper "Testing and Debugging Functional Reactive Programming" [3]. Thanks to Christina Zeller for reporting bugs. Both libraries can be found here: http://hackage.haskell.org/package/Yampa http://hackage.haskell.org/package/yampa-test This version has been tested against all major GHC versions from 7.6 to 8.6. Some legacy code has been deprecated, which has triggered a major version bump (0.12). I would expect all projects that use Yampa to work by, at most, adapting the version constraints in the cabal files. New versions of Yampa will present a simpler API, better documentation and benchmarks [4]. As always, contributions are welcome. There are a number of issues on the github page that are particularly suitable for beginners [5]. Happy Haskelling! Ivan [1] https://github.com/ivanperez-keera/Yampa#other-examples [2] https://haskell.games [3] https://dl.acm.org/citation.cfm?id=3110246 [4] https://github.com/ivanperez-keera/Yampa/milestones [5] https://github.com/ivanperez-keera/Yampa/labels/help%20wanted From ben.franksen at online.de Mon Oct 22 09:22:53 2018 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 22 Oct 2018 11:22:53 +0200 Subject: [Haskell-cafe] property testing with context In-Reply-To: References: Message-ID: Hi Ollie This is fantastic! It's certainly much more than I hoped for. I haven't looked into the details of your plugin yet, but from your description it looks as if this is currently geared towards "classical" unit tests. Perhaps this is not a problem: I think quickcheck & co report exceptions as a failed property, and if they don't we'll just have to catch the exception, print it and return False. I will definitely try it out and report back. Cheers Ben Am 19.10.2018 um 23:25 schrieb Oliver Charles: > Perhaps the work in my "assert-explainer" project is relevant here - > https://github.com/ocharles/assert-explainer. > > The idea is your tests should just be writing "assert > someArbitraryExpressionEvaluatingToBool", and then having some > compiler magic recover the context for you when it goes wrong. To cite > my own README: > > > You write: > > assert (length xs == 4) > > No need for lots of special assertEqual etc functions. > > When the assertion fails, you will get much more context: > > ✘ Assertion failed! > length xs == 4 /= True (at Test.hs:18:12-25) > > I found the following sub-expressions: > - length xs = 3 > - xs = [1,2,3] > > > This is done via a GHC source plugin that rewrites "assert (length xs > == 4)" into an expression that - if False - prints much more > information. > > It's very early days for this plugin, but the goal is to reach parity > with https://docs.pytest.org/en/latest/example/reportingdemo.html#tbreportdemo. > > Hope this helps, > Ollie > On Fri, Oct 19, 2018 at 8:20 AM Ben Franksen wrote: >> >> Hi everyone >> >> it seems to be the season for new variations on the "property testing" >> theme, so I would like to chime in... not to announce a new library, >> sadly, but with a rough idea how the existing ones could perhaps be >> improved, based on practical experience in Darcs. >> >> The problem I have is that there is a tension between >> >> (a) stating a property in a clear and simple way, so its code doubles as >> a formal specification >> >> and >> >> (b) writing the property in such a way that when it fails, the reported >> value(s) give enough information about the context to be useful for >> finding the cause of the problem. >> >> Let me give an example to demonstrate what I mean. >> >> There is a simple law that says if a sequential pair of patches A;B >> commutes to B';A' then B';A' commutes back to A;B. In code this looks >> (more or less) like this: >> >> prop_recommute :: Commute p => (p :> p) wA wB -> Bool >> prop_recommute (x:>y) >> | Just (y':>x') <- commute (x:>y) = >> case commute (y':>x')of >> Just (x'':>y'') -> x==x'' && y==y'' >> Nothing -> False >> | otherwise = True >> >> This is a bit more verbose than the informal spec but still quite readable. >> >> Now suppose this property fails. So quickcheck reports the counter >> example pair (X:>Y) for some X and Y. But that isn't too useful in >> itself. We'd like to know a bit more: >> >> * did the second commute fail? >> * or did it succeed but x/=x'' or y/=y''? >> * and in the latter case, which of the two? >> >> So in practice our property code looks more like this: >> >> prop_recommute :: (ShowPatch p, Commute p) => (p :> p) wA wB -> Bool >> prop_recommute (x :> y) >> | Just (y' :> x') <- commute (x :> y) = >> case commute (y' :> x') of >> Nothing -> >> failed (redText "failed, where x" $$ displayPatch x $$ >> redText ":> y" $$ displayPatch y $$ >> redText "y'" $$ displayPatch y' $$ >> redText ":> x'" $$ displayPatch x') >> Just (x'' :> y'') -> >> if y'' /= y >> then >> failed (redText "y'' =/\\= y failed, where x" $$ >> displayPatch x $$ >> redText ":> y" $$ displayPatch y $$ >> redText "y'" $$ displayPatch y' $$ >> redText ":> x'" $$ displayPatch x' $$ >> redText "x''" $$ displayPatch x'' $$ >> redText ":> y''" $$ displayPatch y'') >> else >> if x'' /= x >> then >> failed (redText "x'' /= x, where x" $$ >> displayPatch x $$ >> redText ":> y" $$ displayPatch y $$ >> redText "y'" $$ displayPatch y' $$ >> redText ":> x'" $$ displayPatch x' $$ >> redText "x''" $$ displayPatch x'' $$ >> redText ":> y''" $$ displayPatch y'') >> else True >> | otherwise = True >> >> Now this code tells us exactly what went wrong when the property fails >> but it is ugly and repetitive and the additional code obscures the >> simple logical content. So this is no longer quite as suitable for a >> (human readable) formal spec. >> >> I wonder if displaying >> >> (1) all relevant contextual variables and >> (2) "where in the code it fails" >> >> could be automated away, somehow. I guess this is not trivial and may >> require syntactic analysis, so perhaps expecting a /library/ to solve >> the problem is unrealistic, except perhaps by using Template Haskell. >> I'd also go with a separate tool that extracts properties from a module >> and enriches them with code that displays the additional information. >> >> Tackling this problem might be an interesting theme for a master >> thesis... ;-) >> >> 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. > From arjenvanweelden at gmail.com Mon Oct 22 09:59:24 2018 From: arjenvanweelden at gmail.com (arjenvanweelden at gmail.com) Date: Mon, 22 Oct 2018 11:59:24 +0200 Subject: [Haskell-cafe] property testing with context In-Reply-To: References: Message-ID: <88af816cf0f8a1b149a686540752374e299e1204.camel@gmail.com> On Fri, 2018-10-19 at 09:19 +0200, Ben Franksen wrote: > Hi everyone > > it seems to be the season for new variations on the "property > testing" > theme, so I would like to chime in... not to announce a new library, > sadly, but with a rough idea how the existing ones could perhaps be > improved, based on practical experience in Darcs. > > The problem I have is that there is a tension between > > (a) stating a property in a clear and simple way, so its code doubles > as > a formal specification > > and > > (b) writing the property in such a way that when it fails, the > reported > value(s) give enough information about the context to be useful for > finding the cause of the problem. > > Let me give an example to demonstrate what I mean. > > There is a simple law that says if a sequential pair of patches A;B > commutes to B';A' then B';A' commutes back to A;B. In code this looks > (more or less) like this: > > prop_recommute :: Commute p => (p :> p) wA wB -> Bool > prop_recommute (x:>y) > | Just (y':>x') <- commute (x:>y) = > case commute (y':>x')of > Just (x'':>y'') -> x==x'' && y==y'' > Nothing -> False > | otherwise = True > > This is a bit more verbose than the informal spec but still quite > readable. > > Now suppose this property fails. So quickcheck reports the counter > example pair (X:>Y) for some X and Y. But that isn't too useful in > itself. We'd like to know a bit more: > > * did the second commute fail? > * or did it succeed but x/=x'' or y/=y''? > * and in the latter case, which of the two? I think that this is possible by simply using QuickCheck's === and ==> (if you have Show and Eq instances for :>): prop_recommute :: Commute p => (p :> p) wA wB -> Bool prop_recommute (x:>y) = isJust commuted ==> commute commuted === Just (x:>y) where commuted = commute (x:>y) See https://hackage.haskell.org/package/QuickCheck-2.11.3/docs/Test-QuickCheck-Property.html for information on ==> and ===. This is more readable and quite similar to your example above. It would print both left and right side of === when a counter-example is found. Depending on your implementation of Show for :>, it could look like: Nothing /= Just (...A... :> ...B...) or Just (...A... :> ...B...) /= Just (...C... :> ...D...). I did not try this myself, so I could have made a mistake or I may have missed why this is not good enough for your case. > So in practice our property code looks more like this: > > prop_recommute :: (ShowPatch p, Commute p) => (p :> p) wA wB -> Bool > prop_recommute (x :> y) > | Just (y' :> x') <- commute (x :> y) = > case commute (y' :> x') of > Nothing -> > failed (redText "failed, where x" $$ displayPatch x $$ > redText ":> y" $$ displayPatch y $$ > redText "y'" $$ displayPatch y' $$ > redText ":> x'" $$ displayPatch x') > Just (x'' :> y'') -> > if y'' /= y > then > failed (redText "y'' =/\\= y failed, where x" $$ > displayPatch x $$ > redText ":> y" $$ displayPatch y $$ > redText "y'" $$ displayPatch y' $$ > redText ":> x'" $$ displayPatch x' $$ > redText "x''" $$ displayPatch x'' $$ > redText ":> y''" $$ displayPatch y'') > else > if x'' /= x > then > failed (redText "x'' /= x, where x" $$ > displayPatch x $$ > redText ":> y" $$ displayPatch y $$ > redText "y'" $$ displayPatch y' $$ > redText ":> x'" $$ displayPatch x' $$ > redText "x''" $$ displayPatch x'' $$ > redText ":> y''" $$ displayPatch y'') > else True > | otherwise = True > > Now this code tells us exactly what went wrong when the property > fails > but it is ugly and repetitive and the additional code obscures the > simple logical content. So this is no longer quite as suitable for a > (human readable) formal spec. > > I wonder if displaying > > (1) all relevant contextual variables and > (2) "where in the code it fails" > > could be automated away, somehow. I guess this is not trivial and may > require syntactic analysis, so perhaps expecting a /library/ to solve > the problem is unrealistic, except perhaps by using Template Haskell. > I'd also go with a separate tool that extracts properties from a > module > and enriches them with code that displays the additional information. > > Tackling this problem might be an interesting theme for a master > thesis... ;-) > > 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. From ollie at ocharles.org.uk Mon Oct 22 21:42:48 2018 From: ollie at ocharles.org.uk (Oliver Charles) Date: Mon, 22 Oct 2018 22:42:48 +0100 Subject: [Haskell-cafe] property testing with context In-Reply-To: References: Message-ID: On Mon, Oct 22, 2018 at 10:23 AM Ben Franksen wrote: > > Hi Ollie > > This is fantastic! It's certainly much more than I hoped for. > > I haven't looked into the details of your plugin yet, but from your > description it looks as if this is currently geared towards "classical" > unit tests. Perhaps this is not a problem: I think quickcheck & co > report exceptions as a failed property, and if they don't we'll just > have to catch the exception, print it and return False. Yea, everything is very proof-of-concept at the moment. Right now, we have assert :: Bool -> IO (), but that could be changed to have a richer return type (and likely will as this project progresses). > I will definitely try it out and report back. Super, please feel free to open issues/questions on GitHub! From carlos.camarao at gmail.com Tue Oct 23 19:13:26 2018 From: carlos.camarao at gmail.com (Carlos Camarao) Date: Tue, 23 Oct 2018 16:13:26 -0300 Subject: [Haskell-cafe] Impossible types [was [Haskell-prime]: A question about run-time errors when class members are undefined] In-Reply-To: References: Message-ID: > Transferring from > https://mail.haskell.org/pipermail/haskell-prime/2018-October/004396.html >> On Sat, 13 Oct 2018 at 4:04 AM, wrote: >> Consider for example: >> >> class F a b where f:: a → b >> class X a where x:: a >> fx = f x >> >> The type of fx, (F a b, X a) ⇒ b, should not be ambiguous: in >> distinct contexts, fx can have distinct types (if ambiguity, and >> 'improvement', are as defined below). > [See the -prime message for the "defined below".] > I'm just not seeing why you think any Haskell should accept > that. What value could inhabit `fx` except bottom? The type of fx, (F a b, X a) ⇒ b, is a normal, constrained polymorphic type, in the proposal. When fx is used so that b is instantiated, type variable 'a' will become unreachable. Satisfiability will then be tested: if there is a single instance that satisfies the constraints with the unreachable type variables, these variables will be instantiated and the constrains removed ("type improvement"). For example: -----------A.hs------------------- module A (fx) where class F a b where f:: a -> b class X a where x:: a fx = f x ---------------------------------- ----------- M.hs ----------------- module M (inc) where import A (fx) instance F Int (Int->Int) where f = (+) instance X Int where x = 1 inc = fx ---------------------------------- You cannot define and use fx nowadays in Haskell, even if a functional dependency is inserted and ambiguous types are allowed, because no type improvement is used to instantiate unreachable variables, when unreachable type variables exist. Ok? > And indeed no Haskell does accept it, not even GHC with all sorts of > nasty extensions switched on, including `AllowAmbiguousTypes`. > GHC will accept class `F` with a Functional Dependency `b -> a`, but > still I can't 'poke' any value into the `x` argument to `f` in the > equation for `fx`. I hope things are clearer now. >> Note: agreeing with this view can lead to far-reaching consequences, e.g. support of >> overloaded record fields [1,Section 7], ... > There are other ways to support overloaded/duplicate record fields, Of course. > without doing this much violence to the type system. Look at the > `HasField` class using Functional Dependencies, in Adam Gundry's work. There is no violence to the type system, just simplification and clean-up. >> polymonads [2] etc. > Note that's from a Trac ticket asking for 'dysfunctional' Functional > Dependencies. There's a long discussion from the type-inference > brains trust coming to no discernable conclusion as to whether it's > broken type safety. (Catching incoherence in the Core lint > typecheck is not a good look.) > > a) You've not shown any detailed working of how your proposal gives the type improvement required > without also descending into incoherence. I don't know why you wonder about incoherence being a problem. > b) The combination of Functional Dependencies+Overlapping > Instances+Undecidable Instances might be able to cover just enough, > but not too much of the requirements (which were never made clear). > See my worked examples on that ticket -- some of which are really > quite scary. See some of Oleg's work on his ftp site with > multi-directional FunDeps and overlaps to achieve injectivity. To > try to tame the scariness while still supporting enough power, see > the suggestion here https://ghc.haskell.org/trac/ghc/ticket/15632 Perhaps you could select one or two examples for discussion. >> Further examples can be discussed > I have yet to see a convincing use case (from the very lengthy > discussions) which couldn't be handled already in GHC. I agree the > combination of extensions in GHC (including its bogus consistency > check/Trac #10675) can give alarming surprises; but they don't quite > break type safety. I think any example of use of any MPTC will be able to be handled, although perhaps differently, with the proposal. >> but this example conveys the main idea that ambiguity should be >> changed; unlike the example of (show . read), no type annotation >> can avoid ambiguity of polymorphic fx in current Haskell. > Since `fx` is not accepted in current Haskell, whether you can put a > type annotation seems beside the point. fx is accepted in the proposal, as well as (show . read). I thought it was a good example because it is small and illustrates that you cannot accept it and avoid changing the ambiguity rule by just inserting a type annotation. Kind regards, Carlos PS: I was away and couldn't see e-mails last week. On Sun, 14 Oct 2018 at 03:31, Anthony Clayden wrote: > Transferring from > https://mail.haskell.org/pipermail/haskell-prime/2018-October/004396.html > > On Sat, 13 Oct 2018 at 4:04 AM, wrote: > >> >> Consider for example: >> >> class F a b where f:: a → b >> class X a where x:: a >> fx = f x >> >> The type of fx, (F a b, X a) ⇒ b, should not be ambiguous: in >> distinct contexts, fx can have distinct types (if ambiguity, and >> 'improvement', are as defined below). > > > [See the -prime message for the "defined below".] > > > I'm just not seeing why you think any Haskell should accept that. What > value could inhabit `fx` except bottom? > > And indeed no Haskell does accept it, not even GHC with all sorts of nasty > extensions switched on, including `AllowAmbiguousTypes`. > > GHC will accept class `F` with a Functional Dependency `b -> a`, but still > I can't 'poke' any value into the `x` argument to `f` in the equation for > `fx`. > > > Note: agreeing with this view can lead to far-reaching consequences, e.g. >> support of >> overloaded record fields [1,Section 7], ... > > > There are other ways to support overloaded/duplicate record fields, > without doing this much violence to the type system. Look at the `HasField` > class using Functional Dependencies, in Adam Gundry's work. > > > polymonads [2] etc. >> > > Note that's from a Trac ticket asking for 'dysfunctional' Functional > Dependencies. There's a long discussion from the type-inference brains > trust coming to no discernable conclusion as to whether it's broken type > safety. (Catching incoherence in the Core lint typecheck is not a good > look.) > > a) You've not shown any detailed working of how your proposal gives the > type improvement required > without also descending into incoherence. > > b) The combination of Functional Dependencies+Overlapping > Instances+Undecidable Instances might be able to cover just enough, > but not too much of the requirements (which were never made clear). > See my worked examples on that ticket -- some of which are really quite > scary. > See some of Oleg's work on his ftp site with multi-directional FunDeps > and overlaps to achieve injectivity. > To try to tame the scariness while still supporting enough power, see > the suggestion here > https://ghc.haskell.org/trac/ghc/ticket/15632 > > > >> Further examples can be discussed > > > I have yet to see a convincing use case (from the very lengthy > discussions) which couldn't be handled already in GHC. I agree the > combination of extensions in GHC (including its bogus consistency > check/Trac #10675) can give alarming surprises; but they don't quite break > type safety. > > > > but this example conveys the >> main idea that ambiguity should be changed; unlike the example >> of (show . read), no type annotation can avoid ambiguity of >> polymorphic fx in current Haskell. > > > Since `fx` is not accepted in current Haskell, whether you can put a type > annotation seems beside the point. > > > AntC > > [1] Optional Type Classes for Haskell, > Rodrigo Ribeiro, Carlos Camarão, Lucília Figueiredo, Cristiano > Vasconcellos, > SBLP'2016 (20th Brazilian Symposium on Programming Languages), > Marília, SP, September 19-23, 2016. > > [2] https://github.com/carlos1camarao/ghc-proposals/blob/d81c1f26298961ac635ce0724bb76164b418866b/expression-ambiguity.rst > > > _______________________________________________ > 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 ben.franksen at online.de Wed Oct 24 06:31:45 2018 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 24 Oct 2018 08:31:45 +0200 Subject: [Haskell-cafe] property testing with context In-Reply-To: <88af816cf0f8a1b149a686540752374e299e1204.camel@gmail.com> References: <88af816cf0f8a1b149a686540752374e299e1204.camel@gmail.com> Message-ID: Am 22.10.2018 um 11:59 schrieb arjenvanweelden at gmail.com: > I think that this is possible by simply using QuickCheck's === and ==> > (if you have Show and Eq instances for :>): > > prop_recommute :: Commute p => (p :> p) wA wB -> Bool > prop_recommute (x:>y) > = isJust commuted ==> commute commuted === Just (x:>y) > where > commuted = commute (x:>y) > > See > https://hackage.haskell.org/package/QuickCheck-2.11.3/docs/Test-QuickCheck-Property.html > for information on ==> and ===. > > This is more readable and quite similar to your example above. It would > print both left and right side of === when a counter-example is found. Thanks for the hint wrt (===) which I wasn't aware of. In the example I posted this would work, but not in more complex ones. There are properties that get more patches as input and require many combinations of e.g. commute to succeed. Any one of them can fail and the rest can only be performed if the previous ones have succeeded. Cheers Ben From ben.franksen at online.de Wed Oct 24 07:44:48 2018 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 24 Oct 2018 09:44:48 +0200 Subject: [Haskell-cafe] property testing with context In-Reply-To: References: Message-ID: Am 19.10.2018 um 22:53 schrieb Olaf Klinke: > the solution might be simple: Don't express the property as an atomic > function (a -> Bool). This reminds me a bit of the Cutty-Howard > correspondence, only that proofs are replaced by counterexamples. A > testing library should have an operator for each of the logical > connectives, where > > - a counterexample to True is never found > - a counterexample to False is () > - a counterexample to (not x) is an example for x > - a counterexample to (x && y) is either a counterexample to x or a counterexample to y, whichever is found first > - a counterexample to (x || y) is a pair of counterexamples to both x and y > - a counterexample to (x ==> y) is an example for x together with a counterexample for y > > Then, if you build your property out of smaller properties and the connectives above, the counterexample-finder would be able to inform you which part of the property failed. I'm pretty sure at least one of the testing libraries has a system like this. > Hi Olaf while this approach works in principle it has practical disadvantages. One charming feature of property testing in Haskell is that expressing properties does normally /not/ require to import the testing library. This allows me to write my properties in a generic style that works with e.g. quickcheck, leancheck, smallcheck etc. With your approach I would be tied to a single property testing library. I guess this would be less of a problem if in Haskell the boolean operators were overloaded i.e. part of a class. I think this was an oversight when the Prelude and the standard libraries were designed. IME boolean algebras (or perhaps more generally lattices) appear /everywhere/. I can't count the number of times I wanted to use these operators on structures containing Bools or functions returning Bool and couldn't. IMHO such a generalization would be a lot more useful and less controversial than the one from List to Foldable. (I can't remember a single instance where I missed this generalization of lists. In fact I think is completely useless. Foldable essentially allows me to say: "give me all your elements, one by one, in /your/ preferred order, so I can combine them to something new". Due to the laziness of lists this is really the same as having a toList function (modulo list fusion to take care of the constant factor overhead). Only that a container type may offer many different versions of toList but only a single Foldable instance. I understand that foldr and foldl have been added to the class to allow at least two different "preferred" traversal orders, but adding methods to a class in this way obviously doesn't scale and is poor design, again IMHO.) Cheers Ben From ben.franksen at online.de Wed Oct 24 07:44:48 2018 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 24 Oct 2018 09:44:48 +0200 Subject: [Haskell-cafe] property testing with context In-Reply-To: References: Message-ID: Am 19.10.2018 um 22:53 schrieb Olaf Klinke: > the solution might be simple: Don't express the property as an atomic > function (a -> Bool). This reminds me a bit of the Cutty-Howard > correspondence, only that proofs are replaced by counterexamples. A > testing library should have an operator for each of the logical > connectives, where > > - a counterexample to True is never found > - a counterexample to False is () > - a counterexample to (not x) is an example for x > - a counterexample to (x && y) is either a counterexample to x or a counterexample to y, whichever is found first > - a counterexample to (x || y) is a pair of counterexamples to both x and y > - a counterexample to (x ==> y) is an example for x together with a counterexample for y > > Then, if you build your property out of smaller properties and the connectives above, the counterexample-finder would be able to inform you which part of the property failed. I'm pretty sure at least one of the testing libraries has a system like this. > Hi Olaf while this approach works in principle it has practical disadvantages. One charming feature of property testing in Haskell is that expressing properties does normally /not/ require to import the testing library. This allows me to write my properties in a generic style that works with e.g. quickcheck, leancheck, smallcheck etc. With your approach I would be tied to a single property testing library. I guess this would be less of a problem if in Haskell the boolean operators were overloaded i.e. part of a class. I think this was an oversight when the Prelude and the standard libraries were designed. IME boolean algebras (or perhaps more generally lattices) appear /everywhere/. I can't count the number of times I wanted to use these operators on structures containing Bools or functions returning Bool and couldn't. IMHO such a generalization would be a lot more useful and less controversial than the one from List to Foldable. (I can't remember a single instance where I missed this generalization of lists. In fact I think is completely useless. Foldable essentially allows me to say: "give me all your elements, one by one, in /your/ preferred order, so I can combine them to something new". Due to the laziness of lists this is really the same as having a toList function (modulo list fusion to take care of the constant factor overhead). Only that a container type may offer many different versions of toList but only a single Foldable instance. I understand that foldr and foldl have been added to the class to allow at least two different "preferred" traversal orders, but adding methods to a class in this way obviously doesn't scale and is poor design, again IMHO.) Cheers Ben From amindfv at gmail.com Wed Oct 24 13:44:23 2018 From: amindfv at gmail.com (amindfv at gmail.com) Date: Wed, 24 Oct 2018 09:44:23 -0400 Subject: [Haskell-cafe] property testing with context In-Reply-To: <88af816cf0f8a1b149a686540752374e299e1204.camel@gmail.com> References: <88af816cf0f8a1b149a686540752374e299e1204.camel@gmail.com> Message-ID: <5512390F-174B-4003-BF25-B5D33F855FD6@gmail.com> Agreed, I think QuickCheck is already up to the task. The simpler prop_recommute could be rewritten with (===), (.&&.), and maybe "counterexample" to label which branch failed. Tom > El 22 oct 2018, a las 05:59, arjenvanweelden at gmail.com escribió: > >> On Fri, 2018-10-19 at 09:19 +0200, Ben Franksen wrote: >> Hi everyone >> >> it seems to be the season for new variations on the "property >> testing" >> theme, so I would like to chime in... not to announce a new library, >> sadly, but with a rough idea how the existing ones could perhaps be >> improved, based on practical experience in Darcs. >> >> The problem I have is that there is a tension between >> >> (a) stating a property in a clear and simple way, so its code doubles >> as >> a formal specification >> >> and >> >> (b) writing the property in such a way that when it fails, the >> reported >> value(s) give enough information about the context to be useful for >> finding the cause of the problem. >> >> Let me give an example to demonstrate what I mean. >> >> There is a simple law that says if a sequential pair of patches A;B >> commutes to B';A' then B';A' commutes back to A;B. In code this looks >> (more or less) like this: >> >> prop_recommute :: Commute p => (p :> p) wA wB -> Bool >> prop_recommute (x:>y) >> | Just (y':>x') <- commute (x:>y) = >> case commute (y':>x')of >> Just (x'':>y'') -> x==x'' && y==y'' >> Nothing -> False >> | otherwise = True >> >> This is a bit more verbose than the informal spec but still quite >> readable. >> >> Now suppose this property fails. So quickcheck reports the counter >> example pair (X:>Y) for some X and Y. But that isn't too useful in >> itself. We'd like to know a bit more: >> >> * did the second commute fail? >> * or did it succeed but x/=x'' or y/=y''? >> * and in the latter case, which of the two? > > I think that this is possible by simply using QuickCheck's === and ==> > (if you have Show and Eq instances for :>): > > prop_recommute :: Commute p => (p :> p) wA wB -> Bool > prop_recommute (x:>y) > = isJust commuted ==> commute commuted === Just (x:>y) > where > commuted = commute (x:>y) > > See > https://hackage.haskell.org/package/QuickCheck-2.11.3/docs/Test-QuickCheck-Property.html > for information on ==> and ===. > > This is more readable and quite similar to your example above. It would > print both left and right side of === when a counter-example is found. > > Depending on your implementation of Show for :>, it could look > like: Nothing /= Just (...A... :> ...B...) or Just (...A... :> ...B...) > /= Just (...C... :> ...D...). > > I did not try this myself, so I could have made a mistake or I may have > missed why this is not good enough for your case. > >> So in practice our property code looks more like this: >> >> prop_recommute :: (ShowPatch p, Commute p) => (p :> p) wA wB -> Bool >> prop_recommute (x :> y) >> | Just (y' :> x') <- commute (x :> y) = >> case commute (y' :> x') of >> Nothing -> >> failed (redText "failed, where x" $$ displayPatch x $$ >> redText ":> y" $$ displayPatch y $$ >> redText "y'" $$ displayPatch y' $$ >> redText ":> x'" $$ displayPatch x') >> Just (x'' :> y'') -> >> if y'' /= y >> then >> failed (redText "y'' =/\\= y failed, where x" $$ >> displayPatch x $$ >> redText ":> y" $$ displayPatch y $$ >> redText "y'" $$ displayPatch y' $$ >> redText ":> x'" $$ displayPatch x' $$ >> redText "x''" $$ displayPatch x'' $$ >> redText ":> y''" $$ displayPatch y'') >> else >> if x'' /= x >> then >> failed (redText "x'' /= x, where x" $$ >> displayPatch x $$ >> redText ":> y" $$ displayPatch y $$ >> redText "y'" $$ displayPatch y' $$ >> redText ":> x'" $$ displayPatch x' $$ >> redText "x''" $$ displayPatch x'' $$ >> redText ":> y''" $$ displayPatch y'') >> else True >> | otherwise = True >> >> Now this code tells us exactly what went wrong when the property >> fails >> but it is ugly and repetitive and the additional code obscures the >> simple logical content. So this is no longer quite as suitable for a >> (human readable) formal spec. >> >> I wonder if displaying >> >> (1) all relevant contextual variables and >> (2) "where in the code it fails" >> >> could be automated away, somehow. I guess this is not trivial and may >> require syntactic analysis, so perhaps expecting a /library/ to solve >> the problem is unrealistic, except perhaps by using Template Haskell. >> I'd also go with a separate tool that extracts properties from a >> module >> and enriches them with code that displays the additional information. >> >> Tackling this problem might be an interesting theme for a master >> thesis... ;-) >> >> 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. From HaskellCafe at solipsys.co.uk Wed Oct 24 14:41:11 2018 From: HaskellCafe at solipsys.co.uk (Rider of Giraffes) Date: Wed, 24 Oct 2018 14:41:11 BST Subject: [Haskell-cafe] Has twidge stopped working? Message-ID: <20181024132701.0A0C7BC8C6@haskell.org> Greetings, New on the list, apologies if I break any traditions. Sent here from https://github.com/jgoerzen/twidge/wiki with the question in the header. I sent a tweet via twidge on Oct 22, but since then nothing has got through. Has twidge stopped working? Has Twitter made yet another change to the API, this one incompatible? All assistance and advice welcome. Thank you. -- I don't suffer from stress - I'm a carrier. From simon.jakobi at googlemail.com Wed Oct 24 14:43:21 2018 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Wed, 24 Oct 2018 16:43:21 +0200 Subject: [Haskell-cafe] Has twidge stopped working? In-Reply-To: <20181024132701.0A0C7BC8C6@haskell.org> References: <20181024132701.0A0C7BC8C6@haskell.org> Message-ID: Hi! I'd suggest that you open an issue on twidge's issue tracker: https://github.com/jgoerzen/twidge/issues Cheers, Simon Am Mi., 24. Okt. 2018 um 16:11 Uhr schrieb Rider of Giraffes < HaskellCafe at solipsys.co.uk>: > Greetings, > > New on the list, apologies if I break any traditions. > Sent here from https://github.com/jgoerzen/twidge/wiki > with the question in the header. > > I sent a tweet via twidge on Oct 22, but since then > nothing has got through. Has twidge stopped working? > Has Twitter made yet another change to the API, this > one incompatible? > > All assistance and advice welcome. > > Thank you. > > -- > I don't suffer from stress - I'm a carrier. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Oct 24 20:51:31 2018 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 24 Oct 2018 21:51:31 +0100 Subject: [Haskell-cafe] property testing with context In-Reply-To: <5512390F-174B-4003-BF25-B5D33F855FD6@gmail.com> References: <88af816cf0f8a1b149a686540752374e299e1204.camel@gmail.com> <5512390F-174B-4003-BF25-B5D33F855FD6@gmail.com> Message-ID: I agree with Ben's point though that you have to "buy in" to the testing framework and write tests in a DSL, though. This seems unfortunate. On Wed, 24 Oct 2018, 2:44 pm , wrote: > Agreed, I think QuickCheck is already up to the task. The simpler > prop_recommute could be rewritten with (===), (.&&.), and maybe > "counterexample" to label which branch failed. > > Tom > > > El 22 oct 2018, a las 05:59, arjenvanweelden at gmail.com escribió: > > > >> On Fri, 2018-10-19 at 09:19 +0200, Ben Franksen wrote: > >> Hi everyone > >> > >> it seems to be the season for new variations on the "property > >> testing" > >> theme, so I would like to chime in... not to announce a new library, > >> sadly, but with a rough idea how the existing ones could perhaps be > >> improved, based on practical experience in Darcs. > >> > >> The problem I have is that there is a tension between > >> > >> (a) stating a property in a clear and simple way, so its code doubles > >> as > >> a formal specification > >> > >> and > >> > >> (b) writing the property in such a way that when it fails, the > >> reported > >> value(s) give enough information about the context to be useful for > >> finding the cause of the problem. > >> > >> Let me give an example to demonstrate what I mean. > >> > >> There is a simple law that says if a sequential pair of patches A;B > >> commutes to B';A' then B';A' commutes back to A;B. In code this looks > >> (more or less) like this: > >> > >> prop_recommute :: Commute p => (p :> p) wA wB -> Bool > >> prop_recommute (x:>y) > >> | Just (y':>x') <- commute (x:>y) = > >> case commute (y':>x')of > >> Just (x'':>y'') -> x==x'' && y==y'' > >> Nothing -> False > >> | otherwise = True > >> > >> This is a bit more verbose than the informal spec but still quite > >> readable. > >> > >> Now suppose this property fails. So quickcheck reports the counter > >> example pair (X:>Y) for some X and Y. But that isn't too useful in > >> itself. We'd like to know a bit more: > >> > >> * did the second commute fail? > >> * or did it succeed but x/=x'' or y/=y''? > >> * and in the latter case, which of the two? > > > > I think that this is possible by simply using QuickCheck's === and ==> > > (if you have Show and Eq instances for :>): > > > > prop_recommute :: Commute p => (p :> p) wA wB -> Bool > > prop_recommute (x:>y) > > = isJust commuted ==> commute commuted === Just (x:>y) > > where > > commuted = commute (x:>y) > > > > See > > > https://hackage.haskell.org/package/QuickCheck-2.11.3/docs/Test-QuickCheck-Property.html > > for information on ==> and ===. > > > > This is more readable and quite similar to your example above. It would > > print both left and right side of === when a counter-example is found. > > > > Depending on your implementation of Show for :>, it could look > > like: Nothing /= Just (...A... :> ...B...) or Just (...A... :> ...B...) > > /= Just (...C... :> ...D...). > > > > I did not try this myself, so I could have made a mistake or I may have > > missed why this is not good enough for your case. > > > >> So in practice our property code looks more like this: > >> > >> prop_recommute :: (ShowPatch p, Commute p) => (p :> p) wA wB -> Bool > >> prop_recommute (x :> y) > >> | Just (y' :> x') <- commute (x :> y) = > >> case commute (y' :> x') of > >> Nothing -> > >> failed (redText "failed, where x" $$ displayPatch x $$ > >> redText ":> y" $$ displayPatch y $$ > >> redText "y'" $$ displayPatch y' $$ > >> redText ":> x'" $$ displayPatch x') > >> Just (x'' :> y'') -> > >> if y'' /= y > >> then > >> failed (redText "y'' =/\\= y failed, where x" $$ > >> displayPatch x $$ > >> redText ":> y" $$ displayPatch y $$ > >> redText "y'" $$ displayPatch y' $$ > >> redText ":> x'" $$ displayPatch x' $$ > >> redText "x''" $$ displayPatch x'' $$ > >> redText ":> y''" $$ displayPatch y'') > >> else > >> if x'' /= x > >> then > >> failed (redText "x'' /= x, where x" $$ > >> displayPatch x $$ > >> redText ":> y" $$ displayPatch y $$ > >> redText "y'" $$ displayPatch y' $$ > >> redText ":> x'" $$ displayPatch x' $$ > >> redText "x''" $$ displayPatch x'' $$ > >> redText ":> y''" $$ displayPatch y'') > >> else True > >> | otherwise = True > >> > >> Now this code tells us exactly what went wrong when the property > >> fails > >> but it is ugly and repetitive and the additional code obscures the > >> simple logical content. So this is no longer quite as suitable for a > >> (human readable) formal spec. > >> > >> I wonder if displaying > >> > >> (1) all relevant contextual variables and > >> (2) "where in the code it fails" > >> > >> could be automated away, somehow. I guess this is not trivial and may > >> require syntactic analysis, so perhaps expecting a /library/ to solve > >> the problem is unrealistic, except perhaps by using Template Haskell. > >> I'd also go with a separate tool that extracts properties from a > >> module > >> and enriches them with code that displays the additional information. > >> > >> Tackling this problem might be an interesting theme for a master > >> thesis... ;-) > >> > >> 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. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Thu Oct 25 05:45:16 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Thu, 25 Oct 2018 18:45:16 +1300 Subject: [Haskell-cafe] Impossible types [was [Haskell-prime]: A question about run-time errors when class members are undefined] In-Reply-To: References: Message-ID: On Wed, 24 Oct 2018 at 8:20 AM, Carlos Camarao wrote: > > Transferring from > > > https://mail.haskell.org/pipermail/haskell-prime/2018-October/004396.html > Carlos, the more I dig into your proposal/the more answers you provide, then the more crazy it's getting. I'll stop after explaining why I say that. I'm absolutely sure I don't want this. SPJ hasn't amplified his "interesting work" comment. You've not indicated if your papers have been peer reviewed nor who by. So in the absence of any independent corroboration, my judgment is there is nothing of merit worth pursuing further. GHC's current combo of FunDeps+Overlap+UndecidableInstances has its problems. That's why I'm always willing to look at alternatives. But not this crazy. > >> On Sat, 13 Oct 2018 at 4:04 AM, wrote: > >> Consider for example: > >> > >> class F a b where f:: a → b > >> class X a where x:: a > >> fx = f x > >> > >> The type of fx, (F a b, X a) ⇒ b, should not be ambiguous: in > >> distinct contexts, fx can have distinct types (if ambiguity, > and > >> 'improvement', are as defined below). > > > [See the -prime message for the "defined below".] > > I'm just not seeing why you think any Haskell should accept > > that. What value could inhabit `fx` except bottom? > > The type of fx, (F a b, X a) ⇒ b, is a normal, constrained polymorphic > type, in the proposal. When fx is used so that b is instantiated, type > variable 'a' will become unreachable. > Wait ... what? Instantiating a type variable changes some other type variable from reachable to unreachable? I'm already struggling to keep up with your definitions, which are different to GHC's definitions. Type improvement (i.e. instantiating type variables) is supposed to be monotonic: how can it a) affect other type variables that weren't even mentioned in the type assignment; b) have an effect on them opposite of improvement? Satisfiability will then be tested: if there is a single instance that > satisfies the constraints > You mean: a single instance in scope. So it's not just that you think scoped instances are a Good Thing (I disagree, for reasons of type safety); You require scoped instances so that there's only one instance visible. What's worse, there's no way to declare for class F that var a is reached from b, as a way to make sure there's only one suitable instance. So I think that means for the (show . read) example that I need to hide all of the Prelude instances, except the one I want for piggy in the middle. with the unreachable type variables, these variables will be > instantiated and the constrains removed ("type improvement"). > > For example: > > -----------A.hs------------------- > module A (fx) where > class F a b where f:: a -> b > class X a where x:: a > > fx = f x > ---------------------------------- > > ----------- M.hs ----------------- > module M (inc) where > import A (fx) > instance F Int (Int->Int) > where f = (+) > instance X Int where x = 1 > inc = fx > ---------------------------------- > > You cannot define and use fx nowadays in Haskell, even if a functional > dependency is inserted and ambiguous types are allowed, because no > type improvement is used to instantiate unreachable variables, when > unreachable type variables exist. Ok? > I am very Ok with how Haskell works. Its definition of 'unreachable' relates to FunDeps. You are now trying to explain Haskell using a different definition of 'unreachable'. I think that's bogus. ... > > I don't know why you wonder about incoherence being a problem. > I don't know why you think anything you've said shows anything about incoherence. You've given an example with only one instance. Then it's not going to be incoherent with itself. (The discussion I elided was about the polymonads example, for which you've given no solution. Are you again going to require there be only one Monad instance in scope? Is that going to be one instance per module, or at a finer grain? A polymonad combines two Monads to return a third; won't that require at least two pairings in scope?) Coherence is a property of the whole program axiomatisation. I.e. all instances for all classes and constraints. ... > > Perhaps you could select one or two examples for discussion. > No, the onus is on you to show you are providing equivalent expressivity to what's long been stable in Haskell (GHC and Hugs). And then you have to show you're providing something that improves on it/addresses its difficulties. Let's see a detailed working for polymonads. All we have so far is hand-waving. ... ambiguity rule ... > Again, you're using a different definition of "ambiguity", as compared with GHC's `AllowAmbiguousTypes` extension. No wonder it's so hard to follow what you're claiming. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.redelings at gmail.com Thu Oct 25 14:43:08 2018 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Thu, 25 Oct 2018 10:43:08 -0400 Subject: [Haskell-cafe] mfix for a nested monad Message-ID: <3d5d8600-7313-e75e-4ae8-526a62fd7737@gmail.com> Hi, I'm trying to implement mfix for a monad that is nested inside another monad.  I came up with the following logic for how to implement this, but I suspect there are some things I'm missing. My conclusion is that I want interpret (MFix f) = mfix (interpret.f) Does this seem right?  Has this situation been discussed somewhere? -BenRI P.S. Here's what I mean by the monad being nested in another monad.  Let's say that the monad M2 has interpreter i2, with type i2 :: M2 a -> M1 a and then M1 is the other monad, and has interpreter i1: i1 :: M1a -> a I suppose that the nesting is really a nesting of interpreters. P.P.S. I came up with some equational reasoning for how to treat mfix in the i2 interpreter. (a) For some interpreters `i`, it makes sense to require     i (mfix f) = let x = (i . f) x in x (b) I want the composition of interpreters (i1.i2) to act like (a) above:     (i1 . i2) (mfix f) = let x = (i1 . i2 . f) x in x (c) Rearranging, and then substituting using (a):     i1 (i2 (mfix f)) = let x = i1 . (i2 . f) x in x                            = i1 (mfix (i2 . f)) (d) Therefore, we could set     i2 (mfix f) = mfix (i2 . f) I'm probably going to make a `data` declaration for M2 so I could actually write     i2 (Mfix f) = mfix (i2 . f) -BenRI From erkokl at gmail.com Thu Oct 25 20:10:09 2018 From: erkokl at gmail.com (Levent Erkok) Date: Thu, 25 Oct 2018 13:10:09 -0700 Subject: [Haskell-cafe] mfix for a nested monad In-Reply-To: <3d5d8600-7313-e75e-4ae8-526a62fd7737@gmail.com> References: <3d5d8600-7313-e75e-4ae8-526a62fd7737@gmail.com> Message-ID: Hi Benjamin, It's impossible to answer your question without precisely pinning down what you mean by an "embedding." For each monad it is defined for, mfix is required to satisfy three laws: Strictness, Purity, and Left-Shrinking. If you can show that your "embedded" definitions satisfy those, then yes; you do have a valid value-recursion operator. You can find a description of these laws in Chapter 2 of [1]. Since you haven't specified what properties your "embedding" has, it's not possible to say anything in isolation. More traditionally, adding "new" effects to old monads in Haskell is achieved by using monad transformers [2]. Perhaps that's what you have in mind? If that's the case, then Section 4.9 of [1] lays out how mfix from the base monad can be lifted through a monad transformer stack while preserving the properties. If you can cast your design in terms of MTL style transformers, this would be the way to go. And if you do use the MTL package, then you'll have your MonadFix instances for free, since the library already defines them via the usual instance mechanism. Cheers, -Levent. [1] http://leventerkok.github.io/papers/erkok-thesis.pdf [2] https://hackage.haskell.org/package/mtl On Thu, Oct 25, 2018 at 7:43 AM Benjamin Redelings < benjamin.redelings at gmail.com> wrote: > Hi, > > I'm trying to implement mfix for a monad that is nested inside another > monad. I came up with the following logic for how to implement this, > but I suspect there are some things I'm missing. My conclusion is that I > want > > interpret (MFix f) = mfix (interpret.f) > > Does this seem right? Has this situation been discussed somewhere? > > -BenRI > > > P.S. Here's what I mean by the monad being nested in another monad. > Let's say that the monad M2 has interpreter i2, with type > > i2 :: M2 a -> M1 a > > and then M1 is the other monad, and has interpreter i1: > > i1 :: M1a -> a > > I suppose that the nesting is really a nesting of interpreters. > > > > P.P.S. I came up with some equational reasoning for how to treat mfix in > the i2 interpreter. > > (a) For some interpreters `i`, it makes sense to require > > i (mfix f) = let x = (i . f) x in x > > (b) I want the composition of interpreters (i1.i2) to act like (a) above: > > (i1 . i2) (mfix f) = let x = (i1 . i2 . f) x in x > > (c) Rearranging, and then substituting using (a): > > i1 (i2 (mfix f)) = let x = i1 . (i2 . f) x in x > = i1 (mfix (i2 . f)) > > (d) Therefore, we could set > > i2 (mfix f) = mfix (i2 . f) > > I'm probably going to make a `data` declaration for M2 so I could > actually write > > i2 (Mfix f) = mfix (i2 . f) > > -BenRI > > _______________________________________________ > 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 leah at vuxu.org Sun Oct 28 16:20:12 2018 From: leah at vuxu.org (Leah Neukirchen) Date: Sun, 28 Oct 2018 17:20:12 +0100 Subject: [Haskell-cafe] Munich Haskell Meeting, 2018-10-30 @ 19:30 Message-ID: <87h8h6avr7.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, October 30 at Augustiner-Gaststätte Rumpler at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-oct-2018/ Everybody is welcome! cu, -- Leah Neukirchen http://leah.zone From aditya.siram at gmail.com Sun Oct 28 20:17:59 2018 From: aditya.siram at gmail.com (aditya siram) Date: Sun, 28 Oct 2018 15:17:59 -0500 Subject: [Haskell-cafe] ANN: Major releases of 'fltkhs-themes' and 'fltkhs' for nice looking, portable native GUIs Message-ID: I'm happy to announce two major releases: fltkhs-themes [1] : a drop-in replacement to FLTKHS [2] with a vastly better looking UX [3] . The small but growing showcase app should hopefully give a better feel for it. And to help you get started with your own project there is a starter app [7] and a lot more documentation [8]. fltkhs[2]: the underlying GUI binding to FLTK which after nearly 6 months of continuous work has been overhauled with a ton of bug fixes and shoring up of the API (fixing leaks, making types more precise via newtypes etc.) and new features have been added including new widgets and out-of-the-box HiDPI and SVG support (which fltkhs-themes relies on heavily for nicer widgets). All the starter kits and demo packages have been updated to this version. If you need help migrating an existing app to the new API feel free to send email to the address on Hackage page or hit me up on Twitter. There a lot more documentation on installation and getting started in the Hackage docs [4]. As always if you have any problems please open an issue on fltkhs [5], fltkhs-themes or any of my other repos. Hopefully these releases help you make Haskell native GUI apps that are fast, portable, easy to install/deploy, and nice looking! [1] http://hackage.haskell.org/package/fltkhs-themes [2] http://hackage.haskell.org/package/fltkhs [3] https://github.com/deech/fltkhs-themes-demo#screenshots [4] http://hackage.haskell.org/package/fltkhs/docs/Graphics-UI-FLTK-LowLevel-FLTKHS.html [5] https://github.com/deech/fltkhs/issues [6] https://github.com/deech/fltkhs-themes/issues [7] https://github.com/deech/fltkhs-light-theme-skeleton [8] http://hackage.haskell.org/package/fltkhs-themes/docs/Graphics-UI-FLTK-Theme-Light.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.l2ll at gmail.com Mon Oct 29 18:56:02 2018 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Mon, 29 Oct 2018 19:56:02 +0100 Subject: [Haskell-cafe] Get number of fields for non-record ADTs using Data type class? Message-ID: Dear list, Is it possible te get the number of fields for data constructors for a plain ADT, i.e something with no record fields? E.g for data T = A Int Double | B String (Maybe String) it would give 2 for both `A` and `B`. For a record it's possible using the `constrFields` function from Data.Data. I was trying to follow this tutorial by Christopher Done https://chrisdone.com/posts/data-typeable, and I feel that it must be possible somehow to get these numbers with the gmap*/gfold* functions, but the use of them is over my head at the moment. Best, -- Markus Läll -------------- next part -------------- An HTML attachment was scrubbed... URL: From lysxia at gmail.com Mon Oct 29 20:34:41 2018 From: lysxia at gmail.com (Li-yao Xia) Date: Mon, 29 Oct 2018 16:34:41 -0400 Subject: [Haskell-cafe] Get number of fields for non-record ADTs using Data type class? In-Reply-To: References: Message-ID: This maps every field to 1, and folds them together using (+): Data.Data.gmapQl (+) 0 (const 1) :: T -> Int (There has to be a similarly easy solution using GHC.Generics instead but I can't think of one...) Li-yao On 10/29/18 2:56 PM, Markus Läll wrote: > Dear list, > > Is it possible te get the number of fields for data constructors for a > plain ADT, i.e something with no record fields? E.g for > > data T = A Int Double | B String (Maybe String) > > it would give 2 for both `A` and `B`. > > For a record it's possible using the `constrFields` function from Data.Data. > > I was trying to follow this tutorial by Christopher Done > https://chrisdone.com/posts/data-typeable, and I feel that it must be > possible somehow to get these numbers with the gmap*/gfold* functions, > but the use of them is over my head at the moment. > > > Best, > > > > -- > Markus Läll > > _______________________________________________ > 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 a.pelenitsyn at gmail.com Mon Oct 29 20:42:16 2018 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Mon, 29 Oct 2018 16:42:16 -0400 Subject: [Haskell-cafe] Get number of fields for non-record ADTs using Data type class? In-Reply-To: References: Message-ID: I don't think there is a point in looking for GHC.Generics-based solution, as Data.Data is the exact match for this kind of problem. -- Best, Artem On Mon, 29 Oct 2018 at 16:35 Li-yao Xia wrote: > This maps every field to 1, and folds them together using (+): > > Data.Data.gmapQl (+) 0 (const 1) :: T -> Int > > (There has to be a similarly easy solution using GHC.Generics instead > but I can't think of one...) > > Li-yao > > On 10/29/18 2:56 PM, Markus Läll wrote: > > Dear list, > > > > Is it possible te get the number of fields for data constructors for a > > plain ADT, i.e something with no record fields? E.g for > > > > data T = A Int Double | B String (Maybe String) > > > > it would give 2 for both `A` and `B`. > > > > For a record it's possible using the `constrFields` function from > Data.Data. > > > > I was trying to follow this tutorial by Christopher Done > > https://chrisdone.com/posts/data-typeable, and I feel that it must be > > possible somehow to get these numbers with the gmap*/gfold* functions, > > but the use of them is over my head at the moment. > > > > > > Best, > > > > > > > > -- > > Markus Läll > > > > _______________________________________________ > > 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 lysxia at gmail.com Mon Oct 29 21:52:31 2018 From: lysxia at gmail.com (Li-yao Xia) Date: Mon, 29 Oct 2018 17:52:31 -0400 Subject: [Haskell-cafe] Get number of fields for non-record ADTs using Data type class? In-Reply-To: References: Message-ID: <72c4ff57-d397-5be5-73c3-642f993221d4@gmail.com> On 10/29/18 4:42 PM, Artem Pelenitsyn wrote: > I don't think there is a point in looking for > GHC.Generics-based solution, as Data.Data is the exact match for this > kind of problem. Although GHC.Generics has its shortcomings (usage complexity and compile times), I still find it worthwhile to advocate as a statically-typed alternative to the dynamically-typed Data.Data for many problems, including this one. Using the one-liner library (which is built around GHC.Generics), the equivalent line of code is: getSum . gfoldMap @AnyType (const 1) :: T -> Int Data.Data is more visible mainly because it comes with a lot of functionality baked into the standard library, whereas GHC.Generics provides only a minimal interface and we have to find everything else in separate packages. However, there is no fundamental reason why one is a better fit than the other for the task of counting constructor fields. Li-yao > > On Mon, 29 Oct 2018 at 16:35 Li-yao Xia > wrote: > > This maps every field to 1, and folds them together using (+): > >      Data.Data.gmapQl (+) 0 (const 1) :: T -> Int > > (There has to be a similarly easy solution using GHC.Generics instead > but I can't think of one...) > > Li-yao > > On 10/29/18 2:56 PM, Markus Läll wrote: > > Dear list, > > > > Is it possible te get the number of fields for data constructors > for a > > plain ADT, i.e something with no record fields? E.g for > > > > data T = A Int Double | B String (Maybe String) > > > > it would give 2 for both `A` and `B`. > > > > For a record it's possible using the `constrFields` function from > Data.Data. > > > > I was trying to follow this tutorial by Christopher Done > > https://chrisdone.com/posts/data-typeable, and I feel that it > must be > > possible somehow to get these numbers with the gmap*/gfold* > functions, > > but the use of them is over my head at the moment. > > > > > > Best, > > > > > > > > -- > > Markus Läll > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > From a.pelenitsyn at gmail.com Mon Oct 29 22:06:48 2018 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Mon, 29 Oct 2018 18:06:48 -0400 Subject: [Haskell-cafe] Get number of fields for non-record ADTs using Data type class? In-Reply-To: <72c4ff57-d397-5be5-73c3-642f993221d4@gmail.com> References: <72c4ff57-d397-5be5-73c3-642f993221d4@gmail.com> Message-ID: Oh, didn't know about `one-liner`. This looks v. nice. Thank you! -- Artem On Mon, 29 Oct 2018 at 17:52 Li-yao Xia wrote: > On 10/29/18 4:42 PM, Artem Pelenitsyn wrote: > > I don't think there is a point in looking for > > GHC.Generics-based solution, as Data.Data is the exact match for this > > kind of problem. > > Although GHC.Generics has its shortcomings (usage complexity and compile > times), I still find it worthwhile to advocate as a statically-typed > alternative to the dynamically-typed Data.Data for many problems, > including this one. > > Using the one-liner library (which is built around GHC.Generics), the > equivalent line of code is: > > getSum . gfoldMap @AnyType (const 1) :: T -> Int > > Data.Data is more visible mainly because it comes with a lot of > functionality baked into the standard library, whereas GHC.Generics > provides only a minimal interface and we have to find everything else in > separate packages. However, there is no fundamental reason why one is a > better fit than the other for the task of counting constructor fields. > > Li-yao > > > > > On Mon, 29 Oct 2018 at 16:35 Li-yao Xia > > wrote: > > > > This maps every field to 1, and folds them together using (+): > > > > Data.Data.gmapQl (+) 0 (const 1) :: T -> Int > > > > (There has to be a similarly easy solution using GHC.Generics instead > > but I can't think of one...) > > > > Li-yao > > > > On 10/29/18 2:56 PM, Markus Läll wrote: > > > Dear list, > > > > > > Is it possible te get the number of fields for data constructors > > for a > > > plain ADT, i.e something with no record fields? E.g for > > > > > > data T = A Int Double | B String (Maybe String) > > > > > > it would give 2 for both `A` and `B`. > > > > > > For a record it's possible using the `constrFields` function from > > Data.Data. > > > > > > I was trying to follow this tutorial by Christopher Done > > > https://chrisdone.com/posts/data-typeable, and I feel that it > > must be > > > possible somehow to get these numbers with the gmap*/gfold* > > functions, > > > but the use of them is over my head at the moment. > > > > > > > > > Best, > > > > > > > > > > > > -- > > > Markus Läll > > > > > > _______________________________________________ > > > 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 icfp.publicity at googlemail.com Tue Oct 30 01:56:14 2018 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Mon, 29 Oct 2018 21:56:14 -0400 Subject: [Haskell-cafe] Call For Workshop Proposals Message-ID: <5bd7ba3ea98c0_407e12270d06299@hermes.mail> CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming August 18 - 23, 2019 Berlin, Germany https://icfp19.sigplan.org/ The 24th ACM SIGPLAN International Conference on Functional Programming will be held in Berlin, Germany on August 18-23, 2019. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as symposiums) to be affiliated with ICFP 2019 and sponsored by SIGPLAN. These events should be less formal and more focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on August 18th (the day before ICFP) and 22-23th of August (the two days after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: November 25, 2018 Notification of acceptance: December 23, 2018 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2019 workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019 at googlegroups.com by November 25, 2018. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 23, 2018, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2019-files/icfp19-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://www.sigplan.org/Resources/Proposals/Sponsored/ ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2019 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Jennifer Hackett (University of Nottingham) Workshop Co-Chair: Christophe Scholliers (University of Ghent) General Chair: Derek Dreyer (MPI-SWS) Program Chair: François Potier (Inria) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019 at googlegroups.com From steve.t.smith at gmail.com Tue Oct 30 02:56:04 2018 From: steve.t.smith at gmail.com (Steven Smith) Date: Mon, 29 Oct 2018 22:56:04 -0400 Subject: [Haskell-cafe] Intention to Take Over adblock2privoxy Hackage Package Message-ID: <7B47CF3A-C895-4078-8899-722D954236F5@gmail.com> Dear Haskell Cafe, I’m writing to publicly state my intention to take over the adblock2privoxy Hackage package: http://hackage.haskell.org/package/adblock2privoxy using the forked github repo at: https://github.com/essandess/adblock2privoxy I have been unable to contact the package’s creator/maintainer at the email provided, and the original repo has not been updated for several years. I forked this project about a year and a half ago, and since then have addressed many issues and incorporated feedback and fixed from the github community, including compilation with the most recent GHC compiler. I am following up on a suggestion made here to publish the latest version in Hackage, following the procedure to take over a package: https://github.com/essandess/adblock2privoxy/pull/29#issue-215776931 https://wiki.haskell.org/Taking_over_a_package My Hackage username is essandess. Sincerely, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Wed Oct 31 23:50:31 2018 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 31 Oct 2018 16:50:31 -0700 Subject: [Haskell-cafe] Network deprecation Message-ID: I'm starting to get deprecation warnings about Network in the network package. I know this has been in the works for a long time, but now that I search I can't find any info about the rationale and suggested replacement (the deprecation message suggests Network.Socket, but this is a completely different lower level api). Does anyone out there have links to discussions, articles, or whatnot? Thanks in advance!