Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1
Is the 7.10.2 hvr ppa using this RC? We just reported a 7.10 regression that I am hoping will be fixed before the release that I was trying to verify https://ghc.haskell.org/trac/ghc/ticket/10599 On Sun, Jun 14, 2015 at 5:16 PM, Austin Seipp aus...@well-typed.com wrote: We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc1 https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/ This includes the source tarball and bindists for Windows, Mac OS X, and Debian Linux. FreeBSD and Solaris binaries will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.2 final release at the end of this coming week - so please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-d...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Increased memory usage with GHC 7.10.1
We have observed issues with compile-time inlining taking much longer in newer versions of GHC in some cases https://github.com/larskuhtz/toCaseFoldBuildTimes This particular issue was reported to the text repo: https://github.com/bos/text/issues/116 On Fri, May 1, 2015 at 7:49 AM, Simon Peyton Jones simo...@microsoft.com wrote: It would be great if someone could · create a ticket for Paolio · investigate what is happening This smaller test case uses Repa, so it’s not clear that GHC is doing anything wrong. Maybe repa is inlining too much? We need insight. Thanks SImon *From:* Glasgow-haskell-users [mailto: glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Paolino *Sent:* 01 May 2015 15:30 *To:* George Colpitts *Cc:* glasgow-haskell-users@haskell.org *Subject:* Re: Increased memory usage with GHC 7.10.1 here is another file , which is small, which cannot be compiled within 4GB memory. https://raw.githubusercontent.com/benl23x5/gloss/master/gloss-examples/raster/Fluid/src-repa/Stage/Linear.hs I'd just want to add that this problem is a nasty one if one doesn't set the max heap: a remote machine frozen that must be rebooted is not a nice adventure , hoping the crash remains confined to the vm. hth, paolino 2015-05-01 15:31 GMT+02:00 George Colpitts george.colpi...@gmail.com: Should we recommend that all library developers compile their libraries with a max heap of 4G (to pick an arbitrary number) so that we can catch some of these issues earlier? On Fri, May 1, 2015 at 5:42 AM, Paolino paolo.verone...@gmail.com wrote: Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with -O1 and -O2 due to ghc : out of memory error on a 4GB linux host. The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions https://hackage.haskell.org/package/OpenGLRaw-2.4.1.0/docs/src/Graphics-Rendering-OpenGL-Raw-Functions.html. With -O0 it uses 600 MB. The file is really huge, but I could compile it with prior versions of ghc. Regards paolino 2015-04-17 1:33 GMT+02:00 David Laing dave.laing...@gmail.com: Hi all, I've been playing around with profiling GHC recently, so I thought I'd chime in with a pointer that might save people searching for the right docs - you could configure a cabal sandbox to work with multiple version of ghc, which I've found useful: https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage Cheers, Dave On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta michal.terep...@gmail.com wrote: Hi Richard, Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with build flavor 'prof' then get the haskell-src-exts sources, install the dependencies and finally add +RTS -p -RTS to the cabal file and compile it, the resulting ghc.prof contains the profiling information. For anyone interested about CallArity slowness, the problem is tracked in https://ghc.haskell.org/trac/ghc/ticket/10293 Cheers, Michal On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg e...@cis.upenn.edu wrote: I've pasted Michal's numbers in #9630, which seems like a good place to track this. Michal, would you mind fleshing out a bit precisely what you did to get those numbers? That would be helpful (though you've already been very helpful indeed in getting the data together)! Thanks, Richard On Apr 14, 2015, at 9:09 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij christiaan.ba...@gmail.com wrote: Actually, I meant only with -fno-specialise. Done. Helps quite a bit but CallArity is still a pretty expensive. I’m on that, and I think I have a quite neat fix for it. I’ll report on that in the trac ticket: https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Restricted Template Haskell
I would like to figure out how to improve the state of TTH documentation. The GHC wiki is usually for things that are changing, and the page is written in that future style, so it makes one wonder if all things are finished or if some things remain unfinished. Some this is how it is documentation in the user guide would seem more useful now. But I am not sure if the user guide [1] is even correct because it indicates a type of `Q (TExp a)` where I would expect just `TExp a` from reading the wiki [2]. [1] https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/template-haskell.html [2] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges On Mon, Feb 2, 2015 at 11:31 AM, Greg Weber g...@gregweber.info wrote: Hi Simon, I am just starting the proposal: gathering interested parties and pointers to related information. Thanks for the pointer to Typed Template Haskell. I was actually unaware of the extent to which Typed Template Haskell is restricted. I have not seen any usage of Typed Template Haskell in the wild or been able to use it myself unfortunately due to backwards compatibility needs (once the next GHC release is out libraries will start to consider dropping 7.6 support and we will see more usage, although Ubuntu still ships 7.6 by default). I will study Typed Template Haskell. Greg Weber On Mon, Feb 2, 2015 at 9:33 AM, Simon Peyton Jones simo...@microsoft.com wrote: The new TH is already split into two parts https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal as I’m sure you know · Typed TH is for expressions only, and doesn’t have reify, nor any Q monad. · Untyped TH is the wild west Typed TH may get some of what you want? Certainly you want to acknowledge the existing split in your own design. The proposal could do with examples to illustrate what the difficulties are. What bad things happen in the Q monad? Can you give examples of reasoning that would be valid in level 1 but not in level 2. etc. More precision please! Simon *From:* Glasgow-haskell-users [mailto: glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Greg Weber *Sent:* 30 January 2015 23:39 *To:* ghc-d...@haskell.org; GHC users *Cc:* David Terei; Maxwell Swadling *Subject:* Restricted Template Haskell Hello GHC friends! I am starting up a proposal for variants of Template Haskell that restrict what operations are available. The goal is to make TH easier for users to reason about and to allow for an easier compilation story. Here is the proposal page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted Right now the proposal does not have any details and the goal is to write out a clear specification. If this sounds interesting to you, let me know or leave some feedback on the wiki. Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Restricted Template Haskell
Hi Simon, I am just starting the proposal: gathering interested parties and pointers to related information. Thanks for the pointer to Typed Template Haskell. I was actually unaware of the extent to which Typed Template Haskell is restricted. I have not seen any usage of Typed Template Haskell in the wild or been able to use it myself unfortunately due to backwards compatibility needs (once the next GHC release is out libraries will start to consider dropping 7.6 support and we will see more usage, although Ubuntu still ships 7.6 by default). I will study Typed Template Haskell. Greg Weber On Mon, Feb 2, 2015 at 9:33 AM, Simon Peyton Jones simo...@microsoft.com wrote: The new TH is already split into two parts https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal as I’m sure you know · Typed TH is for expressions only, and doesn’t have reify, nor any Q monad. · Untyped TH is the wild west Typed TH may get some of what you want? Certainly you want to acknowledge the existing split in your own design. The proposal could do with examples to illustrate what the difficulties are. What bad things happen in the Q monad? Can you give examples of reasoning that would be valid in level 1 but not in level 2. etc. More precision please! Simon *From:* Glasgow-haskell-users [mailto: glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Greg Weber *Sent:* 30 January 2015 23:39 *To:* ghc-d...@haskell.org; GHC users *Cc:* David Terei; Maxwell Swadling *Subject:* Restricted Template Haskell Hello GHC friends! I am starting up a proposal for variants of Template Haskell that restrict what operations are available. The goal is to make TH easier for users to reason about and to allow for an easier compilation story. Here is the proposal page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted Right now the proposal does not have any details and the goal is to write out a clear specification. If this sounds interesting to you, let me know or leave some feedback on the wiki. Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Restricted Template Haskell
On Fri, Jan 30, 2015 at 7:05 PM, adam vogt vogt.a...@gmail.com wrote: Hi Greg, Perhaps a less-invasive way to implement the -XSafe part of your proposal would be to provide a module like: module Language.Haskell.TH.Safe ( module Language.Haskell.TH, reifyWithoutNameG, ) where import Language.Haskell.TH hiding (runIO, reify*) where reifyWithoutNameG is the same as reify, except definitions that are out of scope are either missing or modified such that they use NameQ instead of NameG for out-of-scope names. Thanks, I added this concept to the wiki. That way there is no new syntax needed, and safe TH can be called by unsafe TH without any conversions. I think defining another monad like Q that can do less is too inconvenient because you have to disambiguate between Safe.listE and Unsafe.listE, or make those functions more polymorphic (which makes type errors worse). Another option would be if there were Oh, you are getting into more concrete details now than I have even thought about! For the restricted monad route, we might look into a more capable method of using capabilities that would end up looking like this: reify :: Name - Restrict (TH :+: Reify) Info runIO :: IO a - Restrict (TH :+: RunIO) a There are still a lot of details to work out, thanks for getting things started. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Restricted Template Haskell
Hello GHC friends! I am starting up a proposal for variants of Template Haskell that restrict what operations are available. The goal is to make TH easier for users to reason about and to allow for an easier compilation story. Here is the proposal page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted Right now the proposal does not have any details and the goal is to write out a clear specification. If this sounds interesting to you, let me know or leave some feedback on the wiki. Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1
No, it is a big change and the merge window is closed now. This question was just asked on reddit: http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/ On Tue, Dec 23, 2014 at 6:12 PM, Kazu Yamamoto k...@iij.ad.jp wrote: Hi, If I understand correctly, OverloadedRecordFields has not been merged yet. Are there any chances to merge it into GHC 7.10.1? --Kazu We are pleased to announce the first release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc1/ This includes the source tarball and bindists for 64bit/32bit Linux and Windows. Binary builds for other platforms will be available shortly. (CentOS 6.5 binaries are not available at this time like they were for 7.8.x). These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.1 release sometime in February of 2015. We expect another RC to occur during January of 2015. Please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Annotations: status and documentation
Should I be asking this question on a different mailing list such as ghc-devs? On Wed, Nov 5, 2014 at 12:21 PM, Greg Weber g...@gregweber.info wrote: I would like to be able to retrieve user-supplied annotations in Template Haskell. The 7.8 user manual doesn't mention this ability. However, I see this Trac page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations Where it appears that this feature may exist in 7.8. I will gladly tinker with annotations and update the user manual if someone will help me understand what the situation is. On a related note, it looks like this patch pointed to from the Wiki page for annotations got ignored. Should i submit it to phabricator? https://ghc.haskell.org/trac/ghc/ticket/8460 Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Annotations: status and documentation
I was able to get in touch with the author and I am discussing my use case with him. Thanks! On Thu, Nov 6, 2014 at 10:23 AM, Greg Weber g...@gregweber.info wrote: Should I be asking this question on a different mailing list such as ghc-devs? On Wed, Nov 5, 2014 at 12:21 PM, Greg Weber g...@gregweber.info wrote: I would like to be able to retrieve user-supplied annotations in Template Haskell. The 7.8 user manual doesn't mention this ability. However, I see this Trac page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations Where it appears that this feature may exist in 7.8. I will gladly tinker with annotations and update the user manual if someone will help me understand what the situation is. On a related note, it looks like this patch pointed to from the Wiki page for annotations got ignored. Should i submit it to phabricator? https://ghc.haskell.org/trac/ghc/ticket/8460 Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Annotations: status and documentation
I would like to be able to retrieve user-supplied annotations in Template Haskell. The 7.8 user manual doesn't mention this ability. However, I see this Trac page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations Where it appears that this feature may exist in 7.8. I will gladly tinker with annotations and update the user manual if someone will help me understand what the situation is. On a related note, it looks like this patch pointed to from the Wiki page for annotations got ignored. Should i submit it to phabricator? https://ghc.haskell.org/trac/ghc/ticket/8460 Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
I created a GHC patch that spits out the generated Template Haskell code to a file with -dump-to-file -ddump-splices https://ghc.haskell.org/trac/ghc/ticket/9126 On Sat, Jul 5, 2014 at 8:18 PM, adam vogt vogt.a...@gmail.com wrote: Zeroth takes the first approach. It only supports a subset of TH (DecsQ splices) however. http://hackage.haskell.org/package/zeroth https://github.com/aavogt/zeroth is a fork that works with more recent haskell-src-exts and ghc On Sat, Jul 5, 2014 at 3:59 PM, John Meacham j...@repetae.net wrote: Actually, I was looking into it a little, and template haskell could effectively be implemented by a pre-processor and a portable library that is compiler independent. If one could get ghc to spit out the template haskell source after it expands it then that can be fed to jhc as a quick first pass, but ideally the pre-processor TH would create programs that can be run under the target compiler. that would bring TH to every haskell compiler. John On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery allber...@gmail.com wrote: On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald carter.schonw...@gmail.com wrote: does JHC support template haskell? Pretty sure TH is too closely tied to ghc. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -- John Meacham - http://notanumber.net/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8.3 release
For me upgrading to 7.8 was very easy. The release slippage actually helped out with that. 7.8 had already been specified well enough and already had some active users for a long time. This made for a long window for package maintainers to update their packages to have 7.8 compatibility. Perhaps October is a good timeline to try to cut an initial alpha release that specifies the interface for package authors to compile against, but the actual release can wait until later. On Fri, May 30, 2014 at 2:46 PM, Simon Marlow marlo...@gmail.com wrote: On 27/05/14 09:06, Austin Seipp wrote: PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. FWIW, I think doing 7.10 in October is way too soon. Major releases create a large distributed effort for package maintainers and users, and there are other knock-on effects, so we shouldn't do them too often. A lot of our users want stability, while many of them also want progress, and 12 months between major releases is the compromise we settled on. The last major release slipped for various reasons, but I don't believe that means we should try to get back on track by having a short time between 7.8 and 7.10. 7.8 will be out of maintenance when it has only just made it into a platform release. Anyway, that's my opinion. Of course if everyone says they don't mind a 7.10 in October then I withdraw my objection :-) (as a data point, upgrading to 7.8 at work cost me three weeks, but we're probably a special case) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: PROPOSAL: Literate haskell and module file names
Can we get a little more information on what pandoc is doing? Is there a documentation link? In part am wondering if it is possible to have a Foo.hs.md file that pandoc compiles down to Foo.hs with or without help from GHC. On Sun, Mar 16, 2014 at 5:56 AM, Merijn Verstraaten mer...@inconsistent.nlwrote: Ola! I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) The report only mentions that by convention .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name Foo.rst but module name Foo.rst maps to filename Foo/rst.hs which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. Pros: - Tool authors can more easily determine non-haskell content of literate haskell files - Currently valid module names will not break - Report doesn't specify behaviour, so GHC can do whatever it likes Cons: - Someone has to implement it - ?? Discussion: 4 weeks Cheers, Merijn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: carriage returns on Windows from quasi-quotes
Yes, this is only an issue on Windows. On Fri, Oct 4, 2013 at 11:19 PM, Christopher Done chrisd...@gmail.comwrote: They're on Windows? On 5 October 2013 01:36, Greg Weber g...@gregweber.info wrote: A Windows user rerported using Data.Text.IO.writeFile to write out quasi-quoted text. writeFile automatically translates '\r' to \r\n, so the user ended up writing out \r\r\n to a file. Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Desugaring do-notation to Applicative
I think there are 2 use cases: * explicit ado is best, it communicates the intent of the writer and can give better error messages * we want users to write code in a do style and the implementer to make it applicative if possible So we probably need to accommodate 2 use cases with 2 extensions, one that enables `ado` and have another extension that will automatically work with `do`. Another advantage of this approach is that `ado` should be simpler to get started. On Wed, Oct 2, 2013 at 1:27 PM, Bardur Arantsson s...@scientician.netwrote: On 2013-10-02 20:13, Reid Barton wrote: On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett ekm...@gmail.com wrote: That is admittedly a pretty convincing example that we may want to provide either a LANGUAGE pragma or a different syntax to opt in. I suppose the Applicative desugaring can reliably be disabled by adding a syntactic dependency on previous variables, like [ (x, y) | x - [1..3], y - const [1..1000] x ] so as far as I'm concerned it's sufficient if the Applicative desugaring is opt-in on a per-module basis, without a separate syntax for Applicative vs Monad do-notation/comprehensions. That seems like an easily-overlooked and IMO too-subtle way to saying hey, GHC, don't do the applicative desugaring in this particular place. Those who opt in can be expected to understand and deal with this sharing issue if it affects them. (They pretty much have to understand it already, if they are compiling with optimizations.) I don't think it's a about understanding -- not all READERS of the code could necessarily be expected to have the same expertise (or level of carefulness) as the writer of the code. This could lead to subtle bugs arising during maintenance. Therefore it would seem a good idea to me to be explicit about the distiction with ado vs. do (or similar) -- not sure about how the distincation should be made in the comprehensions, but I'm sure *something* explicit can be worked out. I mean, is a single extra letter really a burden? Regards, Bardur ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
carriage returns on Windows from quasi-quotes
A Windows user rerported using Data.Text.IO.writeFile to write out quasi-quoted text. writeFile automatically translates '\r' to \r\n, so the user ended up writing out \r\r\n to a file. Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] [web-devel] Automatic error traces
That's great. We should collaborate on this. I wrote the file-location package and Michael Snoyman wrote monad-logger: both of these give file location information. I also added command tracing to Shelly (which could also benefit from this kind of thing) and recently released rollbar for error notification and would like to have as much line info as possible for that. On Tue, Jul 16, 2013 at 5:45 AM, Alberto G. Corona agocor...@gmail.comwrote: It is important to have execution traces in case of error. specially in server applications that run 24/7 such are web applications Thanks to the wonderful package monadloc by Pepe Iborra, now MFlow can generate a complete execution trace in case of error. The control-monad-exception uses monadLoc to generate stack traces, but MFlow makes use of his backtracking mechanism to generate a complete execution trace. Here I explain what and how: http://haskell-web.blogspot.com.es/2013/07/automatic-error-trace-generation-in.html The MFlow version that implements this is in gitHub. Not in hackage yet. https://github.com/agocorona/MFlow I´m quite proud of it since it is one of the things closest to magic that I have done. Feedback? I do not want to keep MFlow as a single person development. I think that it has many unique and nice features not available in other languages and frameworks, and it can be raised to a serious exploitation level by the Haskell community. This will attract people working in Industrial Web development to Haskell thanks to the edge in expressiveness and safety necessary for creating industrial solutions that Haskell has over other languages. It uses most other Haskell web developments blaze, wai, hamlet etc and there are many other things to come. monadLoc : http://hackage.haskell.org/package/monadloc -- Alberto. ___ web-devel mailing list web-de...@haskell.org http://www.haskell.org/mailman/listinfo/web-devel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shake, Shelly, FilePath
Shelly is using system-filepath which was created as an improvement over using a simple String. For a build system in which you name all your files you may not care about the upside. If you want a version of Shelly that uses String you can try Shellish, its predecessor. Otherwise the shim should be written for Shake to use system-filepath. Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Suggested policy: use declarative names for tests instead of increasing integers
The 2 approaches are not mutually exclusive.
ticket#_description.hs
tc12345_GADT.hs
On Tue, Dec 18, 2012 at 6:22 AM, Simon Marlow marlo...@gmail.com wrote:
On 18/12/12 12:33, Roman Cheplyaka wrote:
* Simon Peyton-Jones simo...@microsoft.com [2012-12-18 10:32:39+]
(This belongs on cvs-ghc, or the upcoming ghc-devs.)
| I find our tests to be quite hard to navigate, as the majority have
| names like tc12345.hs or some such. I suggest we instead use
descriptive
| names like GADT.hs or PrimOps.hs instead. What do people think?
We've really moved to a naming convention connected to tickets. Thus
test T7490 is a test for Trac ticket #7490. This is fantastic. It
eliminates the need for elaborate comments in the test to say what is being
tested... just look at the ticket.
The old serially number tests tc032 etc are history.
If there isn't a corresponding ticket, it'd be a good idea to create one.
Increasingly we refer to tickets in source-code comments. They are
incredibly valuable resource to give the detail of what went wrong.
OK? We should document this convention somewhere.
It is sort of documented at http://hackage.haskell.org/**
trac/ghc/wiki/Building/**RunningTests/Addinghttp://hackage.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding
Having found a suitable place for the test case, give the test case a
name. For regression test cases, we often just name the test case
after the bug number (e.g. T2047). Alternatively, follow the
convention for the directory in which you place the test case: for
example, in typecheck/should_compile, test cases are named tc001,
tc002, and so on.
But I wonder what if one wants to create a test preventively (say, for a
new feature), and there isn't actually any bug to create a ticket for?
It wouldn't hurt to be more descriptive with test names than we are
currently in e.g. codeGen and typechecker. Some parts of the testsuite are
better, e.g. see libraries/base/tests where the tests are named after the
function being tested (sort of), or in codeGen/should_run_asm:
test('memcpy',
unless_platform('x86_64-**unknown-linux',skip), compile_cmp_asm,
[''])
test('memcpy-unroll',
unless_platform('x86_64-**unknown-linux',skip), compile_cmp_asm,
[''])
test('memcpy-unroll-conprop',
unless_platform('x86_64-**unknown-linux',skip), compile_cmp_asm,
[''])
ticket numbers are good names for regression tests, but for other tests
more descriptive names would help. There isn't always a good name for a
test, but often there is.
Cheers,
Simon
__**_
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.**org Glasgow-haskell-users@haskell.org
http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-usershttp://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: Adding support for an API-since-version-attribute to Haddock?
a lot of packages are doing this already, would be nice to formalize it On Tue, Sep 4, 2012 at 3:56 AM, Herbert Valerio Riedel h...@gnu.org wrote: Hello Haskellers, I've been wondering whether it might be useful to add a feature to Haddock similar to what can be found in other API documentation systems, specifically an optional parseable since-attribute, declaring the last package version when the associated definition/symbol was introduced or its semantics modified. Beyond giving a uniform/standard representation for this kind of information (e.g. if Haddock would render this information in a distinctive style suitable to give a visual hint for locating this information easily), this information could be used to generate an automated changelog entry (at least for the current package version), listing all definitions added or modified with the current version. Another application I could thinkg of would be to find the lowest version of a package supporting the currently used API from it (given the currently known-to-work package-version and a list of currently used symbols from that package). Would such an enhancement to Haddock be worthwhile or is it a bad idea? Has such a proposal come up in the past already? Are there alternative approaches to consider? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: Scoping rule change
sounds good. will there be a shadowing warning? On Mon, Jul 23, 2012 at 5:28 PM, Lennart Augustsson lenn...@augustsson.net wrote: It's not often that one gets the chance to change something as fundamental as the scoping rules of a language. Nevertheless, I would like to propose a change to Haskell's scoping rules. The change is quite simple. As it is, top level entities in a module are in the same scope as all imported entities. I suggest that this is changed to that the entities from the module are in an inner scope and do not clash with imported identifiers. Why? Consider the following snippet module M where import I foo = True Assume this compiles. Now change the module I so it exports something called foo. After this change the module M no longer compiles since (under the current scoping rules) the imported foo clashes with the foo in M. Pros: Module compilation becomes more robust under library changes. Fewer imports with hiding are necessary. Cons: There's the chance that you happen to define a module identifier with the same name as something imported. This will typically lead to a type error, but there is a remote chance it could have the same type. Implementation status: The Mu compiler has used the scoping rule for several years now and it works very well in practice. -- Lennart ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: default instance for IsString
On Mon, Apr 23, 2012 at 9:58 AM, Yitzchak Gale g...@sefer.org wrote:
Jeremy Shaw wrote:
I have often wished for something like:
{-# LANGUAGE StringLiteralsAs Text #-}
where all string literals like:
f = foo
would be translated to:
f = (fromString foo :: Text)
Agreed, I would also really like this.
I find that OverloadedStrings is too general and causes ambiguous type
errors. Additionally, I seldom find that I have more than one type of
string literal per file. Things tend to be all String, all Text, etc.
So, if I could just pick a concrete type for all the string literals
in my file, I would be happy.
In addition, OverloadedStrings is unsound. Library authors can,
and do, write unsafe implementations of IsString that cause
syntax errors to be caught only at run time instead of at
compile time. That is the opposite of one of the most
important things we are trying to accomplish by using
Haskell instead of, say, some dynamically typed language.
Greg Weber wrote:
You can default a String. So this compiles just fine:
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE ExtendedDefaultRules #-}
import Data.Text as T
default (T.Text)
No, I do not want string literals to be polymorphic, even
if there is some kind of defaulting. I want them to be
monomorphic, as they always have been. But I still
want to be able to specify to the compiler somehow
that the monomorphic type for string literals in a
particular module should be something other than
String.
Thanks,
Yitz
Hi Yitz,
I very much agree with you. However, when we complain about something
essentially we are asking others to prioritize it ahead of other
things. I don't think any more visibility of this issue is going to
improve its prioritization. I suspect your only way forward right now
is to start implementing something yourself.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
The defaulting is very good for most use cases, however I am
discovering it won't default when I try to build up a list or tuple.
This does not work:
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE ExtendedDefaultRules #-}
{-# LANGUAGE FlexibleInstances #-}
module Default (noDefault) where
import Data.Text as T
default (T.Text)
classNoDefault awhere noDefault :: a - [Text]
instance NoDefault [T.Text] where noDefault = id
main = print (noDefault [Hello!])
On Sun, Apr 22, 2012 at 8:31 PM, Greg Weber g...@gregweber.info wrote:
Sorry, someone responded on haskell-cafe and the message didn't get
sent here. You can default a String. So this compiles just fine:
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE ExtendedDefaultRules #-}
import Data.Text as T
default (T.Text)
class NoDefault a where noDefault :: a - Text
instance NoDefault T.Text where noDefault = id
main = print (noDefault Hello!)
On Sun, Apr 22, 2012 at 1:57 PM, Jeremy Shaw jer...@n-heptane.com wrote:
I have often wished for something like:
{-# LANGUAGE StringLiteralsAs Text #-}
where all string literals like:
f = foo
would be translated to:
f = (fromString foo :: Text)
I find that OverloadedStrings is too general and causes ambiguous type
errors. Additionally, I seldom find that I have more than one type of
string literal per file. Things tend to be all String, all Text, etc.
So, if I could just pick a concrete type for all the string literals
in my file, I would be happy.
- jeremy
On Sat, Apr 21, 2012 at 7:20 PM, Greg Weber g...@gregweber.info wrote:
I would like to default IsString to use the Text instance to avoid
ambiguous type errors.
I see defaulting capability is available for Num. Is there any way to
do this for IsString?
Thanks,
Greg Weber
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
so how can I update the documentation? I asked some of the most experienced Haskell users at the Hackathon about this, and looked through any documentation I could find and there was nothing indicating I could do what you sent in your last message. On Sun, Apr 22, 2012 at 8:15 AM, Markus Läll markus.l...@gmail.com wrote: The core of it is in the GHC docs' overloaded strings section [1]. It could be clearer though -- reading about defaulting in the reports, in the type defaulting section of GHC docs and in [1] can be a bit confusing. [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#overloaded-strings On Sun, Apr 22, 2012 at 4:54 PM, Greg Weber g...@gregweber.info wrote: Thanks Markus, I think you have saved the day! Even after googling for this extension and searching in the manual I am still coming up pretty blank. Is there somewhere I missed where this is documented or somewhere I can contribute documentation? On Sun, Apr 22, 2012 at 4:47 AM, Markus Läll markus.l...@gmail.com wrote: ExtendedDefaultRules -- Markus Läll ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Sorry, someone responded on haskell-cafe and the message didn't get
sent here. You can default a String. So this compiles just fine:
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE ExtendedDefaultRules #-}
import Data.Text as T
default (T.Text)
classNoDefault a where noDefault :: a - Text
instance NoDefault T.Text where noDefault = id
main = print (noDefault Hello!)
On Sun, Apr 22, 2012 at 1:57 PM, Jeremy Shaw jer...@n-heptane.com wrote:
I have often wished for something like:
{-# LANGUAGE StringLiteralsAs Text #-}
where all string literals like:
f = foo
would be translated to:
f = (fromString foo :: Text)
I find that OverloadedStrings is too general and causes ambiguous type
errors. Additionally, I seldom find that I have more than one type of
string literal per file. Things tend to be all String, all Text, etc.
So, if I could just pick a concrete type for all the string literals
in my file, I would be happy.
- jeremy
On Sat, Apr 21, 2012 at 7:20 PM, Greg Weber g...@gregweber.info wrote:
I would like to default IsString to use the Text instance to avoid
ambiguous type errors.
I see defaulting capability is available for Num. Is there any way to
do this for IsString?
Thanks,
Greg Weber
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] default instance for IsString
Thanks Markus, I think you have saved the day! Even after googling for this extension and searching in the manual I am still coming up pretty blank. Is there somewhere I missed where this is documented or somewhere I can contribute documentation? On Sun, Apr 22, 2012 at 4:47 AM, Markus Läll markus.l...@gmail.com wrote: ExtendedDefaultRules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] default instance for IsString
so how can I update the documentation? I asked some of the most experienced Haskell users at the Hackathon about this, and looked through any documentation I could find and there was nothing indicating I could do what you sent in your last message. On Sun, Apr 22, 2012 at 8:15 AM, Markus Läll markus.l...@gmail.com wrote: The core of it is in the GHC docs' overloaded strings section [1]. It could be clearer though -- reading about defaulting in the reports, in the type defaulting section of GHC docs and in [1] can be a bit confusing. [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#overloaded-strings On Sun, Apr 22, 2012 at 4:54 PM, Greg Weber g...@gregweber.info wrote: Thanks Markus, I think you have saved the day! Even after googling for this extension and searching in the manual I am still coming up pretty blank. Is there somewhere I missed where this is documented or somewhere I can contribute documentation? On Sun, Apr 22, 2012 at 4:47 AM, Markus Läll markus.l...@gmail.com wrote: ExtendedDefaultRules -- Markus Läll ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
default instance for IsString
I would like to default IsString to use the Text instance to avoid ambiguous type errors. I see defaulting capability is available for Num. Is there any way to do this for IsString? Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
my actual use case looks more like this:
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
import Data.Text as T
class ShowT a where
showT :: a - String
instance ShowT T.Text where
showT = show
instance ShowT String where
showT = show
main = print (showT Hello!)
Ambiguous type variable `a0' in the constraints:
(ShowT a0) arising from a use of `showT' at default.hs:16:15-19
(Data.String.IsString a0) arising from the literal `Hello!'
So I actually want to define a default instance for a typeclass I
define that uses isString instances.
On Sat, Apr 21, 2012 at 6:24 PM, Daniel Peebles pumpkin...@gmail.com wrote:
I think it'll be hard to do that without putting Text in base, which I'm not
sure anyone wants to do.
Dan
On Sat, Apr 21, 2012 at 8:20 PM, Greg Weber g...@gregweber.info wrote:
I would like to default IsString to use the Text instance to avoid
ambiguous type errors.
I see defaulting capability is available for Num. Is there any way to
do this for IsString?
Thanks,
Greg Weber
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
This is a better demonstration of the issue. I am going to open a GHC
bug report, as I can't see how this behavior is desirable.
{-# LANGUAGE OverloadedStrings #-}
import Data.Text as T
classNoDefault a where noDefault :: a - Text
instance NoDefault T.Text where noDefault = id
main = print (noDefault Hello!)
default.hs:7:15:
Ambiguous type variable `a0' in the constraints:
(NoDefault a0) arising from a use of `noDefault'
at default.hs:7:15-23
(Data.String.IsString a0) arising from the literal `Hello!'
at default.hs:7:25-32
Probable fix: add a type signature that fixes these type variable(s)
In the first argument of `print', namely `(noDefault Hello!)'
In the expression: print (noDefault Hello!)
In an equation for `main': main = print (noDefault Hello!)
On Sat, Apr 21, 2012 at 7:51 PM, Greg Weber g...@gregweber.info wrote:
my actual use case looks more like this:
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
import Data.Text as T
class ShowT a where
showT :: a - String
instance ShowT T.Text where
showT = show
instance ShowT String where
showT = show
main = print (showT Hello!)
Ambiguous type variable `a0' in the constraints:
(ShowT a0) arising from a use of `showT' at default.hs:16:15-19
(Data.String.IsString a0) arising from the literal `Hello!'
So I actually want to define a default instance for a typeclass I
define that uses isString instances.
On Sat, Apr 21, 2012 at 6:24 PM, Daniel Peebles pumpkin...@gmail.com wrote:
I think it'll be hard to do that without putting Text in base, which I'm not
sure anyone wants to do.
Dan
On Sat, Apr 21, 2012 at 8:20 PM, Greg Weber g...@gregweber.info wrote:
I would like to default IsString to use the Text instance to avoid
ambiguous type errors.
I see defaulting capability is available for Num. Is there any way to
do this for IsString?
Thanks,
Greg Weber
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] GSOC Proposal 2012 : HDBC
Hi Pranjal, We are glad you are interested in the GSoC. Please take a look at persistent: http://www.yesodweb.com/book/persistent It performs queries and serialization based on Haskell records. It also uses native drivers rather than HDBC. I created a proposal outline [1] and there is a student submission for it [2] [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1605 [2] http://hackage.haskell.org/trac/summer-of-code/ticket/1605 Let me know if you are interested in that or need help coming up with a proposal Thanks, Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: A Modest Records Proposal
Hi Gershom,
This sounds very interesting even if I have no idea what you are
talking about :)
Please create a proposal linked from this page:
http://hackage.haskell.org/trac/ghc/wiki/Records
The first thing you should probably do is explain the programmer's
point of view. That ensures that we are all going through the
requirements phase correctly.
I can assure you that haskell prime would not accept a records change
until it is first implemented in GHC or another Haskell compiler.
Thanks,
Greg Weber
On Sat, Mar 31, 2012 at 11:14 PM, Gershom B gersh...@gmail.com wrote:
The records discussion has been really complicated and confusing. But
I have a suggestion that should provide a great deal of power to
records, while being mostly[1] backwards-compatible with Haskell 2010.
Consider this example:
data A a = A{a:a, aa::a, aaa :: a - A (a - a)}
data B a = B{aaa :: a - A (a - a), a :: A}
Now what is the type of this?
a a aa = a{a = a, aaa = aa}
Using standard Haskell typeclasses this is a difficult question to
answer. The types of for A and B do not unify in an obvious way.
However, while they are intensionally quite distinct, they unify
trivially extensionally. The obvious thing to do is then to extend the
type system with extensional equality on record functions.
Back when Haskell was invented, extensional equality was thought to be
hard. But purity was thought to be hard too, and so were Monads. Now,
we know that function existentionality is easy. In fact, if we add the
Univalence Axiom to GHC[2], then this is enough to get function
existensionality. This is a well-known result of Homotopy Type
Theory[3], which is a well-explored approach that has existed for at
least a few years and produced more than one paper[4]. Homotopy Type
Theory is so sound and well understood that it has even been
formalized in Coq.
Once we extend GHC with homotopies, it turns out that records reduce
to mere syntactic sugar, and there is a natural proof of their
soundness (Appendix A). Furthermore, there is a canonical projection
for any group of fields (Appendix B). Even better, we can make .
into the identity path operator, unifying its uses in composition and
projection. In fact, with extended (parenthesis-free) section rules,
. can also be used to terminate expressions, making Haskell friendly
not only to programmers coming from Java, but also to those coming
from Prolog!
After some initial feedback, I'm going to create a page for the
Homotopy Extensional Records Proposal (HERP) on trac. There are really
only a few remaining questions. 1) Having introduced homotopies, why
not go all the way and introduce dependent records? In fact, are HERP
and Dependent Extensional Records Proposal (DERP) already isomorphic?
My suspicion is that HERP is isomorphic, but DERP is not. However, I
can only get away with my proof using Scott-free semantics. 2) Which
trac should I post this too? Given how well understood homotopy type
theory is, I'm tempted to bypass GHC entirely and propose this for
haskell-prime. 3) What syntax should we use to represent homotopies?
See extend discussion in Appendix C.
HTH HAND,
Gershom
[1] To be precise, 100% of Haskell 2010 programs should, usually, be
able to be rewritten to work with this proposal with a minimal set of
changes[1a].
[1a] A minimal set of changes is defined as the smallest set of
changes necessary to make to a Haskell 2010 program such that it works
with this proposal. We can arrive at these changes by the following
procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3)
are we done? If not, make another change.
[1b] To do this constructively, we need an order. I suggest the lo
mein, since noodles give rise to a free soda.
[2] I haven't looked at the source, but I would suggest putting it in
the file Axioms.hs.
[3] http://homotopytypetheory.org/
[4] http://arxiv.org/
*Appendix A: A Natural Proof of the Soundness of HERP
Take the category of all types in HERP, with functions as morphisms.
Call it C. Take the category of all sound expressions in HERP, with
functions as morphisms. Call it D. Define a full functor from C to D.
Call it F. Define a faithful functor on C and D. Call it G. Draw the
following diagram.
F(X)F(Y)
| |
| |
| |
G(X)G(Y)
Define the arrows such that everything commutes.
*Appendix B: Construction of a Canonical Projection for Any Group of Fields.
1) Take the fields along the homotopy to an n-ball.
2) Pack them loosely with newspaper and gunpowder.
3) Project them from a cannon.
In an intuitionistic logic, the following simplification is possible:
1) Use your intuition.
*Appendix C: Homotopy Syntax
Given that we already are using the full unicode set, what syntax
should we use to distinguish paths and homotopies? At first, I thought
we could avoid providing any syntax for homotopies at all. Haskell
Re: [Haskell-cafe] A Modest Records Proposal
Obviously Gregory is not familiar with Homotopy. In fact, its
isomorphism predicts that if someone named Greg is involved in a
discussion, someone named Gregory will also become involved.
Or that is what I get for responding to an e-mail without reading it
on April 1st :)
On Sun, Apr 1, 2012 at 7:40 AM, Gregory Collins g...@gregorycollins.net wrote:
Whoosh? :-)
On Sun, Apr 1, 2012 at 3:54 PM, Greg Weber g...@gregweber.info wrote:
Hi Gershom,
This sounds very interesting even if I have no idea what you are
talking about :)
Please create a proposal linked from this page:
http://hackage.haskell.org/trac/ghc/wiki/Records
The first thing you should probably do is explain the programmer's
point of view. That ensures that we are all going through the
requirements phase correctly.
I can assure you that haskell prime would not accept a records change
until it is first implemented in GHC or another Haskell compiler.
Thanks,
Greg Weber
On Sat, Mar 31, 2012 at 11:14 PM, Gershom B gersh...@gmail.com wrote:
The records discussion has been really complicated and confusing. But
I have a suggestion that should provide a great deal of power to
records, while being mostly[1] backwards-compatible with Haskell 2010.
Consider this example:
data A a = A{a:a, aa::a, aaa :: a - A (a - a)}
data B a = B{aaa :: a - A (a - a), a :: A}
Now what is the type of this?
a a aa = a{a = a, aaa = aa}
Using standard Haskell typeclasses this is a difficult question to
answer. The types of for A and B do not unify in an obvious way.
However, while they are intensionally quite distinct, they unify
trivially extensionally. The obvious thing to do is then to extend the
type system with extensional equality on record functions.
Back when Haskell was invented, extensional equality was thought to be
hard. But purity was thought to be hard too, and so were Monads. Now,
we know that function existentionality is easy. In fact, if we add the
Univalence Axiom to GHC[2], then this is enough to get function
existensionality. This is a well-known result of Homotopy Type
Theory[3], which is a well-explored approach that has existed for at
least a few years and produced more than one paper[4]. Homotopy Type
Theory is so sound and well understood that it has even been
formalized in Coq.
Once we extend GHC with homotopies, it turns out that records reduce
to mere syntactic sugar, and there is a natural proof of their
soundness (Appendix A). Furthermore, there is a canonical projection
for any group of fields (Appendix B). Even better, we can make .
into the identity path operator, unifying its uses in composition and
projection. In fact, with extended (parenthesis-free) section rules,
. can also be used to terminate expressions, making Haskell friendly
not only to programmers coming from Java, but also to those coming
from Prolog!
After some initial feedback, I'm going to create a page for the
Homotopy Extensional Records Proposal (HERP) on trac. There are really
only a few remaining questions. 1) Having introduced homotopies, why
not go all the way and introduce dependent records? In fact, are HERP
and Dependent Extensional Records Proposal (DERP) already isomorphic?
My suspicion is that HERP is isomorphic, but DERP is not. However, I
can only get away with my proof using Scott-free semantics. 2) Which
trac should I post this too? Given how well understood homotopy type
theory is, I'm tempted to bypass GHC entirely and propose this for
haskell-prime. 3) What syntax should we use to represent homotopies?
See extend discussion in Appendix C.
HTH HAND,
Gershom
[1] To be precise, 100% of Haskell 2010 programs should, usually, be
able to be rewritten to work with this proposal with a minimal set of
changes[1a].
[1a] A minimal set of changes is defined as the smallest set of
changes necessary to make to a Haskell 2010 program such that it works
with this proposal. We can arrive at these changes by the following
procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3)
are we done? If not, make another change.
[1b] To do this constructively, we need an order. I suggest the lo
mein, since noodles give rise to a free soda.
[2] I haven't looked at the source, but I would suggest putting it in
the file Axioms.hs.
[3] http://homotopytypetheory.org/
[4] http://arxiv.org/
*Appendix A: A Natural Proof of the Soundness of HERP
Take the category of all types in HERP, with functions as morphisms.
Call it C. Take the category of all sound expressions in HERP, with
functions as morphisms. Call it D. Define a full functor from C to D.
Call it F. Define a faithful functor on C and D. Call it G. Draw the
following diagram.
F(X)F(Y)
| |
| |
| |
G(X)G(Y)
Define the arrows such that everything commutes.
*Appendix
Re: String != [Char]
I am starting up the proposal. http://hackage.haskell.org/trac/haskell-prime/ticket/143 http://hackage.haskell.org/trac/haskell-prime/wiki/OpaqueText Unfortunately I haven't had any time to work on this for the last week and won't for 2 more weeks. Your help is appreciated. I think the first step is to move list functions into a separate module for the Text package to see if we can get rid of name conflicts with the Prelude. On Sat, Mar 31, 2012 at 11:49 PM, Colin Paul Adams co...@colina.demon.co.uk wrote: Gabriel == Gabriel Dos Reis g...@integrable-solutions.net writes: Gabriel On Mon, Mar 26, 2012 at 5:08 AM, Christian Siefkes Gabriel It is not the precision of Char or char that is the issue Gabriel here. It has been clarified at several points that Char is Gabriel not a Unicode character, but a Unicode code point. That's not what the standard says: 6.1.2 Characters and Strings The character type Char is an enumeration whose values represent Unicode characters [2]. [2] Unicode Consortium. Unicode standard. http://unicode.org/standard/standard.html. -- Colin Adams Preston Lancashire () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] A Modest Records Proposal
Hi Gershom,
This sounds very interesting even if I have no idea what you are
talking about :)
Please create a proposal linked from this page:
http://hackage.haskell.org/trac/ghc/wiki/Records
The first thing you should probably do is explain the programmer's
point of view. That ensures that we are all going through the
requirements phase correctly.
I can assure you that haskell prime would not accept a records change
until it is first implemented in GHC or another Haskell compiler.
Thanks,
Greg Weber
On Sat, Mar 31, 2012 at 11:14 PM, Gershom B gersh...@gmail.com wrote:
The records discussion has been really complicated and confusing. But
I have a suggestion that should provide a great deal of power to
records, while being mostly[1] backwards-compatible with Haskell 2010.
Consider this example:
data A a = A{a:a, aa::a, aaa :: a - A (a - a)}
data B a = B{aaa :: a - A (a - a), a :: A}
Now what is the type of this?
a a aa = a{a = a, aaa = aa}
Using standard Haskell typeclasses this is a difficult question to
answer. The types of for A and B do not unify in an obvious way.
However, while they are intensionally quite distinct, they unify
trivially extensionally. The obvious thing to do is then to extend the
type system with extensional equality on record functions.
Back when Haskell was invented, extensional equality was thought to be
hard. But purity was thought to be hard too, and so were Monads. Now,
we know that function existentionality is easy. In fact, if we add the
Univalence Axiom to GHC[2], then this is enough to get function
existensionality. This is a well-known result of Homotopy Type
Theory[3], which is a well-explored approach that has existed for at
least a few years and produced more than one paper[4]. Homotopy Type
Theory is so sound and well understood that it has even been
formalized in Coq.
Once we extend GHC with homotopies, it turns out that records reduce
to mere syntactic sugar, and there is a natural proof of their
soundness (Appendix A). Furthermore, there is a canonical projection
for any group of fields (Appendix B). Even better, we can make .
into the identity path operator, unifying its uses in composition and
projection. In fact, with extended (parenthesis-free) section rules,
. can also be used to terminate expressions, making Haskell friendly
not only to programmers coming from Java, but also to those coming
from Prolog!
After some initial feedback, I'm going to create a page for the
Homotopy Extensional Records Proposal (HERP) on trac. There are really
only a few remaining questions. 1) Having introduced homotopies, why
not go all the way and introduce dependent records? In fact, are HERP
and Dependent Extensional Records Proposal (DERP) already isomorphic?
My suspicion is that HERP is isomorphic, but DERP is not. However, I
can only get away with my proof using Scott-free semantics. 2) Which
trac should I post this too? Given how well understood homotopy type
theory is, I'm tempted to bypass GHC entirely and propose this for
haskell-prime. 3) What syntax should we use to represent homotopies?
See extend discussion in Appendix C.
HTH HAND,
Gershom
[1] To be precise, 100% of Haskell 2010 programs should, usually, be
able to be rewritten to work with this proposal with a minimal set of
changes[1a].
[1a] A minimal set of changes is defined as the smallest set of
changes necessary to make to a Haskell 2010 program such that it works
with this proposal. We can arrive at these changes by the following
procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3)
are we done? If not, make another change.
[1b] To do this constructively, we need an order. I suggest the lo
mein, since noodles give rise to a free soda.
[2] I haven't looked at the source, but I would suggest putting it in
the file Axioms.hs.
[3] http://homotopytypetheory.org/
[4] http://arxiv.org/
*Appendix A: A Natural Proof of the Soundness of HERP
Take the category of all types in HERP, with functions as morphisms.
Call it C. Take the category of all sound expressions in HERP, with
functions as morphisms. Call it D. Define a full functor from C to D.
Call it F. Define a faithful functor on C and D. Call it G. Draw the
following diagram.
F(X)F(Y)
| |
| |
| |
G(X)G(Y)
Define the arrows such that everything commutes.
*Appendix B: Construction of a Canonical Projection for Any Group of Fields.
1) Take the fields along the homotopy to an n-ball.
2) Pack them loosely with newspaper and gunpowder.
3) Project them from a cannon.
In an intuitionistic logic, the following simplification is possible:
1) Use your intuition.
*Appendix C: Homotopy Syntax
Given that we already are using the full unicode set, what syntax
should we use to distinguish paths and homotopies? At first, I thought
we could avoid providing any syntax for homotopies at all. Haskell
Re: [Haskell-cafe] A Modest Records Proposal
Obviously Gregory is not familiar with Homotopy. In fact, its
isomorphism predicts that if someone named Greg is involved in a
discussion, someone named Gregory will also become involved.
Or that is what I get for responding to an e-mail without reading it
on April 1st :)
On Sun, Apr 1, 2012 at 7:40 AM, Gregory Collins g...@gregorycollins.net wrote:
Whoosh? :-)
On Sun, Apr 1, 2012 at 3:54 PM, Greg Weber g...@gregweber.info wrote:
Hi Gershom,
This sounds very interesting even if I have no idea what you are
talking about :)
Please create a proposal linked from this page:
http://hackage.haskell.org/trac/ghc/wiki/Records
The first thing you should probably do is explain the programmer's
point of view. That ensures that we are all going through the
requirements phase correctly.
I can assure you that haskell prime would not accept a records change
until it is first implemented in GHC or another Haskell compiler.
Thanks,
Greg Weber
On Sat, Mar 31, 2012 at 11:14 PM, Gershom B gersh...@gmail.com wrote:
The records discussion has been really complicated and confusing. But
I have a suggestion that should provide a great deal of power to
records, while being mostly[1] backwards-compatible with Haskell 2010.
Consider this example:
data A a = A{a:a, aa::a, aaa :: a - A (a - a)}
data B a = B{aaa :: a - A (a - a), a :: A}
Now what is the type of this?
a a aa = a{a = a, aaa = aa}
Using standard Haskell typeclasses this is a difficult question to
answer. The types of for A and B do not unify in an obvious way.
However, while they are intensionally quite distinct, they unify
trivially extensionally. The obvious thing to do is then to extend the
type system with extensional equality on record functions.
Back when Haskell was invented, extensional equality was thought to be
hard. But purity was thought to be hard too, and so were Monads. Now,
we know that function existentionality is easy. In fact, if we add the
Univalence Axiom to GHC[2], then this is enough to get function
existensionality. This is a well-known result of Homotopy Type
Theory[3], which is a well-explored approach that has existed for at
least a few years and produced more than one paper[4]. Homotopy Type
Theory is so sound and well understood that it has even been
formalized in Coq.
Once we extend GHC with homotopies, it turns out that records reduce
to mere syntactic sugar, and there is a natural proof of their
soundness (Appendix A). Furthermore, there is a canonical projection
for any group of fields (Appendix B). Even better, we can make .
into the identity path operator, unifying its uses in composition and
projection. In fact, with extended (parenthesis-free) section rules,
. can also be used to terminate expressions, making Haskell friendly
not only to programmers coming from Java, but also to those coming
from Prolog!
After some initial feedback, I'm going to create a page for the
Homotopy Extensional Records Proposal (HERP) on trac. There are really
only a few remaining questions. 1) Having introduced homotopies, why
not go all the way and introduce dependent records? In fact, are HERP
and Dependent Extensional Records Proposal (DERP) already isomorphic?
My suspicion is that HERP is isomorphic, but DERP is not. However, I
can only get away with my proof using Scott-free semantics. 2) Which
trac should I post this too? Given how well understood homotopy type
theory is, I'm tempted to bypass GHC entirely and propose this for
haskell-prime. 3) What syntax should we use to represent homotopies?
See extend discussion in Appendix C.
HTH HAND,
Gershom
[1] To be precise, 100% of Haskell 2010 programs should, usually, be
able to be rewritten to work with this proposal with a minimal set of
changes[1a].
[1a] A minimal set of changes is defined as the smallest set of
changes necessary to make to a Haskell 2010 program such that it works
with this proposal. We can arrive at these changes by the following
procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3)
are we done? If not, make another change.
[1b] To do this constructively, we need an order. I suggest the lo
mein, since noodles give rise to a free soda.
[2] I haven't looked at the source, but I would suggest putting it in
the file Axioms.hs.
[3] http://homotopytypetheory.org/
[4] http://arxiv.org/
*Appendix A: A Natural Proof of the Soundness of HERP
Take the category of all types in HERP, with functions as morphisms.
Call it C. Take the category of all sound expressions in HERP, with
functions as morphisms. Call it D. Define a full functor from C to D.
Call it F. Define a faithful functor on C and D. Call it G. Draw the
following diagram.
F(X)F(Y)
| |
| |
| |
G(X)G(Y)
Define the arrows such that everything commutes.
*Appendix
Re: String != [Char]
Can anyone explain how the tangent discussion of the finer points of Unicode and the value of teaching [Char] is relevant to the proposal under discussion? We aren't going to completely eliminate String and break most existing Haskell code as Simon said. String is just a list anyways, and lists are here to stay in Haskell. I would like to get back to working on the proposal and determining how Text can be added to the language. Thank you, Greg weber ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
I would like to get back to working on the proposal and determining how Text can be added to the language. The discussion started because of the question of whether Text should support list processing functions at all, and if so how. That is a very legitimate question related to the Text proposal, at least if you are concerned about correct semantics. Once you are there, the discussion about Unicode characters is unavoidable, and is very much within the scope of discussing Text. Can we take a break from arguing then, and can you create a wiki page that explains how you think Text should behave? This conversation is getting extremely long and repetitive. Can someone please show me how to create a wiki page on the Haskell proposals site (or suggest a different appropriate site)? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
On Sun, Mar 25, 2012 at 5:39 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Sun, Mar 25, 2012 at 6:54 PM, Henrik Nilsson n...@cs.nott.ac.uk wrote: In any case, this is hardly the place to to discuss how to best teach Haskell or programming in general. Sure, I haven't seen any disagreement with that. As interesting as this discussion is, I think this agreement is the perfect segway to take it off list. Debating the usefulness of String = [Char] does not seem to be productive here anyways. What would be helpful is if alternatives were offered, tested out, and shared among the teaching community. If this requires any changes to the language (other than what is being discussed now), please let us know. The Prelude is still going to export list functions whether they are used on [Char] or not. So we are still in the position of requiring qualified imports for Text functions or needing to change the Text package or something about the language to avoid conflicts with list functions. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
Can we all agree that * Text can now demonstrate both CPU and RAM performance improvements in benchmarks. Because Text is an opaque type it has a maximum potential for future performance improvements. Declaring a String to be a list limits performance improvements * In a Unicode world, String = [Char] is not always correct: instead for some operations one must operate on the String as a whole. Using a [Char] type makes it much more likely for a programmer to mistakenly operate on individual characters. Using a Text type allows us to choose to not expose character manipulation functions. * The usage of String in the base libraries will continue as long as Text is not in the language standard. This will continue to make writing Haskell code a greater chore than is necessary: converting between types, and working around the inconvenience of defining typeclasses that operate on both String and []. These are important enough to *try* to include Text into the standard, even if there are objections to how it might practically be included. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
On Sat, Mar 24, 2012 at 7:26 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber g...@gregweber.info wrote: Problem: we want to write beautiful (and possibly inefficient) code that is easy to explain. If nothing else, this is pedagologically important. The goals of this code are to: * use list processing pattern matching and functions on a string type I may have missed this question so I will ask it (apologies if it is a repeat): Why is it believed that list processing pattern matching is appropriate or the right tool for text processing? Nobody said it is the right tool for text processing. In fact, I think we all agreed it is the wrong tool for many cases. But it is easy for students to understand since they are already being taught to use lists for everything else. It would be great if you can talk with teachers of Haskell and figure out a better way to teach text processing. -- Gaby ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
I would really just like for someone to show me how to create a wiki proposal page :) This proposal doesn't have to break any codebases. One possibility is to add the Text type to the standard while keeping String and marking it as deprecated. On Fri, Mar 23, 2012 at 6:13 AM, ARJANEN Loïc Jean David arjanen.l...@gmail.com wrote: 2012/3/22 Greg Weber g...@gregweber.info: I am not trying to win an argument with anyone. Just trying to do what is best for the community. Many others here have a better grasp of the issue than me and can help answer questions and come up with a solution. I am also not saying this proposal is done. A lot of thought and work is needed to ensure it can be implemented as smoothly as possible. It does seem though that everyone thinks it is a good proposal. Sorry for the misunderstanding, but when you said that someone should take this proposal up and help make sure it gets in the next batch, I believed you thought we could take this proposal as is. Deeply sorry for my error. But now we have at least two tasks to do before we can put up the proposal: define what operations should be supported by String and should we apply this proposal in the next batch. Given that this proposal will break many codebases (we shouldn't hope to apply all of list's syntax to this string type) should we apply it alone or wait until we have more other codebase-breakers to apply ? -- ARJANEN Loïc Jean David http://luigiscorner.wordpress.com --- Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes, or chemistry is about beakers and test tubes. Science is not about tools. It is about how we use them, and what we find out when we do. Michael R. Fellows and Ian Parberry ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
Does Python 3 have the equivalent of LANGUAGE pragmas? That is, as a
GHC user i can add {-# LANGUAGE OLD_STRINGS -#} and my program works
with the new language standard!
I think what ruined Perl 6 is that it is still under development!
Avoiding breakage is important. But throwing around comparisons to
Perl 6 is not going to help move the discussion along!
On Fri, Mar 23, 2012 at 6:33 AM, Christian Siefkes
christ...@siefkes.net wrote:
On 03/23/2012 02:13 PM, ARJANEN Loïc Jean David wrote:
2012/3/22 Greg Weber g...@gregweber.info:
But now we have at least two tasks to do before we can put up the
proposal: define what operations should be supported by String and
should we apply this proposal in the next batch. Given that this
proposal will break many codebases (we shouldn't hope to apply all of
list's syntax to this string type) should we apply it alone or wait
until we have more other codebase-breakers to apply ?
I very much hope that the Haskell committee will never ever accept a
proposal that will break many codebases! That's what ruined Perl 6 und
Python 3, and quite unnecessarily so.
Even if I a future Haskell standard defines String as something that doesn't
have to be implemented as a list of Char, it still would have to behave as
if it was [Char] for most practical purposes (except performance-wise, of
course!). That's necessary for compatibility. Or String could just be
complemented with an additional standardized Text type, as Greg suggested.
Best regards
Christian
--
|--- Dr. Christian Siefkes --- christ...@siefkes.net ---
| Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
| Peer Production Everywhere: http://peerconomy.org/wiki/
|-- OpenPGP Key ID: 0x346452D8 --
Just so that nobody takes his guess for the full truth, here's my standing
on keeping control, in 2 words (three?):
I won't.
-- Linus Torvalds, The Tanenbaum-Torvalds Debate
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
This proposal seems fairly uncontroversial at the moment. I would really like it if someone more familiar with the proposal process can take this proposal up and help make sure it gets in the next batch. I can't even figure out how to create a wiki page for the proposal right now :) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
[Haskell-cafe] good lightweight web-framework like sinatra?
WAI has CGI handlers, so you should be able to deploy a WAI-based framework like Yesod to CGI. If you want a simple framework, you can just use WAI directly. Scotty is a WAI framework that mimics Sinatra. Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: String != [Char]
I actually was not able to successfully google for Text vs. String benchmarks. If someone can point one out that would be very helpful. On Sat, Mar 17, 2012 at 1:52 AM, Christopher Done chrisd...@googlemail.com wrote: On 17 March 2012 05:30, Tony Morris tonymor...@gmail.com wrote: Do you know if there is a good write-up of the benefits of Data.Text over String? I'm aware of the advantages just by my own usage; hoping someone has documented it rather than in our heads. Good point, it would be good to collate the experience and wisdom of this decision with some benchmark results on the HaskellWiki as The Place to link to when justifying it. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
This is the best I can do with Bryan's blog posts, but none of the graphs (which contain all the information) show up: http://web.archive.org/web/20100222031602/http://www.serpentine.com/blog/2009/12/10/the-performance-of-data-text/ If someone has some benchmarks that can be ran that would be helpful. On Mon, Mar 19, 2012 at 7:51 AM, Johan Tibell johan.tib...@gmail.com wrote: Hi Greg, There are a few blog posts on Bryan's blog. Here are two of them: http://www.serpentine.com/blog/2009/10/09/announcing-a-major-revision-of-the-haskell-text-library/ http://www.serpentine.com/blog/2009/12/10/the-performance-of-data-text/ Unfortunately the blog seems partly broken. Images are missing and some articles are missing altogether (i.e. the article is there but the actualy body text is gone.) -- Johan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
String != [Char]
the text library and Text data type have shown the worth in real world Haskell usage with GHC. I try to avoid String whenever possible, but I still have to deal with conversions and other issues. There is a lot of real work to be done to convert away from [Char], but I think we need to take it out of the language definition as a first step. I can only see one issue with the proposal: it can be convenient to operate on a list of characters. But I think there are plenty of solutions at our disposal. A simple conversion from Text to a list of characters might suffice. In GHC, OverloadedStrings means users would still be free to use String the same way they are now. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: thoughts on the record update problem
This worries me:
3. The syntax of record updates must be changed to include the class:
r {Rcls| n1 = x1, n2 = x2}
And if I understand correctly this proposal is still uncertain on some
edge cases.
I think it is time to close down the records discussion on the mail
list and ask for an implementation
The implementer should use any means at their disposal, probably by
adding a new construct to the language. However, for now any new
constructs or other implementation details should be kept internal so
that we can maintain flexibility going forward.
A lot of smart people are expending a huge amount of mental effort
discussing how to shoehorn this problem into the existing Haskell
machinery and the fine details of the best way to do it even though
there is still no truly satisfactory solution. I would really like to
see this effort instead go into an implementation.
On Mon, Mar 5, 2012 at 10:59 AM, Greg Weber g...@gregweber.info wrote:
Thanks so much for stepping up and attempting a solution at our big
problem, Barney!
I would ask everyone restrict their comments on this for now solely as
to figuring out whether it makes updates work. There has been a lively
debate about ideal details on a record implementation, but until
updates are solved it is all a moot point.
On Mon, Mar 5, 2012 at 10:36 AM, Barney Hilken b.hil...@ntlworld.com wrote:
There are actually four problems with overloaded record update, not three as
mentioned on the SORF page. This is an attempt to solve them.
The SORF update mechanism.
--
SORF suggests adding a member set to the class Has which does the actual
updating just as get does the selecting. So
set :: Has r f t = t - r - r
and r {n1 = x1, n2 = x2} is translated as
set @ n2 x2 (set @ n1 x1)
The Problems.
-
1. It's not clear how to define set for virtual record selectors. For
example, we might define
data Complex = Complex {re :: Float, im :: Float}
instance Has Complex arg Float where
get r = atan2 r.im r.re
but if we want to set arg, what should be kept constant? The obvious
answer is mod, but we haven't even defined it, and there are plenty of
cases where there is no obvious answer.
2. If the data type has one or more parameters, updates can change the type
of the record. Set can never do this, because of its type. What is more, if
several fields depend on the parameter, for example
data Twice a = Twice {first :: a, second :: a}
any update of first which changes the type must also update second at
the same time to keep the type correct. No hacked version of set can do this.
3. The Haskel implementation of impredicative polymorphism (from the Boxy
Types paper) isn't strong enough to cope with higher rank field types in
instances of set.
4. The translation of multiple updates into multiple applications of set is
not the same as the definition of updates in the Haskel report, where
updates are simultaneous not sequential. This would be less efficient, and
in the case of virtual record selectors, it wouldn't be equal, and is
arguably incorrect.
Point 3 could possibly be fixed by improving the strength of the type
system, but SPJ says this is a hard problem, and no-one else seems ready to
tackle it. Points 1, 2 4 suggest that any solution must deal not with
individual fields but with sets of fields that can sensibly be updated
together.
The Proposed Solution.
--
This is an extension to SORF. I don't know if the same approach could be
applied to other label systems.
1. Introduce a new form of class declaration:
class Rcls r where
r {n1 :: t1, n2 :: t2}
is translated as
class (Has r n1 t1, Has r n2 t2) = Rcls r where
setRcls :: t1 - t2 - r - r
setRcls is used internally but hidden from the user.
2. Instances of record classes can use a special form of default. So
data Rec = Rec {n1 :: t1, n2 :: t2}
instance Rcls Rec
is translated as
instance Rcls Rec where
setRcls x1 y1 (Rec _ _) = Rec x1 y1
provided all the fields in the class occur in the data type with the correct
types. In general, the definition of the update function is the same as the
Haskel98 translation of update, solving problem 4.
3. The syntax of record updates must be changed to include the class:
r {Rcls| n1 = x1, n2 = x2}
is translated as
setRcls x1 x2 r
Updating a subset of the fields is allowed, so
r {Rcls| n1 = x1}
is translated as
setRcls x1 (r.n2) r
4. Non default instances use the syntax:
instance Rcls Rec where
r {Rcls| n1 = x1, n2 = x2} = ...x1..x2..
which is translated as
instance Rcls Rec where
setRcls x1 y1 r = ...x1..x2..
in order to allow virtual selectors. This solves problem 1, because
Re: thoughts on the record update problem
I think it is time to close down the records discussion on the mail list and ask for an implementation The implementer should use any means at their disposal, probably by adding a new construct to the language. However, for now any new constructs or other implementation details should be kept internal so that we can maintain flexibility going forward. A lot of smart people are expending a huge amount of mental effort discussing how to shoehorn this problem into the existing Haskell machinery and the fine details of the best way to do it even though there is still no truly satisfactory solution. I would really like to see this effort instead go into an implementation. This attitude is one I can't even begin to understand. How can you implement something before understanding it? What are you going to implement? Trying to close down discussion when no conclusion has been reached is not the action of a healthy community! Barney. This discussion has largely centered around trying to come up with a hack that desugars to Haskell's existing language constructs. What you are proposing right now may be the most workable solution of that category, but Java programmers still have it far better. The main fruit of this discussion is this realization. There is an alternative to a desugaring hack: add a real record construct to the language. I don't see how any more discussion on this mail list is going to make this happen. And there is nothing to discuss if we hide the implementation details (besides some details of the exposed interface). What we need now are implementers to do actual work on this. Let them choose the path they want rather than be handicapped by us and they can decide if further discussion is needed. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: thoughts on the record update problem
On Thu, Mar 8, 2012 at 12:37 PM, Chris Smith cdsm...@gmail.com wrote: On Thu, Mar 8, 2012 at 1:00 PM, Greg Weber g...@gregweber.info wrote: This discussion has largely centered around trying to come up with a hack that desugars to Haskell's existing language constructs. There is an alternative to a desugaring hack: add a real record construct to the language. I am not sure what distinction you are making between real record construct and desugaring hack. As far as I can see, all major proposals currently desugar to type classes... not as a hack but because type classes *are* how Haskell does type-directed resolution. I don't think there are any ground rules set against proposing a system that doesn't use type classes. If you wanted, you could certainly propose a system that defines brand new and potentially very different semantics for a desired record system from scratch, and has nothing to do with type classes. I tend to think it would be a poor idea, both because it would be a large amount of work to be sure the semantics are even nailed down well, and because then the progress of abstraction over that new construct would happen independently from the existing progress of abstraction over type classes, and we'd end up with a more complex and warty language as a result. In any case, I'm in agreement that stop arguing about semantics and just implement something is a very bad idea. We aren't arguing about implementation choices here; we're arguing about pretty fundamental questions of semantics of records and labels, and the way to settle fundamental questions about the record system we hope to be using in 10 years time is not based on who has time after work for GHC hacking this month. -- Chris Smith Just because Haskell currently resolves its types through type-classes does not mean we are forced to stop at type-classes for every aspect of the implementation. Moreover, with our best proposal here we are left in the peculiar position of declaring victory of resolving through type-classes without annotations, but now requiring a new form of type annotation for all record updates. It would make more sense just to not go full force on the type-class resolution and instead require a normal type annotation. The semantics that will be exposed to users have already been largely decide upon. If we like, we can continue to debate the fine details of the semantics we would like to expose. The problem is that we have been mixing the semantics with the implementation details and using it as an excuse to hold up any implementation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: thoughts on the record update problem
Since it is impossible for anyone to have read and kept in their mind all the discussion that has gone I will fill you in as I know it. We would like the syntax of record updates to be the same as they are today. That is separate from this proposal. This proposal is the only solution so far that works for updates with the desugaring hack and it requires a special form of type annotations instead of using the syntax we would like. Does that make sense? I take it that you agree that we should separate the discussion of semantics from implementation: this is a perfect example of why. On Thu, Mar 8, 2012 at 1:14 PM, Chris Smith cdsm...@gmail.com wrote: On Thu, Mar 8, 2012 at 2:09 PM, Greg Weber g...@gregweber.info wrote: The semantics that will be exposed to users have already been largely decide upon. Admittedly I haven't had time to carefully read some parts of this thread, and if that claim is true, then of course implementation should be the major concern. But it seems unlikely that claim is true, since in the very same email you express what looks like a pretty serious concern about the semantics that will be exposed to users (namely, the need for a new kind of type annotation). -- Chris Smith ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
This is obviously a great concept. However, it may not be appropriate for a GSoC. The design space is far too open, and it is not clear if anything in that space will end up beating plain old javascript. I think my proposal for an awesome websockets library [1] shows that this is putting the cart before the horse. For some of the potential javascript solutions, websockets is a dependency anyways. Without being able to hold open a connection to the server, required server interaction will be too slow. Yesod has been successful by explicitly avoiding any new radical paradigms, but by instead just trying to get the basics of web development established correctly. Without websockets, we don't have the basics down for fluid client-side interaction. The groundwork for this ticket has been laid: it should be easy to accomplish with time left over. So we are guaranteed a clear win for the community. With the time left over, a solution to the javascript problem can be attempted. But there is no burden for it to be solved within the summer. Next year the landscape will be more mature and we can try to come up with a solid proposal for the javscript problem if the community hasn't already created a solution. [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
On Wed, Mar 7, 2012 at 11:47 AM, Alejandro Serrano Mena trup...@gmail.com wrote: I agree with you that maybe this proposal is vague for a GSoC, but I don't think that websockets is a good option either, because not all browsers support them. We already have a websockets library, but like you say it is not very useful by itself because it may not be supported in all browsers. The GSoC proposal is to create a library that will use appropriate fallbacks on all browsers, which is how websockets are normally used. 2012/3/7 Greg Weber g...@gregweber.info This is obviously a great concept. However, it may not be appropriate for a GSoC. The design space is far too open, and it is not clear if anything in that space will end up beating plain old javascript. I think my proposal for an awesome websockets library [1] shows that this is putting the cart before the horse. For some of the potential javascript solutions, websockets is a dependency anyways. Without being able to hold open a connection to the server, required server interaction will be too slow. Yesod has been successful by explicitly avoiding any new radical paradigms, but by instead just trying to get the basics of web development established correctly. Without websockets, we don't have the basics down for fluid client-side interaction. The groundwork for this ticket has been laid: it should be easy to accomplish with time left over. So we are guaranteed a clear win for the community. With the time left over, a solution to the javascript problem can be attempted. But there is no burden for it to be solved within the summer. Next year the landscape will be more mature and we can try to come up with a solid proposal for the javscript problem if the community hasn't already created a solution. [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: thoughts on the record update problem
Thanks so much for stepping up and attempting a solution at our big
problem, Barney!
I would ask everyone restrict their comments on this for now solely as
to figuring out whether it makes updates work. There has been a lively
debate about ideal details on a record implementation, but until
updates are solved it is all a moot point.
On Mon, Mar 5, 2012 at 10:36 AM, Barney Hilken b.hil...@ntlworld.com wrote:
There are actually four problems with overloaded record update, not three as
mentioned on the SORF page. This is an attempt to solve them.
The SORF update mechanism.
--
SORF suggests adding a member set to the class Has which does the actual
updating just as get does the selecting. So
set :: Has r f t = t - r - r
and r {n1 = x1, n2 = x2} is translated as
set @ n2 x2 (set @ n1 x1)
The Problems.
-
1. It's not clear how to define set for virtual record selectors. For
example, we might define
data Complex = Complex {re :: Float, im :: Float}
instance Has Complex arg Float where
get r = atan2 r.im r.re
but if we want to set arg, what should be kept constant? The obvious answer
is mod, but we haven't even defined it, and there are plenty of cases where
there is no obvious answer.
2. If the data type has one or more parameters, updates can change the type
of the record. Set can never do this, because of its type. What is more, if
several fields depend on the parameter, for example
data Twice a = Twice {first :: a, second :: a}
any update of first which changes the type must also update second at the
same time to keep the type correct. No hacked version of set can do this.
3. The Haskel implementation of impredicative polymorphism (from the Boxy
Types paper) isn't strong enough to cope with higher rank field types in
instances of set.
4. The translation of multiple updates into multiple applications of set is
not the same as the definition of updates in the Haskel report, where updates
are simultaneous not sequential. This would be less efficient, and in the
case of virtual record selectors, it wouldn't be equal, and is arguably
incorrect.
Point 3 could possibly be fixed by improving the strength of the type system,
but SPJ says this is a hard problem, and no-one else seems ready to tackle
it. Points 1, 2 4 suggest that any solution must deal not with individual
fields but with sets of fields that can sensibly be updated together.
The Proposed Solution.
--
This is an extension to SORF. I don't know if the same approach could be
applied to other label systems.
1. Introduce a new form of class declaration:
class Rcls r where
r {n1 :: t1, n2 :: t2}
is translated as
class (Has r n1 t1, Has r n2 t2) = Rcls r where
setRcls :: t1 - t2 - r - r
setRcls is used internally but hidden from the user.
2. Instances of record classes can use a special form of default. So
data Rec = Rec {n1 :: t1, n2 :: t2}
instance Rcls Rec
is translated as
instance Rcls Rec where
setRcls x1 y1 (Rec _ _) = Rec x1 y1
provided all the fields in the class occur in the data type with the correct
types. In general, the definition of the update function is the same as the
Haskel98 translation of update, solving problem 4.
3. The syntax of record updates must be changed to include the class:
r {Rcls| n1 = x1, n2 = x2}
is translated as
setRcls x1 x2 r
Updating a subset of the fields is allowed, so
r {Rcls| n1 = x1}
is translated as
setRcls x1 (r.n2) r
4. Non default instances use the syntax:
instance Rcls Rec where
r {Rcls| n1 = x1, n2 = x2} = ...x1..x2..
which is translated as
instance Rcls Rec where
setRcls x1 y1 r = ...x1..x2..
in order to allow virtual selectors. This solves problem 1, because updates
are grouped together in a meaningful way. An extended example is given below.
5. Record classes can have parameters, so
class TwiceClass r where
r a {first :: a, second :: a}
data Twice a = Twice {first :: a, second :: a}
instance TwiceClass Twice
translates as
class TwiceClass r where
setTwiceClass :: a - a - r b - r a
data Twice a = Twice {first :: a, second :: a}
instance TwiceClass Twice where
setTwiceClass x y (Twice _ _) = Twice x y
which allows updates to change the type correctly. This solves problem 2.
6. Problem 3 *almost* works. The translation of
class HRClass r where
r {rev :: forall a. [a] - [a]}
is
class Has r rev (forall a. [a] - [a]) = HRClass r where
setHRClass :: (forall a.[a] - [a]) - r - r
which is fine as far as updating is concerned, but the context is not
Re: Records in Haskell
The DORF proposal is bringing to light some universal issues with records, so I am glad they are being hashed out. However, at this point it is premature optimization: we still don't have a proposal that solves the narrow issue of record name-spacing with Haskell. At this point SORF/DORF need a hero to figure out how to make them work with all of Haskell's current type capabilities. The DORF proposal makes some steps forward, but also backwards: it only solves the narrow name-spacing issue within a module. If a record is imported into another module, it will still clash. I stated this months ago, and I think it is even truer now: the sugar approach to records does not appear to actually be simplifying things, therefore we should consider adding a new first-class construct. I don't know much about the subject of first-class records, but so far I have come across a few styles of existing implementations in FP: structural typing, records as modules, and row types. I recently linked to Ur's extensible record impementation (that uses row types) from the wiki: http://adam.chlipala.net/papers/UrPLDI10/UrPLDI10.pdf We are trying to stay focused on the narrow issue of solving name-spacing. I think we can stay narrow if we do implement first class records but hold off for now on presenting any special capabilities to the programmer. At this point we are months into the records process without a clear way forward. I think we should be willing to take any workable implementation and just avoid exposing the implementation details for now. If anyone can lend a hand at figuring out SORF updates or determining if type inference of records in the Ur paper can be made to work in Haskell, that would be very helpful! Greg Weber On Sun, Feb 26, 2012 at 7:01 AM, Jerzy Karczmarczuk jerzy.karczmarc...@unicaen.fr wrote: Barney Hilken : Haskel is supposed to be a theoretically sound, cleanly designed language, and if we lose sight of this we might as well use C++. Well, since I have nothing to say about new records, I don't say anything, but I have the impression that when we got to this level of discussion, it is a beginning of the end. Veeery, very funny... Imagine an ecclesiastic General Council, and the Pope saying: Brothers Bishops! Our new dogmas must be absolutely flawless, pure and sound, otherwise we might as well become Muslims. Inchaa whatever. Jerzy Karczmarczuk Caen, France ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
I looked at the DORF implementers view
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/ImplementorsView
It appears that we still have no solution for record updates that
change the type of a polymorphic field.
I think this means we need to look to ways to solve this update issue
other than just de-sugaring to typeclasses.
On Thu, Feb 23, 2012 at 5:01 PM, Greg Weber g...@gregweber.info wrote:
On Thu, Feb 23, 2012 at 4:25 PM, AntC anthony_clay...@clear.net.nz wrote:
Greg Weber greg at gregweber.info writes:
Thanks to Anthony for his DORF proposal, and spending time to clearly
explain it on the wiki.
I have a big issue with the approach as presented - it assumes that
record fields with the same name should automatically be shared. As I
have stated before, to avoid circular dependencies, one is forced to
declare types in a single module in Haskell that would ideally be
declared in a multiple modules. ...
Thanks Greg, but I'm struggling to understand what the difficulty is with
sharing the same name, or why your dependencies are circular. Would you be
able to post some code snippets that illustrate what's going on (or what's
failing to go on)?
Or perhaps this is an experience from some application where you weren't
using
Haskell? Could you at least describe what was in each record type?
You can get an idea of things in the section 'Problems with using the
module namespace mechanism' here:
http://hackage.haskell.org/trac/ghc/wiki/Records?version=4
The attachment that Chris Done left to demonstrate his types seems to
be overwritten.
I will bring back his text as it seems his point does need to be driven home.
A lot of Haskell projects have a separate Types module to avoid issues
with circular dependencies.
Continuing the database example, I
will have multiple tables with a 'name' column, but they do not have
the same meaning.
If I have a function:
helloName person = Hello, ++ person.name
The compiler could infer that I want to say hello to inanimate objects!
So the first question is:
* do your fields labelled `name` all have the same type? (Perhaps all
String?)
* what meaning does a name have beyond being a String?
Your code snippet doesn't give the types, but if I guess that you intend
`person` to be of type `Person`. Then you can give a signature:
helloName :: Person - String
If person can be 'anything' then the type inferred from the bare function
equation would be:
helloName :: r{ name :: String } = r - String
So you could say hello to your cat, and your pet rock. You couldn't say hello
to a pile of bricks (unless it's been given a name as an art installation in
the Tate Gallery ;-)
Of course we know that we can always add type annotations to clarify
things. The question is whether we want to be opt-out and have to
explain people that they can end up with weakly typed code when they
don't want to share fields.
Note that I am not completely against abstraction over fields, I just
don't think it is the best default behavior.
So what is the best default behaviour, and what is the range of other
behaviours you want to support?
I believe the best default is to not share fields, but instead have
the programmer indicate at or outside of the record definition that
they want to share fields. Basically just use type-classes how they
are used now - as opt-in. But I am OK with making an especially easy
way to do this with records if the current techniques for defining
typeclasses are seen as to verbose.
And the section Modules and qualified names for records shows that
the proposal doesn't fully solve the name-spacing issue.
I think it shows only that record field labels can run into accidental name
clash in exactly the same way as everything else in Haskell (or indeed in any
programming language). And that Haskell has a perfectly good way for dealing
with that; and that DORF fits in with it.
Greg, please give some specific examples! I'm trying to understand, but I'm
only guessing from the fragments of info you're giving.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Actually, I looked at the SORF page again: http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields There is now an 'Alternative Proposal' section that claims to solve polymorphic update. If anyone has comments on this please let us know! So my proposal would be to somehow use the SORF Alternative Proposal to allow for name-spaced records. This should be used to generate internal constraints and not be exposed to the end user and not automatically abstract over fields. This leaves all of our future options open while satisfying the narrow issue at hand. On Fri, Feb 24, 2012 at 9:27 AM, Greg Weber g...@gregweber.info wrote: I looked at the DORF implementers view http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/ImplementorsView It appears that we still have no solution for record updates that change the type of a polymorphic field. I think this means we need to look to ways to solve this update issue other than just de-sugaring to typeclasses. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken b.hil...@ntlworld.com wrote: This should be used to generate internal constraints and not be exposed to the end user and not automatically abstract over fields. Every one of your messages about records stresses your dislike for polymorphic projections, and your insistence that the Has class should be hidden from the user. I've read all of your explanations, but I'm still totally unconvinced. All your arguments about the semantics of labels are based on the way you want to use them, not on what they are. They are projection functions! Semantically, the only difference between them is the types. Polymorphism makes perfect sense and is completely natural. There is nothing untyped about it. I feel you are pushing a narrow personal agenda here. I think the Has class would be useful to programmers and no harder to understand than other Haskel classes. It should not be hidden. Barney, these kinds of statements about personal agenda are counterproductive. I have put in a lot of work that nobody, including yourself has been willing to do for years to push Haskell's records forward. I would appreciate respectful disagreement - I think I have earned that much. Please just stick to logical arguments. Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
No, I don't think anybody has a satisfactory approach to updating polymorphic/higher-ranked fields. (DORF mentions one, but it's a ghastly hack. So are the proposals dead until this is tackled, or should SORF/DORF propose not to allow that? What on earth do you mean by not automatically abstract over fields? Abstraction over fields is the ability to write a function that works on two records with the same field label. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Sorry for getting offended! I agree with your sentiment, which is why I thought having to write an extra word in a Record declaration to get automatic abstraction over fields was a good solution to the problem. But now I am in the position of being the lone dissenter on automatic abstraction over fields. And I am in disagreement with SPJ, and I would gladly drop this entire process and just ask him to be a benevolent dictator on the subject. So I am ok with automatic abstraction over fields. Ideally we should have a way to disable it, just as I was proposing we have a way to enable it. But perhaps having this will help force a solution to the circular references issues that makes automatic field abstraction problematic in the first place. After all, Haskell did start with barely any way to do IO. On Fri, Feb 24, 2012 at 2:26 PM, Barney Hilken b.hil...@ntlworld.com wrote: I'm sorry Greg, I didn't mean to be offensive. I just feel that all your arguments in favour of this restriction are based on one particular application of records, rather than a general notion of what records are. Obviously this application is what motivates you to do all the valuable work you have done, and I appreciate that. But people are going to use records in many different ways, and I don't think that a restriction which makes perfect sense in your application should be allowed to restrict the ways other people want to write programs. Barney. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On Thu, Feb 23, 2012 at 4:25 PM, AntC anthony_clay...@clear.net.nz wrote:
Greg Weber greg at gregweber.info writes:
Thanks to Anthony for his DORF proposal, and spending time to clearly
explain it on the wiki.
I have a big issue with the approach as presented - it assumes that
record fields with the same name should automatically be shared. As I
have stated before, to avoid circular dependencies, one is forced to
declare types in a single module in Haskell that would ideally be
declared in a multiple modules. ...
Thanks Greg, but I'm struggling to understand what the difficulty is with
sharing the same name, or why your dependencies are circular. Would you be
able to post some code snippets that illustrate what's going on (or what's
failing to go on)?
Or perhaps this is an experience from some application where you weren't using
Haskell? Could you at least describe what was in each record type?
You can get an idea of things in the section 'Problems with using the
module namespace mechanism' here:
http://hackage.haskell.org/trac/ghc/wiki/Records?version=4
The attachment that Chris Done left to demonstrate his types seems to
be overwritten.
I will bring back his text as it seems his point does need to be driven home.
A lot of Haskell projects have a separate Types module to avoid issues
with circular dependencies.
Continuing the database example, I
will have multiple tables with a 'name' column, but they do not have
the same meaning.
If I have a function:
helloName person = Hello, ++ person.name
The compiler could infer that I want to say hello to inanimate objects!
So the first question is:
* do your fields labelled `name` all have the same type? (Perhaps all String?)
* what meaning does a name have beyond being a String?
Your code snippet doesn't give the types, but if I guess that you intend
`person` to be of type `Person`. Then you can give a signature:
helloName :: Person - String
If person can be 'anything' then the type inferred from the bare function
equation would be:
helloName :: r{ name :: String } = r - String
So you could say hello to your cat, and your pet rock. You couldn't say hello
to a pile of bricks (unless it's been given a name as an art installation in
the Tate Gallery ;-)
Of course we know that we can always add type annotations to clarify
things. The question is whether we want to be opt-out and have to
explain people that they can end up with weakly typed code when they
don't want to share fields.
Note that I am not completely against abstraction over fields, I just
don't think it is the best default behavior.
So what is the best default behaviour, and what is the range of other
behaviours you want to support?
I believe the best default is to not share fields, but instead have
the programmer indicate at or outside of the record definition that
they want to share fields. Basically just use type-classes how they
are used now - as opt-in. But I am OK with making an especially easy
way to do this with records if the current techniques for defining
typeclasses are seen as to verbose.
And the section Modules and qualified names for records shows that
the proposal doesn't fully solve the name-spacing issue.
I think it shows only that record field labels can run into accidental name
clash in exactly the same way as everything else in Haskell (or indeed in any
programming language). And that Haskell has a perfectly good way for dealing
with that; and that DORF fits in with it.
Greg, please give some specific examples! I'm trying to understand, but I'm
only guessing from the fragments of info you're giving.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Thanks to Anthony for his DORF proposal, and spending time to clearly explain it on the wiki. I have looked over the main page: http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields I have a big issue with the approach as presented - it assumes that record fields with the same name should automatically be shared. As I have stated before, to avoid circular dependencies, one is forced to declare types in a single module in Haskell that would ideally be declared in a multiple modules. Continuing the database example, I will have multiple tables with a 'name' column, but they do not have the same meaning. If I have a function: helloName person = Hello, ++ person.name The compiler could infer that I want to say hello to inanimate objects! Note that I am not completely against abstraction over fields, I just don't think it is the best default behavior. And the section Modules and qualified names for records shows that the proposal doesn't fully solve the name-spacing issue. On Sat, Feb 11, 2012 at 9:43 PM, wren ng thornton w...@freegeek.org wrote: On 2/11/12 9:47 AM, Greg Weber wrote: What is the use case for changing the type of a record field on update? I use it all the time. One may just as well ask: What is the use case for changing the type of a Maybe on update? Or what is the use case for changing only one of the types for a tuple update? Records are no different from any other polymorphic data type. We don't require special syntax for changing Maybe A to Maybe B nor for changing (A,B) to (A,C), so why should we treat records any differently? One particular use case is for records with phantom types. For example, say I have a large record which contains both real data and also some memoization caches for common queries. I don't want to have to recompute the caches every time I make a small change to the data, instead I'd like to just be able to flip a type-level bit that says now the caches are dirty. This way I can make a bunch of small changes to the main data, and then only once that is completed I will recompute the caches (because all the querying functions require that the type-level bit says the caches are clean/up-to-date). There are, of course, non-phantom examples as well. For instance, consider a record type for dealing with both sound and unsound versions of some kind of yucky data. For example, dealing with commandline argument handling. For the first stage of handling we just want to store the raw Strings (or [String]s, Maybe Strings,...); but then we'll want to parse those strings into ADTs and also perform some sanity checks to make sure the whole configuration is sane. One option of doing this is to have our record parametrized by the types of the fields, so we're converting from (Yuck String String ...) into (Yuck Bool (Maybe (Int,Float)) ...). For both of these examples it would be possible to monomorphize things to have DataDirty/DataClean or YuckRaw/YuckSane. For the latter example, that's probably a better choice; but for the former example it is demonstrably inferior. And of course it is easy to construct additional examples where monomorphization is not actually feasible. The reason to do this sort of thing as polymorphic records is so that you can simultaneously have some functions which care about the type parameters, and other functions which do not. Without type-changing updates the only way to achieve this is with some convoluted hack like defining a type class over all the monomorphic records (and duplicating all the neigh-identical record definitions), or using data families which are non-portable. Neither of those hacks says what you mean, and both require much more sophisticated type analysis than just using type-changing update for records. Type-changing update should not be removed, and rendering it into something distinct from type-unchanging record update is only coherent for phantom type uses of type changes and so cannot apply to non-phantom uses. -- Live well, ~wren ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Subject: A universal data store interface
Hi Deian, Thanks for bringing this to our attention - this is a neat project! It actually looks *exactly* like persistent - I can't actually discern a meaningful difference, although likely your internals are slightly simpler if you only support MongoDB. If your goals are to support multiple backends then it seems your goals are *exactly* the same as Persistent. Lets collaborate on this off of the mail list. The url listed on hackage for the git repo points to Stanford, not github. Greg Weber On Tue, Feb 14, 2012 at 11:17 AM, Deian Stefan haskell-c...@deian.net wrote: On Mon, Feb 13, 2012 at 11:52, Greg Weber g...@gregweber.info wrote: That being said, I would like to have a Template Haskell interface instead of just a QQ interface. The reason why we haven't bothered with doing that ourselves is because the record name-spacing issue makes the current QQ interface much more convenient. I am actively working to solve the namespace issue. This all brings up a great point though: as part of the GSoC we should create a Template Haskell interface (similar to acid-state as you mention). Given the structure of things that Michael has already pointed out, and that we are already using Template Haskell with the DSL, this should only be a few day's work. I'm joining this thread slightly late, but thought I point to a similar TH approach: http://hackage.haskell.org/package/structured-mongoDB The implementation is very much MongoDB-specific, but we're working on targeting different backends (package is on github, so we welcome other hackers). Of course, some of the issues that have been brought up (e.g., no support for projection) still exist in structured-mongoDB, but our goals have been more relaxed: 1) provide a type-safe interface to MongoDB, 2) to avoid QQ DSL approach if possible, and 3) support a HaskellDB-like query interface. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Subject: A universal data store interface
Hi Sergiu, Thanks you for your interest in that proposal. I rushed it off a year ago. Since then we have made a lot of improvements to Persistent and the library forms a basic building block for most Yesod users and other Haskellers. Persistent offers a level of type-safety and convenience not available elsewhere (except perhaps for libraries like acid-state that are limited to in-memory storage). That being said, there are still a lot of improvements that could be made. With the effort of a GSoC volunteer we could probably get it to the point of being the go-to data storage library for Haskellers, at least those planning on using the subset of backends (likely SQL) with great support. This proposal is vague and we would need to work with you to narrow things down a bit. I am biased, but I believe the Yesod project is one of the most compelling in the Haskell ecosystem. There are a lot of different ways a GSoC project could help make things even better besides improving the associated Persistent library, and we would really like to mentor at least one GSoC student. I would open more tickets for this in the system, but I am not sure how helpful it will be. It seems that we need to reach out to more students like yourself, but I am not sure how to do that unless I see messages like these first. Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
Persistent is a database abstraction layer with no dependencies on Yesod. Those that need a persistence layer have the same needs to interface with the database in a type-safe way, regardless of whether their program presents a web interface. Have you tried using Persistent? We have never heard a report from a user that the Persistent DSL schema syntax is confusing. These complaints always seem to be from someone that hasn't actually tried it but is adverse to quasi-quoting. The DSL is basically the exact same as Haskell record syntax. I am not sure who the mythical users are that can figure out Haskell but can't understand dead-simple DSL's. That being said, I would like to have a Template Haskell interface instead of just a QQ interface. The reason why we haven't bothered with doing that ourselves is because the record name-spacing issue makes the current QQ interface much more convenient. I am actively working to solve the namespace issue. This all brings up a great point though: as part of the GSoC we should create a Template Haskell interface (similar to acid-state as you mention). Given the structure of things that Michael has already pointed out, and that we are already using Template Haskell with the DSL, this should only be a few day's work. On Mon, Feb 13, 2012 at 11:40 AM, Tom Murphy amin...@gmail.com wrote: It seems that all tutorials and resources for Persistent use Template Haskell along with several Yesod specifics. But, I could be wrong, or new tutorials could be written. Tom On 2/13/12, Michael Snoyman mich...@snoyman.com wrote: Actually, Persistent is fully usable without any special syntax, DSLs, or Template Haskell. In fact, Persistent itself has no template-haskell dependencies, specifically so that it can be built on ghc-iphone. Additionally, the Persistent DSL syntax is completely separate from any other Yesod DSL syntaxes that exist, so it's not like you have to learn five new things to get the automatic code generation. On Mon, Feb 13, 2012 at 9:30 PM, Tom Murphy amin...@gmail.com wrote: With respect, I don't think that Persistent is a natural choice as the go-to tool for Haskell users, simply because it requires knowledge of a lot of Yesod-EDSL syntax. The set of users with persistent data needs seems a very different set than that of those who are familiar with Yesod, and I think the syntax is quite confusing without fuller understanding of Yesod. The syntax of acid-state (not familiar with this one), and swapper (https://github.com/roman-smrz/swapper/blob/master/test/) seem to have a much more linear learning curve for an intermediate Haskell user. amindfv / Tom On 2/13/12, Greg Weber g...@gregweber.info wrote: Hi Sergiu, Thanks you for your interest in that proposal. I rushed it off a year ago. Since then we have made a lot of improvements to Persistent and the library forms a basic building block for most Yesod users and other Haskellers. Persistent offers a level of type-safety and convenience not available elsewhere (except perhaps for libraries like acid-state that are limited to in-memory storage). That being said, there are still a lot of improvements that could be made. With the effort of a GSoC volunteer we could probably get it to the point of being the go-to data storage library for Haskellers, at least those planning on using the subset of backends (likely SQL) with great support. This proposal is vague and we would need to work with you to narrow things down a bit. I am biased, but I believe the Yesod project is one of the most compelling in the Haskell ecosystem. There are a lot of different ways a GSoC project could help make things even better besides improving the associated Persistent library, and we would really like to mentor at least one GSoC student. I would open more tickets for this in the system, but I am not sure how helpful it will be. It seems that we need to reach out to more students like yourself, but I am not sure how to do that unless I see messages like these first. Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
things even better besides improving Greg the associated Persistent library, and we would really like to mentor Greg at least one GSoC student. I would open more tickets for this in the Greg system, but I am not sure how helpful it will be. It seems that we Greg need to reach out to more students like yourself, but I am not sure Greg how to do that unless I see messages like these first. Greg Greg Weber -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
This proposal is vague and we would need to work with you to narrow things down a bit. Yes, that would be cool :-) Since I'm not familiar with Persistence at all (unfortunately :-( ), do you have some suggestions for me to start with? I've found this http://www.yesodweb.com/book/persistent and I'm going to get familiar with it in the first place. I hope it won't take me much longer than a couple days. That is definitely the best place to start. If you want to look at more example usage code you can look at the test suite in the persistent-test folder of the repository. Perhaps you have a Haskell program that could benefit from persisting data (and maybe already does in a flat file) and you could try integrating Persistent with it. I am rather far away from Web programming, so, unfortunately, I am not sure whether it would be relevant if I volunteered to contribute to Yesod directly. In my perspective, there are possibilities for a non-Web programmer to contribute to Yesod, though, so, if I am not too much off with my perspectives, I'll be glad to work on Yesod as well. I also opened up a GSoC ticket for making Haskell ready for the real-time web. This is also another somewhat self-contained project that does not really require web development experience. More and more programs would like to have a web interface or at least speak some HTTP at some point. Most web programmers don't have a great understanding of the internals of web development that they are abstracted from. I wouldn't shy away from something web related because you are afraid you won't be able to hack it. The only problem would be that you might not be able to judge the project well before starting the project. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How do I get official feedback (ratings) on my GSoC proposal?
Other than changing the status myself, how do I get a priority attached to my GSoC proposal? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How do I get official feedback (ratings) on my GSoC proposal?
http://hackage.haskell.org/trac/summer-of-code/report/1 There is a column 'Priority'. And there are now several unrated proposals. On Mon, Feb 13, 2012 at 3:40 PM, Johan Tibell johan.tib...@gmail.com wrote: On Mon, Feb 13, 2012 at 3:20 PM, Greg Weber g...@gregweber.info wrote: Other than changing the status myself, how do I get a priority attached to my GSoC proposal? What priorities are you referring to? -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Proposal: require spaces around the dot operator
I am sorry that I made the huge mistake in referencing future possible proposals. If this proposal passes, that has no bearing on whether the other proposals would pass, it just makes them possible. Please help me fix my error by stopping all discussions of future proposals and focusing solely on the one at hand. Thank you! Greg Weber On Sat, Feb 11, 2012 at 5:39 PM, Roman Leshchinskiy r...@cse.unsw.edu.au wrote: On 12/02/2012, at 01:29, Nate Soares wrote: If - was introduced for accessing fields, we'd have to discuss whether it should have spaces around it. I'd lean towards requiring that it have no spaces when used for field access, for symmetry with . when used for module access. I'm not spaces matter in this case, - is a reserved token so we would just have expressions of the form expr - field with no special lexical rules. BTW, if - doesn't work for some reason then there is also = which AFAIK isn't used in expressions at all currently. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Proposal: require spaces around the dot operator
Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the usage of the unspaced dot as a record field selector as shown in proposal #129. After this proposal shows clear signs of moving forward I will add a proposal to support a unicode dot for function composition. After that we can all have a lively discussion about how to fully replace the ascii dot with an ascii alternative such as ~ or After that we can make the dot operator illegal by default. This has already been discussed as part of a records solution on the ghc-users mail list and documented here: http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
There are 2 compelling reasons I know of to prefer dot for record access 1) follows an almost universal convention in modern programming languages 2) is consistent with using the dot to select functions from module name-spaces We can have a lot of fun bike-shedding about what operator we would prefer were these constraints not present. Personally I wouldn't care. However, I find either one of these 2 points reason enough to use the dot for record field access, and even without a better record system the second point is reason enough to not use dot for function composition. It is somewhat convenient to argue that it is too much work and discussion for something one is discussing against. The only point that should matter is how existing Haskell code is effected. On Thu, Feb 9, 2012 at 8:27 PM, Daniel Peebles pumpkin...@gmail.com wrote: I'm very happy to see all the work you're putting into the record discussion, but I'm struggling to see why people are fighting so hard to get the dot character in particular for field access. It seems like a huge amount of work and discussion for a tiny bit of syntactic convenience that we've only come to expect because of exposure to other very different languages. Is there some fundamental reason we couldn't settle for something like # (a valid operator, but we've already shown we're willing to throw that away in the MagicHash extension) or @ (only allowed in patterns for now)? Or we could even keep (#) as a valid operator and just have it mean category/lens composition. Thanks, Dan On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber g...@gregweber.info wrote: Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the usage of the unspaced dot as a record field selector as shown in proposal #129. After this proposal shows clear signs of moving forward I will add a proposal to support a unicode dot for function composition. After that we can all have a lively discussion about how to fully replace the ascii dot with an ascii alternative such as ~ or After that we can make the dot operator illegal by default. This has already been discussed as part of a records solution on the ghc-users mail list and documented here: http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Some thoughts on Type-Directed Name
Hi guys, There is an effort underway to make Haskell's Records better. The discussion is ongoing on the ghc-users mail list, feel free to join, or at least read on gmane. The wiki pages are up to date. Please note that we are moving in the direction of making the most minimal changes possible to achieve some simple record name-spacing. Thanks, Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Records in Haskell
The starting point a new records implementation was to be pragmatic and get something done. Simon has identified that Has constraints are required to implement records. However, in general, exposing an internal implementation to a user is an idea that should give great pause. It makes it difficult to switch implementations in the future, and there is likely a more ideal interface for the end user - I believe that is the case for Has constraints. So I propose we move forward with implementing Has constraints, but do not expose it to the user (similar to TDNR). We don't add abstraction over fields or virtual fields or any special capabilities that would expose the implementation. After we have a working records implementation that meets our goal of solving name-spacing, we can re-visit what the best interface is to present to the user for more advanced records capabilities. There were complaints about TDNR previously. I think we can address them by noting that we are limiting the scope to just records and that it is just a beginning that will not limit us. With this in mind, what limitations are left? are updates still a problem, and can we solve it (for now at least) by being more demanding of type annotations? Greg Weber On Fri, Jan 20, 2012 at 3:22 PM, Greg Weber g...@gregweber.info wrote: 2012/1/18 Simon Peyton-Jones simo...@microsoft.com: | Has *is* a type class. It can be used and abused like any other. | Record members with the same key ought to have the same semantics; the | programmer must ensure this, not just call them all x or the like. | | Weak types these are not. The selector type is well-defined. The value | type is well-defined. The record type is well-defined, but of course | we define a type-class to let it be polymorphic. I want to mention that the issue Greg raises here is tackled under Representation hiding. The way we currently prevent random clients of a data type from selecting its foo field is by hiding the record selector foo. Similarly for its data constructors. This is Haskell's way of doing data abstraction; it may not be the best way, but it's Haskell's way. The trouble with instance declarations is that they are *always* exported. No hiding. Under Representation hiding I suggest that * If the record selector foo is in scope (by any name), then the corresponding Has instance is in scope too and vice versa. That would match up with Haskell's hiding mechanisms precisely, albeit at the cost of having an ad-hoc rule for Has instances. Simon I am not just concerned about Has instances from modules not under my control. I am concerned there is a new implicit rule that must be explained to me and that I have no control over: that every record field in the same module with a given label must have the exact same semantics as all others with the same label. Currently we don't have this rule. Currently we have records with the essentialy the same field labels, but with prefixes so they can coexist, and they need not have the same semantics. There is an extra problem with adding this rule: it is common practice to put types that arguably should be spread across multiple modules into one (module often named Types). Some form of this must be done out of necessity in the case of circular references between types that will otherwise not resolve. By default in Yesod, we do this out of necessity for records representing database tables. We call the module Models and users are free to write functions there. Now we have to explain to them that they should not. What use case for abstraction over record fields is too burdensome to use a type class for? Lacking such a compelling use case we are adding implicit complexity that can result in weak-typing for the unwary user with no compelling benefit. The wiki page for overloaded records suggests that users are expected to write code like this for virtual selectors: instance Has Shape area Float where get = area This is a leaky abstraction forcing me to quote function names at the type level. I would rather not be writing this code - explaining this code to someone means delving into implementation details that I don't understand. The overloaded records proposal is vying for extensibility by supporting abstraction over record fields with the same name. For this dubious use case that type classes already satisfies we lose user-friendly implementation of obviously useful functionality like virtual selectors, and also explainability. There is something to be said for the fact that I can quickly comprehend explanations of module-based record systems. I have read over the Overloaded Records proposal several times now and I have the gist of it, but I am still confused on details and need another couple reads to look at all the details instead of glossing over them. So far I have found some details on record implementations in four FP languages
Re: Records in Haskell
Thank you Nils for those excellent links. Yitz would like Agda's module/record setup which allows for multiple modules in a single file. Records are yet another local module. The neat thing is, that like any module you can open it, or put it into the scope of your current module for convenient use that avoids the needs for qualifiers (see Record opening example). Johan, I think Agda's use of records might also be what you are getting at. On Tue, Jan 17, 2012 at 7:10 AM, Nils Anders Danielsson n...@chalmers.se wrote: On 2012-01-16 19:16, Yitzchak Gale wrote: Allow nested modules. [...] Perhaps Agda's module/record system can provide some inspiration: http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Modules http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Records (I don't think the wiki pages above are entirely complete/up to date, but for the purposes of this discussion they should do.) -- /NAD ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
2012/1/18 Simon Peyton-Jones simo...@microsoft.com: | Has *is* a type class. It can be used and abused like any other. | Record members with the same key ought to have the same semantics; the | programmer must ensure this, not just call them all x or the like. | | Weak types these are not. The selector type is well-defined. The value | type is well-defined. The record type is well-defined, but of course | we define a type-class to let it be polymorphic. I want to mention that the issue Greg raises here is tackled under Representation hiding. The way we currently prevent random clients of a data type from selecting its foo field is by hiding the record selector foo. Similarly for its data constructors. This is Haskell's way of doing data abstraction; it may not be the best way, but it's Haskell's way. The trouble with instance declarations is that they are *always* exported. No hiding. Under Representation hiding I suggest that * If the record selector foo is in scope (by any name), then the corresponding Has instance is in scope too and vice versa. That would match up with Haskell's hiding mechanisms precisely, albeit at the cost of having an ad-hoc rule for Has instances. Simon I am not just concerned about Has instances from modules not under my control. I am concerned there is a new implicit rule that must be explained to me and that I have no control over: that every record field in the same module with a given label must have the exact same semantics as all others with the same label. Currently we don't have this rule. Currently we have records with the essentialy the same field labels, but with prefixes so they can coexist, and they need not have the same semantics. There is an extra problem with adding this rule: it is common practice to put types that arguably should be spread across multiple modules into one (module often named Types). Some form of this must be done out of necessity in the case of circular references between types that will otherwise not resolve. By default in Yesod, we do this out of necessity for records representing database tables. We call the module Models and users are free to write functions there. Now we have to explain to them that they should not. What use case for abstraction over record fields is too burdensome to use a type class for? Lacking such a compelling use case we are adding implicit complexity that can result in weak-typing for the unwary user with no compelling benefit. The wiki page for overloaded records suggests that users are expected to write code like this for virtual selectors: instance Has Shape area Float where get = area This is a leaky abstraction forcing me to quote function names at the type level. I would rather not be writing this code - explaining this code to someone means delving into implementation details that I don't understand. The overloaded records proposal is vying for extensibility by supporting abstraction over record fields with the same name. For this dubious use case that type classes already satisfies we lose user-friendly implementation of obviously useful functionality like virtual selectors, and also explainability. There is something to be said for the fact that I can quickly comprehend explanations of module-based record systems. I have read over the Overloaded Records proposal several times now and I have the gist of it, but I am still confused on details and need another couple reads to look at all the details instead of glossing over them. So far I have found some details on record implementations in four FP languages. Every single one implements a module-like namespace for records, one after abandoning the abstraction over fields approach. There are differing good approaches to convenient access - I think that is where it is appropriate for Haskell to attempt to take a different approach. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Composition operator [was: Re: Records in Haskell]
I broke out the dot operator section of the proposal to its own page since it is actually fairly independent of the different proposals. http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator On Sat, Jan 14, 2012 at 7:26 PM, wren ng thornton w...@freegeek.org wrote: On 1/13/12 11:31 PM, Chris Smith wrote: Anyone want to hazard a guess what percentage of Haskell programmers can even name every letter of the Greek alphabet? I'm betting less than 10%. That's easy for anyone with a classical education (or far too much mathematics education). There may well be less than 10% of Haskellers who have such, but Greek letters are rather trivial to learn. The problems arise when suddenly everyone needs to know the names of all the graphemes of Cyrillic, Amharic, Mandarin, Japanese, Arabic, Hebrew,... (because there are a great number of writing systems, and because they are relatively unknown having not been coopted by the mathematical tradition) or when everyone needs to know the names of all the obscure symbols mathematicians have come up with over the years (because generally they've never been named in the first place). -- Live well, ~wren __**_ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.**org Glasgow-haskell-users@haskell.org http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-usershttp://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On Sat, Jan 14, 2012 at 12:52 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:
Complexities of (Plan B)
Proposal (Plan B) sounds innocent enough. But I promise you, it isn't.
There has ben some mention of the left-to-right bias of Frege type
inference engine; indeed the wohle explanation of which programs are
accepted and which are rejected, inherently involves an understanding
of the type inference algorithm. This is a Very Bad Thing when the
type inference algorithm gets complicated, and GHC's is certainly
complicated.
Here's an example:
type family F a b
data instance F Int [a] = Mk { f :: Int }
g :: F Int b - ()
h :: F a [Bool] - ()
k x = (g x, x.f, h x)
Consider type inference on k. Initially we know nothing about the
type of x.
* From the application (g x) we learn that x's type has
shape (F Int something).
* From the application (h x) we learn that x's type has
shape (F something else [Bool])
* Hence x's type must be (F Int [Bool])
* And hence, using the data family we can see which field
f is intended.
Notice that
a) Neither left to right nor right to left would suffice
b) There is significant interaction with type/data families
(and I can give you more examples with classes and GADTs)
c) In passing we note that it is totally unclear how (Plan A)
would deal with data families
This looks like a swamp. In a simple Hindley-Milner typed language
you might get away with some informal heuristics, but Haskell is far
too complicated.
I rarely use Haskell's complex type machinery (and must admit to very
little understanding of it). So before dismissing this as difficult to
resolve in the face of a complex type system, For the complex type system I
would like to figure out.
* I am assuming that it is always possible to add a type annotation. Is
there extra complexity to the annotation, or can we just annotate the
record or top-level function?
* which parts of Haskell's complex type sytem will require type annotations
for Frege-style records.
* does using a library that uses complex machinery under the hood but tries
to limit the complexity of types exposed to the user end up infecting the
user's code with respect to difficulty in resolving records.
What makes the Haskell's type system great is first and foremost
typeclasses. And this is as complex as the vast majority of code gets. It
doesn't sound that bad to have an implementation that works very well for
the vast majority of code but requires using type annotations or normal
verbose name-spacing for those few parts that are already using verbose
name spacing.
- When you have SORF, you don't really need anything else
The blocking issues are described on
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
a) Representation hiding (look for that heading)
b) Record update (ditto), most especially for records whose
fields have polymorphic types
If we fix these we can move forward.
So essentially records are stalled again :(
I will keep trying to see if I can figure something out.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
That is a downside the Frege author had - one of the reasons he abandandoned this style of implementation. It is listed on the wiki. On Sat, Jan 14, 2012 at 3:28 PM, Jan-Willem Maessen jmaes...@alum.mit.eduwrote: On Fri, Jan 13, 2012 at 6:52 PM, Simon Peyton-Jones simo...@microsoft.com wrote: [... good summary of the issues...] But note what has happened: we have simply re-invented SORF. So the conclusion is this: the only sensible way to implement FDR is using SORF. An obvious question at this point: can records have unboxed fields? I'm worried a bit about the kinds that can appear in a has constraint: A feature of SORF is that you can write functions like this k :: Has r f Int = r - Int k r = r.f + 1 I'm thinking out loud about the implementation implications here. -Jan-Willem Maessen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Composition operator [was: Re: Records in Haskell]
Let me suggest that a simple non-nuclear alternative would be for people interested in Unicode symbols to use an editor that auto converts from Haskell Ascii to Haskell Unicode when loading and (of course) back again when saving. You can do that today. You can even pick your own Ascii from/to Unicode mapping. No need to argue about whether a symbol is prettier than another. All of this without forcing the rest of the (couldn't care less about record access syntax) Haskell community to have to deal with Unicode :-) I tried this with an existing vim extension, but found it to be slightly buggy. It seems much greater effort to tell people to use a mapping - now everyone must learn how to configure/program their editor, and this may be impossible for some editors. I was under the impression that virtually every code editor and viewer supports utf-8. If you want to do mappings, it seems preferable to first use a new ASCII operator for composition, which can still be mapped it to a unicode dot. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
I added this and your Control.Category. to the wiki.
I am not sure about the tuple proposal - tuples normally imply an ordering,
which would imply that all record fields must be accounted for at least
with an empty comma or an underscore, particularly if updating the last
field in a record. For records we want a syntax where we can pick out one
or many fields to update and ignore the rest.
My feeling on is that ~ is slightly more intuitive than because it
looks like an arrow which I equate with functions, and is more
difficult to parse because I have to recognize three in a row of the same
character . However, if everyone likes using the unicode dot, then it
doesn't matter what the non-unicode symbol is, and re-using existing
symbols is certainly advantageous.
On Thu, Jan 12, 2012 at 10:02 AM, Matthew Farkas-Dyck
strake...@gmail.comwrote:
On 09/01/2012, Isaac Dupree m...@isaac.cedarswampstudios.org wrote:
You mean this wiki page, right?:
http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
That is, there are no fundamental
objections to the implementation of this records implementation.
I think that might be overly optimistic... I think there's a risk that
SPJ finds an irritating complication to type inference the rest of us
aren't type-system-savvy enough to continue trying to guess at that :)
But I think you're referring to whether we object to ad-hoc overloading
of record field names (neither parametric nor class-based polymorphism),
if no difficulties crop up. Some of the concerns on
http://www.haskell.org/haskellwiki/TypeDirectedNameResolution apply --
I'm not sure to what extent, but address those concerns rather than
require those people to repeat themselves again! :)
(If we dodge all those obstacles, well, a better record system is
better!)
Regardless, I think the proposal needs more precision, so I tried for
syntax. And got this thousand word email just about syntax, in several
sections of reasoning, sorry!
--so here are my conclusions/suggestions up front in case you prefer,
most complicated first - look later for details in a different order,
referenced by [number].
Given that type inference for expr.field decides between several
different possible meanings of field, which fields in scope count as
possibilities? I concluded All identifiers 'field' in top-level scope
(i.e. declared in this module or imported unqualified from another
module), but no local let/lambda bindings. [1]
I have an unrelated record/module system tweak suggestion to prevent
leaks of the field-ness of exports meant only as functions. [2]
.field, for any identifier field, is a postfix operator that binds
more tightly than function application. [1]
I don't care whether the expression and .field are permitted to be
separated by whitespace or not. [4]
(.field) as a section: should it always require parentheses? (assuming
there is a way to type-inference the unapplied dot operator usefully at
all). [3]
The Type.{...} / expr.{...} variations look probably fine (Syntax for
updates in the wiki). [5]
Allow TyCon.field for selecting a specific version of field, but
only if there isn't a module in scope as TyCon in which case it's
interpreted as Module.field. [7]
Allow expr.TyCon.field / expr.Module.field wherever expr.field is
allowed. [8]
I bikesheddily suggest field@expr rather than expr.field (I'd be
alright with either/both). [6]
= Defining the basic dot syntax for record field selection =
[1]
.x, for any identifier x, is a postfix operator that binds more tightly
than function application. This operator does not constrain the type of
its operand or its result. After regular type inference, the type
system collects in-scope xs and does something to try to choose one.
(As a non-type-system-expert, I'm not addressing what does something
means in this email, besides capitalizing TYPE INFERENCE where I suspect
there might (or might not) be extra problems. Anyway, I wish the
algorithm do the right thing for expr.x.y.z.)
But which in-scope xes does it collect? Regular Haskell scope would
completely break let x = var.x if we wished to allow let x = var.x.
How about: all record fields 'x' declared in this module or imported
(qualified[??] or unqualified) from another module.
[[[
Should qualified ones be allowed?
Pro: if you import Data.Map qualified, as is common (let's just pretend
that Maps have members), then someMap.field works.
Pro: it's like allowing qualified imports for instance declaration
class-member-definitions.
Con: it's not really like that. It makes qualified imports a weaker
protection, as the class/instance exception can lead to no ambiguity,
but this can lead to ambiguity. The PVP would make a sad face.
Con: using unqualified import with (..) would easily bring the field
names into scope.
Re: Records in Haskell
I added your relevant previous notes to the wiki page. I have no idea if what you said about type inference is right or wrong. I don't think that record fields can be called scope resolution in a normal sense - the scope is guaranteed to resolve without conflict (unless the user incorrectly types the field name). We do need those very familiar with the GHC internals to weigh in with any implementation objections. On Tue, Jan 10, 2012 at 11:42 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: On 01/10/2012 05:06 AM, Greg Weber wrote: Some of your comments seem to not fully recognize the name-spacing (plus simple type resolution) aspect of this proposal that I probably didn't explain well enough. Or maybe I don't understand your comments. For record.field, field is under the record's namespace. A namespace (from a module or under the new system a record), cannot export conflicting names, and there this system prevents the importer from every having a conflict with a record field name because the field is still under the record's namespace when imported. The type system must resolve the type of the record, and generally the field cannot contribute to this effort. (I have only used Haskell for several years, not implemented Haskell several times; apologies for my amateurish understanding of the type system.) So Type inference proceeds assuming that record.field is something equivalent to undefined record (using undefined as a function type), and the program is only correct if the type of record resolves to a concrete type? I don't know if concrete type is at all the right terminology; I mean a type-variable doesn't count (whether class-constrained, Num a = a, or not, a, or even m Int is not concrete). Is forall a. Maybe a okay (if Maybe were a record)? forall a. Num a = Maybe a? I'm guessing yes. Does it get harder in the presence of the type-system extensions? (a ~ SomeRecord) = a: presumably that works with record syntax? Can the compiler always figure out whether or not it can find a type-variable's concrete type? My concept of Haskell is that (except for Template Haskell), scope resolution happens before type inference happens, no exceptions. So you're deliberately breaking that pattern. Right? Does this order of stages (regular scope selection, then type inference, then record scope) make as high a fraction of code work as Frege's left-to-right model (which I am guessing interleaves type inference and record scope selection as it proceeds left-to-right through the program)? Correct me if I got something wrong, -Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Thank you for all your feedback! I updated the wiki page accordingly. Let us stop and take note of what this feedback is about: the most convenient syntax for manipulating records, and much of this feedback applies to any records proposal. That is, there are no fundamental objections to the implementation of this records implementation. If you give this kind of general feedback then I assume you are fine with the name-spacing records implementation. At this point I feel we are largely waiting on feedback from implementers to give the implementation critiques or a green light. But that does not need to stop us from continuing our discussion of the best syntax for using records. For the left-right, right-left issue, I added a discussion and potential solution through partial application: Partial application provides a potential solution: (b . .a) r So if we have a function f r = b r.a then one can write it points-free: b . .a Our longer example from above: e . d . .c . .b . .a At first glance it may look odd, but it is starting to grow on me. Let us consider more realistic usage with longer names: echo . delta . .charlie . .beta . .alpha Is there are more convenient syntax for this? b .a Note that a move to a different operator for function composition (discussed in dot operator section) would make things easier to parse: b ~ .a where the unicode dot might be even nicer. On Mon, Jan 9, 2012 at 3:15 AM, wren ng thornton w...@freegeek.org wrote: quux (y . (foo. bar).baz (f . g)) moo It's not that easy to distinguish from quux (y . (foo. bar) . baz (f . g)) moo ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
2012/1/8 Gábor Lehel illiss...@gmail.com
Later on you write that the names of record fields are only accessible
from the record's namespace and via record syntax, but not from the
global scope. For Haskell I think it would make sense to reverse this
decision. On the one hand, it would keep backwards compatibility; on
the other hand, Haskell code is already written to avoid name clashes
between record fields, so it wouldn't introduce new problems. Large
gain, little pain. You could use the global-namespace function as you
do now, at the risk of ambiguity, or you could use the new record
syntax and avoid it. (If you were to also allow x.n syntax for
arbitrary functions, this could lead to ambiguity again... you could
solve it by preferring a record field belonging to the inferred type
over a function if both are available, but (at least in my current
state of ignorance) I would prefer to just not allow x.n for anything
other than record fields.)
Perhaps you can give some example code for what you have in mind - we do
need to figure out the preferred technique for interacting with old-style
records. Keep in mind that for new records the entire point is that they
must be name-spaced. A module could certainly export top-level functions
equivalent to how records work now (we could have a helper that generates
those functions).
Let's say you have a record.
data Record = Record { field :: String }
In existing Haskell, you refer to the accessor function as 'field' and
to the contents of the field as 'field r', where 'r' is a value of
type Record. With your proposal, you refer to the accessor function as
'Record.field' and to the contents of the field as either
'Record.field r' or 'r.field'. The point is that I see no conflict or
drawback in allowing all of these at the same time. Writing 'field' or
'field r' would work exactly as it already does, and be ambiguous if
there is more than one record field with the same name in scope. In
practice, existing code is already written to avoid this ambiguity so
it would continue to work. Or you could write 'Record.field r' or
'r.field', which would work as the proposal describes and remove the
ambiguity, and work even in the presence of multiple record fields
with the same name in scope.
The point is that I see what you gain by allowing record fields to be
referred to in a namespaced way, but I don't see what you gain by not
allowing them to be referred to in a non-namespaced way. In theory you
wouldn't care because the non-namespaced way is inferior anyways, but
in practice because all existing Haskell code does it that way, it's
significant.
My motivation for this entire change is simply to be able to use two record
with field members of the same name. This requires *not* generating
top-level functions to access record fields. I don't know if there is a
valid use case for the old top-level functions once switched over to the
new record system (other than your stated personal preference). We could
certainly have a pragma or something similar that generates top-level
functions even if the new record system is in use.
All of that said, maybe having TDNR with bad syntax is preferable to
not having TDNR at all. Can't it be extended to the existing syntax
(of function application)? Or least some better one, which is ideally
right-to-left? I don't really know the technical details...
Generalized data-namespaces: Also think I'm opposed. This would import
the problem from OO languages where functions written by the module
(class) author get to have a distinguished syntax (be inside the
namespace) over functions by anyone else (which don't).
Maybe you can show some example code? To me this is about controlling
exports of namespaces, which is already possible - I think this is
mostly a
matter of convenience.
If I'm understanding correctly, you're suggesting we be able to write:
data Data = Data Int where
twice (Data d) = 2 * d
thrice (Data d) = 3 * d
...
and that if we write 'let x = Data 7 in x.thrice' it would evaluate to
21. I have two objections.
The first is the same as with the TDNR proposal: you would have both
code that looks like
'data.firstFunction.secondFunction.thirdFunction', as well as the
existing 'thirdFunction $ secondFunction $ firstFunction data' and
'thirdFunction . secondFunction . firstFunction $ data', and if you
have both of them in the same expression (which you will) it becomes
unpleasant to read because you have to read them in opposite
directions.
This would not be possible because the functions can only be accessed from
the namespace - you could only use the dot (or T.firstFunction). It is
possible as per your complaint below:
The second is that only the author of the datatype could put functions
into its namespace; the 'data.foo' notation would only be available
for functions written by the datatype's
Re: Records in Haskell
I have updated the wiki - the entry level page [1] compares the different
proposals and points to a more fleshed out explanation of the Frege
proposal [2].
I think I now understand the differences between the existing proposals and
am able to provide leadership to move this forward. Let me summarize the
state of things:
There is a debate over extensible records that we are putting off into the
future. Instead we have 2 proposals to make things better right now:
* an overloaded record fields proposal that still has implementation
concerns
* a name-spacing simple type resolution proposal that is awaiting your
critique
The Frege language originally had overloaded record fields but then moved
to the latter system. The existing experience of the Frege language is very
fortunate for us as we now have some experience to help inform our own
decision.
Greg Weber
[1] http://hackage.haskell.org/trac/ghc/wiki/Records
[2] http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
On Wed, Jan 4, 2012 at 7:54 AM, Greg Weber g...@gregweber.info wrote:
The Frege author does not have a ghc mail list account but gave a more
detailed explanation of how he goes about TDNR for records and how often it
type checks without annotation in practice.
A more general explanation is here:
http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/c3di9sw
He sent a specific response to Simon's mail list message, quoted below:
Simon Peyton-Jones is absolutely correct when he notes:
Well the most obvious issue is this. 3.2 says e.m = (T.m e) if the
expression e has type t and the type constructor of t is T and there exists
a function T.m But that innocent-looking statement begs the *entire*
question! How do we know if e has type t?
The way it is done in Frege is such that, if you have a function that uses
or updates (nondestructively, of course) a record then at least the type
constructor of that record has to be known. This is no different than doing
it explicitly with case constructs, etc., just here you learn the types
from the constructors you write in the patterns.
Hence, it is not so that one can write a function that updates field f to
42 for any record that contains a field f:
foo x = x.{f=42}-- type annotation required for foo or x
In practice this means you'll have to write a type annotation here and
there.
Often, the field access is not the only one that happens to some variable
of record type, or the record is the result of another function
application. In such cases, the type is known.
I estimate that in 2/3 of all cases one does not need to write (T.e x) in
sparsely type annotated code, despite the fact that the frege type checker
has a left to right bias and does not yet attempt to find the type of x in
the code that follows the x.e construct (after let unrolling etc.)
I think one could do better and guarantee that, if the type of x is
inferrable at all, then so will be x.e (Still, it must be more than just a
type variable.)
On Sun, Jan 1, 2012 at 2:39 PM, Greg Weber g...@gregweber.info wrote:
On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Frege has a detailed explanation of the semantics of its record
implementation, and the language is *very* similar to Haskell. Lets just
start by using Frege's document as the proposal. We can start a new wiki
page as discussions are needed.
** **
If it’s a serious proposal, it needs a page to specify the design.
Currently all we have is a paragraph on
http://hackage.haskell.org/trac/ghc/wiki/Records, under “Better name
spacing”.
** **
As previously stated on this thread, the Frege user manual is available
here:
http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf***
*
see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type
Declaration - Constructors with labeled fields)
** **
To all those concerned about Records: look at the Frege implementation
and poke holes in it.
** **
Well the most obvious issue is this. 3.2 says
*e*.*m *= (*T*.*m e*) if the expression *e *has type *t *and the type
constructor
of *t *is *T *and there exists a function *T*.*m*
But that innocent-looking statement begs the **entire** question! How
do we know if “e has type t? This is the route ML takes for arithmetic
operators: + means integer plus if the argument is of type Int, float plus
if the argument is of type Float, and so on.
** **
Haskell type classes were specifically designed to address this
situation. And if you apply type classes to the record situation, I think
you end up with
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
More specifically I think of this as TDNR, which instead of the focus of
the wiki page of maintaining backwards compatibility and de-surgaring to
polymorphic constraints. I had hoped that there were different
Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
great! I am wondering if you can provide even higher-level APIs for the common case: hash - runResourceT $ hashFile my-file and possibly something that runs the ResourceT transformer: hash - runHashFile my-file On Sat, Jan 7, 2012 at 12:16 AM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: Hello! I'm pleased to announce the first release of crypto-conduit [1]! The crypto-api [2] package provides APIs for many cryptographic operations, such as cryptographic hashes and block ciphers. This new crypto-conduit package allows you to use many of these operations with conduits [3], giving you safe I/O using constant memory and no leaks. As an example, here's how you could get the SHA1 hash a file: import Crypto.Conduit -- from crypto-conduit import Crypto.Hash.SHA1 (SHA1) -- from cryptohash import Data.Conduit -- from conduit import Data.Conduit.Binary (sourceFile) -- from conduit main = do hash - runResourceT $ sourceFile my-file $$ sinkHash print (hash :: SHA1) The code snippet above, despite having only sourceFile ... $$ sinkHash on its core, guarantees that the file handle is not kept open and uses a constant amount of memory. Sweet! Please break this package! Although it comes with a test suite, it has just seen the light of the day. Cheers, =) [1] http://hackage.haskell.org/package/crypto-conduit [2] http://hackage.haskell.org/package/crypto-api [3] http://hackage.haskell.org/package/conduit -- Felipe. ___ web-devel mailing list web-de...@haskell.org http://www.haskell.org/mailman/listinfo/web-devel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Records in Haskell
The Frege author does not have a ghc mail list account but gave a more
detailed explanation of how he goes about TDNR for records and how often it
type checks without annotation in practice.
A more general explanation is here:
http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/c3di9sw
He sent a specific response to Simon's mail list message, quoted below:
Simon Peyton-Jones is absolutely correct when he notes:
Well the most obvious issue is this. 3.2 says e.m = (T.m e) if the
expression e has type t and the type constructor of t is T and there exists
a function T.m But that innocent-looking statement begs the *entire*
question! How do we know if e has type t?
The way it is done in Frege is such that, if you have a function that uses
or updates (nondestructively, of course) a record then at least the type
constructor of that record has to be known. This is no different than doing
it explicitly with case constructs, etc., just here you learn the types
from the constructors you write in the patterns.
Hence, it is not so that one can write a function that updates field f to
42 for any record that contains a field f:
foo x = x.{f=42}-- type annotation required for foo or x
In practice this means you'll have to write a type annotation here and
there.
Often, the field access is not the only one that happens to some variable
of record type, or the record is the result of another function
application. In such cases, the type is known.
I estimate that in 2/3 of all cases one does not need to write (T.e x) in
sparsely type annotated code, despite the fact that the frege type checker
has a left to right bias and does not yet attempt to find the type of x in
the code that follows the x.e construct (after let unrolling etc.)
I think one could do better and guarantee that, if the type of x is
inferrable at all, then so will be x.e (Still, it must be more than just a
type variable.)
On Sun, Jan 1, 2012 at 2:39 PM, Greg Weber g...@gregweber.info wrote:
On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones simo...@microsoft.com
wrote:
Frege has a detailed explanation of the semantics of its record
implementation, and the language is *very* similar to Haskell. Lets just
start by using Frege's document as the proposal. We can start a new wiki
page as discussions are needed.
** **
If it’s a serious proposal, it needs a page to specify the design.
Currently all we have is a paragraph on
http://hackage.haskell.org/trac/ghc/wiki/Records, under “Better name
spacing”.
** **
As previously stated on this thread, the Frege user manual is available
here:
http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf
see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type
Declaration - Constructors with labeled fields)
** **
To all those concerned about Records: look at the Frege implementation
and poke holes in it.
** **
Well the most obvious issue is this. 3.2 says
*e*.*m *= (*T*.*m e*) if the expression *e *has type *t *and the type
constructor
of *t *is *T *and there exists a function *T*.*m*
But that innocent-looking statement begs the **entire** question! How
do we know if “e has type t? This is the route ML takes for arithmetic
operators: + means integer plus if the argument is of type Int, float plus
if the argument is of type Float, and so on.
** **
Haskell type classes were specifically designed to address this
situation. And if you apply type classes to the record situation, I think
you end up with
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
More specifically I think of this as TDNR, which instead of the focus of
the wiki page of maintaining backwards compatibility and de-surgaring to
polymorphic constraints. I had hoped that there were different ideas or at
least more flexibility possible for the TDNR implementation.
** **
Well, so maybe we can give up on that. Imagine Frege without the above
abbreviation. The basic idea is that field names are rendered unique by
pre-pending the module name. As I understand it, to record selection one
would then be forced to write (T.m e), to select the ‘m’ field. That is
the, qualification with T is compulsory. The trouble with this is that
it’s **already** possible; simply define suitably named fields
data T = MkE { t_m :: Int, t_n :: Bool }
Here I have prefixed with a (lower case version of) the type name. So we
don’t seem to be much further ahead.
** **
Maybe one could make it optional if there is no ambiguity, much like
Haskell’s existing qualified names. But there is considerable ambiguity
about whether T.m means
m imported from module T
or
the m record selector of data type T
If there is ambiguity, we expect the T to be a module. So you would need
to refer to Record T's module: OtherModule.T.n or T.T.n
Re: Records in Haskell
On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
Frege has a detailed explanation of the semantics of its record
implementation, and the language is *very* similar to Haskell. Lets just
start by using Frege's document as the proposal. We can start a new wiki
page as discussions are needed.
** **
If it’s a serious proposal, it needs a page to specify the design.
Currently all we have is a paragraph on
http://hackage.haskell.org/trac/ghc/wiki/Records, under “Better name
spacing”.
** **
As previously stated on this thread, the Frege user manual is available
here:
http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf
see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type
Declaration - Constructors with labeled fields)
** **
To all those concerned about Records: look at the Frege implementation and
poke holes in it.
** **
Well the most obvious issue is this. 3.2 says
*e*.*m *= (*T*.*m e*) if the expression *e *has type *t *and the type
constructor
of *t *is *T *and there exists a function *T*.*m*
But that innocent-looking statement begs the **entire** question! How do
we know if “e has type t? This is the route ML takes for arithmetic
operators: + means integer plus if the argument is of type Int, float plus
if the argument is of type Float, and so on.
** **
Haskell type classes were specifically designed to address this situation.
And if you apply type classes to the record situation, I think you end up
with
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
More specifically I think of this as TDNR, which instead of the focus of
the wiki page of maintaining backwards compatibility and de-surgaring to
polymorphic constraints. I had hoped that there were different ideas or at
least more flexibility possible for the TDNR implementation.
** **
Well, so maybe we can give up on that. Imagine Frege without the above
abbreviation. The basic idea is that field names are rendered unique by
pre-pending the module name. As I understand it, to record selection one
would then be forced to write (T.m e), to select the ‘m’ field. That is
the, qualification with T is compulsory. The trouble with this is that
it’s **already** possible; simply define suitably named fields
data T = MkE { t_m :: Int, t_n :: Bool }
Here I have prefixed with a (lower case version of) the type name. So we
don’t seem to be much further ahead.
** **
Maybe one could make it optional if there is no ambiguity, much like
Haskell’s existing qualified names. But there is considerable ambiguity
about whether T.m means
m imported from module T
or
the m record selector of data type T
If there is ambiguity, we expect the T to be a module. So you would need to
refer to Record T's module: OtherModule.T.n or T.T.n
Alternatively these conflicts could be compilation errors.
Either way programmers are expected to structure their programs to avoid
conflicting names, no different then they do now.
** **
Perhaps one could make it work out. But before we can talk about it we
need to see a design. Which takes us back to the question of leadership.**
**
I am trying to provide as much leadership on this issue as I am capable
of. Your critique is very useful in that effort.
At this point the Frege proposal without TDNR seems to be a small step
forward. We can now define records with clashing fields in the same module.
However, without TDNR we don't have convenient access to those fields.
I am contacting the Frege author to see if we can get any more insights on
implementation details.
Simon
** **
** **
We only want critiques about
* achieving name-spacing right now
* implementing it in such a way that extensible records could be
implemented in its place in the future, although we will not allow that
discussion to hold up a records implementation now, just possibly modify
things slightly.
** **
Greg Weber
** **
On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones simo...@microsoft.com
wrote:
| The lack of response, I believe, is just a lack of anyone who
| can cut through all the noise and come up with some
| practical way to move forward in one of the many possible
| directions.
You're right. But it is very telling that the vast majority of responses
on
http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/
were not about the subject (leadership) but rather on suggesting yet more,
incompletely-specified solutions to the original problem. My modest
attempt to build a consensus by articulating the simplest solution I could
think of, manifestly failed.
The trouble is that I just don't have the bandwidth (or, if I'm honest,
the motivation) to drive this through to a conclusion. And if no one else
does
Re: Records in Haskell
Simon, I think you are continuing to move forward admirably on this. Thank you for contributing my suggestion to the wiki. I just edited the wiki with some more commentary. In particular I added: Frege has a detailed explanation of the semantics of its record implementation, and the language is *very* similar to Haskell. Lets just start by using Frege's document as the proposal. We can start a new wiki page as discussions are needed. As previously stated on this thread, the Frege user manual is available here: http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields) To all those concerned about Records: look at the Frege implementation and poke holes in it. We only want critiques about * achieving name-spacing right now * implementing it in such a way that extensible records could be implemented in its place in the future, although we will not allow that discussion to hold up a records implementation now, just possibly modify things slightly. Greg Weber On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones simo...@microsoft.comwrote: | The lack of response, I believe, is just a lack of anyone who | can cut through all the noise and come up with some | practical way to move forward in one of the many possible | directions. You're right. But it is very telling that the vast majority of responses on http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/ were not about the subject (leadership) but rather on suggesting yet more, incompletely-specified solutions to the original problem. My modest attempt to build a consensus by articulating the simplest solution I could think of, manifestly failed. The trouble is that I just don't have the bandwidth (or, if I'm honest, the motivation) to drive this through to a conclusion. And if no one else does either, perhaps it isn't *that* important to anyone. That said, it clearly is *somewhat* important to a lot of people, so doing nothing isn't very satisfactory either. Usually I feel I know how to move forward, but here I don't. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
The semantics of Frege's records are layed out in its manual [1] in the
following sections:
4.2.1 Algebraic Data type Declaration - Constructors with labeled fields
3.2 Primary Expression
The Frege record system explanation is the first one that I could read and
immediately understand (oh, it just creates a namespace!). Perhaps this is
just in part because it was better explained. But I think it is also
because desugaring records to a library is a very complicated proposition,
whereas taking the same library concept but baking it into the compiler and
making simple language modifications is actually much more straightforward
to understand.
Many of the built-in record proposals seem more ambitious (create a new
record from an existing one, generalize in some other direction). More
power or generalization could be very useful, but it can wait for later -
Haskell's records are glaringly bad because they lack name-spacing.
I think one of the problems being faced with improving records is a false
choice between a quick but hacky library desugaring or a major Extensible
records built into the compiler. What I am proposing is that (unless
someone proposes a great desugaring solution) we make it the immediate goal
to have records built into the compiler, but done in the simplest (perhaps
least Extensible) way that just accomplishes name-spacing.
[1] http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf
On Tue, Dec 27, 2011 at 8:32 AM, Greg Weber g...@gregweber.info wrote:
The original goal was to come up with a simple solution. Perhaps that goal
is unattainable, or at least attaining it has much higher cost than we had
hoped. If that is the case we must take a step back and look at changing
how things are done currently. Perhaps the approach that a record label
becomes a global module function is just not feasible.
In the Frege http://code.google.com/p/frege (a Haskell with some
differences implementation on the JVM) language every data type is at the
same time a namespace.
* the function that accesses field x of data type T is T.x
* If a::T then a.x = T.x a
* the function that updates field x of data type T is T.{x=}
* the function that sets field x in a T to 42 is T.{x=42}
* If a::T then a.{x=} and a.{x=42} are valid
* the function that changes field x of a T by applying some function to it
is T.{x -}
* T.{x?} is a function that returns true iff the argument was constructed
with a data constructor that has field x.
In the Opa language a Module is in fact a Record specially marked as a
module.
What do you think of the Frege system?
On Fri, Dec 23, 2011 at 2:40 PM, Greg Weber g...@gregweber.info wrote:
I am willing to help on this as much as I can. Unfortunately I don't
think you want me to lead the discussion or make decisions on this - many
of these discussions seem over my head. I will continue to study them
though and see if the sink in more.
I do think almost all of these proposals want a dot selector, so it is a
good idea for Haskell to require the normal function (composition) dot to
have spaces around it - should this be brought to the Haskell
Prime committee?
Greg Weber
On Fri, Dec 23, 2011 at 1:52 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Are Records stalled out again? I am perfectly willing to leave the
fate of records up to a willing and capable implementer. That seems much
better than waiting another 5 years for perfection :)
** **
Yes, they are stalled again. The “simple solution” turned out to be not
simple. I wrote it up at length in
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields*
***
There are various unsatisfactory aspects of the proposal, particularly
concerning record update. I am not sure how to resolve them.
** **
There was essentially no reaction. As it’s quite a lot of work to
implement, and no one seemed to care very much, I put it back on the back
burner. So that’s where it stands.
** **
Meanwhile, AntC has put forth another proposal that I have not had time
to look at in detail.
http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298.html
** **
*What this needs is someone (not me) to lead the discussion and try to
make sure it makes progress*. For example, does AntC’s proposal work?
Is it better than the one I articulated? Are any other variants worth
considering? Is the gain from overloading record fields worth the pain or
design and implementation?Volunteers, stand forth!
** **
Simon
** **
** **
*From:* Greg Weber [mailto:g...@gregweber.info]
*Sent:* 09 December 2011 19:38
*To:* Simon Peyton-Jones
*Cc:* Wolfgang Jeltsch; glasgow-haskell-users@haskell.org
*Subject:* Re: Records in Haskell
** **
Are Records stalled out again? I am perfectly willing to leave the fate
of records up to a willing and capable implementer. That seems much better
than waiting
Re: Records in Haskell
On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave d...@avvanta.com wrote: Quoth Greg Weber g...@gregweber.info, ... Many of the built-in record proposals seem more ambitious (create a new record from an existing one, generalize in some other direction). More power or generalization could be very useful, but it can wait for later - Haskell's records are glaringly bad because they lack name-spacing. I think one of the problems being faced with improving records is a false choice between a quick but hacky library desugaring or a major Extensible records built into the compiler. What I am proposing is that (unless someone proposes a great desugaring solution) we make it the immediate goal to have records built into the compiler, but done in the simplest (perhaps least Extensible) way that just accomplishes name-spacing. It's sure easy to imagine something like that happening, in principle, but ... are you saying that extensibility specifically has been a major issue? Could be, I haven't been paying so much attention. Yes, I believe it is common knowledge and stated in many places that the community cannot decide on the best *extensible* record system. http://www.haskell.org/haskellwiki/GHC:FAQ#Extensible_Records Wouldn't extensibility more or less come along with row polymorphism? I mean, my understanding of the term is that an expression that instantiates a particular record field, can incorporate a record lacking that field, which seems to me to be implicit in row polymorphism anyway. I would think row polymorphism is a must-have. Perhaps if you want *extensible* records. If you would like to make some progress with records in the near future rather than keeping records in limbo, I think we really need to give up for the moment on any higher form of abstraction than straight-forward name-spacing. If you're interested in looking at old, Haskell-related record systems, also see O'Haskell. I am interested in any potential solution. You could link to it on the ExtensibleRecords wiki page and explain it a bit for future reference. O'Haskell seems to be very much concerned with being as extensible as possible - to the point of trying to do OO in Haskell. Greg Weber Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On Wed, Dec 28, 2011 at 3:34 PM, Donn Cave d...@avvanta.com wrote: Quoth Greg Weber g...@gregweber.info, On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave d...@avvanta.com wrote: ... I would think row polymorphism is a must-have. Perhaps if you want *extensible* records. If you would like to make some progress with records in the near future rather than keeping records in limbo, I think we really need to give up for the moment on any higher form of abstraction than straight-forward name-spacing. No, to be clear on that, I haven't given much thought to extensibility per se, I was thinking row polymorphism is a valuable feature on its own, and extensibility just seemed to me to be an implicit side benefit. In principle, a less is more approach to language features appeals to me a lot, but not to the point where we just preemptively give up on any higher form of abstraction. Given the potential for backwards incompatibility, you'd want to have something pretty good to show for it. This is a valid concern. The goal I think we should have is to just to get a release with simple name-spacing resulting in module-like dot notation member selection plus a similar easy syntax for updates. Every extensible records solution I have seen wants this plus some other features. Admittedly I don't understand any of the extensible solutions, so if you can come up with a specific example of backwards incompatibility that would be very useful. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
The original goal was to come up with a simple solution. Perhaps that goal
is unattainable, or at least attaining it has much higher cost than we had
hoped. If that is the case we must take a step back and look at changing
how things are done currently. Perhaps the approach that a record label
becomes a global module function is just not feasible.
In the Frege http://code.google.com/p/frege (a Haskell with some
differences implementation on the JVM) language every data type is at the
same time a namespace.
* the function that accesses field x of data type T is T.x
* If a::T then a.x = T.x a
* the function that updates field x of data type T is T.{x=}
* the function that sets field x in a T to 42 is T.{x=42}
* If a::T then a.{x=} and a.{x=42} are valid
* the function that changes field x of a T by applying some function to it
is T.{x -}
* T.{x?} is a function that returns true iff the argument was constructed
with a data constructor that has field x.
In the Opa language a Module is in fact a Record specially marked as a
module.
What do you think of the Frege system?
On Fri, Dec 23, 2011 at 2:40 PM, Greg Weber g...@gregweber.info wrote:
I am willing to help on this as much as I can. Unfortunately I don't think
you want me to lead the discussion or make decisions on this - many of
these discussions seem over my head. I will continue to study them though
and see if the sink in more.
I do think almost all of these proposals want a dot selector, so it is a
good idea for Haskell to require the normal function (composition) dot to
have spaces around it - should this be brought to the Haskell
Prime committee?
Greg Weber
On Fri, Dec 23, 2011 at 1:52 PM, Simon Peyton-Jones simo...@microsoft.com
wrote:
Are Records stalled out again? I am perfectly willing to leave the fate
of records up to a willing and capable implementer. That seems much better
than waiting another 5 years for perfection :)
** **
Yes, they are stalled again. The “simple solution” turned out to be not
simple. I wrote it up at length in
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields**
**
There are various unsatisfactory aspects of the proposal, particularly
concerning record update. I am not sure how to resolve them.
** **
There was essentially no reaction. As it’s quite a lot of work to
implement, and no one seemed to care very much, I put it back on the back
burner. So that’s where it stands.
** **
Meanwhile, AntC has put forth another proposal that I have not had time
to look at in detail.
http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298.html
** **
*What this needs is someone (not me) to lead the discussion and try to
make sure it makes progress*. For example, does AntC’s proposal work?
Is it better than the one I articulated? Are any other variants worth
considering? Is the gain from overloading record fields worth the pain or
design and implementation?Volunteers, stand forth!
** **
Simon
** **
** **
*From:* Greg Weber [mailto:g...@gregweber.info]
*Sent:* 09 December 2011 19:38
*To:* Simon Peyton-Jones
*Cc:* Wolfgang Jeltsch; glasgow-haskell-users@haskell.org
*Subject:* Re: Records in Haskell
** **
Are Records stalled out again? I am perfectly willing to leave the fate
of records up to a willing and capable implementer. That seems much better
than waiting another 5 years for perfection :)
** **
As an intermediate step, is it possible to put a warning in 7.4 when the
dot operator is used without a space so that it can be reserved for usage
with a records solution? Or will the new records solution be turned on by
an extension anyways?
** **
On Mon, Nov 7, 2011 at 10:21 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
| would inclusion of such a record system into GHC mean that plans for
| first-class labels (http://tinyurl.com/7fppj32) are abandoned? That
| would be a pity, since first-class labels are very useful to implement
| record systems that go beyond what the abovementioned record system
| provides. See, for example, my work on records:
|
http://www.informatik.tu-cottbus.de/~jeltsch/research/ppdp-2010-paper.pdf
| http://hackage.haskell.org/package/records
The story is summarised at
http://hackage.haskell.org/trac/ghc/wiki/Records
First-class labels are one point in the vast swamp of competing and
overlapping proposals for records. I think they are summarise here:
http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords
I am unsure which of this list of proposals you are referring to. The URL
you quote is this
http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels
but it doesn't seem to actually contain a design, merely some options for
a design that is implicit. If you do have a design you advocate, it would
be good to add it to the list at
http
Re: [Haskell-cafe] ANNOUNCE: hxournal-0.5.0.0 - A pen notetaking
yes it worked after your updates shortly after this. Thank you very much for checking up, and also for continuing to develop this - I may be able to replace xournal with it now. On Tue, Dec 27, 2011 at 10:03 AM, Ian-Woo Kim ianwoo...@gmail.com wrote: Hi, Greg, Sorry that I just missed to read your reply. Since hxournal has a configuration file to specify input device and also is activated on the toggle menu item Use X Input, you should be able to experiment pen drawing now. Did you succeed in using the latest version of hxournal? I appreciate your report. Thanks very much. best, Ian-Woo On Tue, Dec 13, 2011 at 5:22 AM, Greg Weber g...@gregweber.info wrote: I got the program installed after creating the libstdc++.so symlink. No ink shows up from my drawing though. I am on a Thinkpad X201 Tablet and xournal works. I am glad you are experimenting with window splits. I think the worst part of xournal is it constrains you to a notebook-width piece of paper. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Records in Haskell
I am willing to help on this as much as I can. Unfortunately I don't think you want me to lead the discussion or make decisions on this - many of these discussions seem over my head. I will continue to study them though and see if the sink in more. I do think almost all of these proposals want a dot selector, so it is a good idea for Haskell to require the normal function (composition) dot to have spaces around it - should this be brought to the Haskell Prime committee? Greg Weber On Fri, Dec 23, 2011 at 1:52 PM, Simon Peyton-Jones simo...@microsoft.comwrote: Are Records stalled out again? I am perfectly willing to leave the fate of records up to a willing and capable implementer. That seems much better than waiting another 5 years for perfection :) ** ** Yes, they are stalled again. The “simple solution” turned out to be not simple. I wrote it up at length in http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields*** * There are various unsatisfactory aspects of the proposal, particularly concerning record update. I am not sure how to resolve them. ** ** There was essentially no reaction. As it’s quite a lot of work to implement, and no one seemed to care very much, I put it back on the back burner. So that’s where it stands. ** ** Meanwhile, AntC has put forth another proposal that I have not had time to look at in detail. http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298.html ** ** *What this needs is someone (not me) to lead the discussion and try to make sure it makes progress*. For example, does AntC’s proposal work? Is it better than the one I articulated? Are any other variants worth considering? Is the gain from overloading record fields worth the pain or design and implementation?Volunteers, stand forth! ** ** Simon ** ** ** ** *From:* Greg Weber [mailto:g...@gregweber.info] *Sent:* 09 December 2011 19:38 *To:* Simon Peyton-Jones *Cc:* Wolfgang Jeltsch; glasgow-haskell-users@haskell.org *Subject:* Re: Records in Haskell ** ** Are Records stalled out again? I am perfectly willing to leave the fate of records up to a willing and capable implementer. That seems much better than waiting another 5 years for perfection :) ** ** As an intermediate step, is it possible to put a warning in 7.4 when the dot operator is used without a space so that it can be reserved for usage with a records solution? Or will the new records solution be turned on by an extension anyways? ** ** On Mon, Nov 7, 2011 at 10:21 AM, Simon Peyton-Jones simo...@microsoft.com wrote: | would inclusion of such a record system into GHC mean that plans for | first-class labels (http://tinyurl.com/7fppj32) are abandoned? That | would be a pity, since first-class labels are very useful to implement | record systems that go beyond what the abovementioned record system | provides. See, for example, my work on records: | http://www.informatik.tu-cottbus.de/~jeltsch/research/ppdp-2010-paper.pdf | http://hackage.haskell.org/package/records The story is summarised at http://hackage.haskell.org/trac/ghc/wiki/Records First-class labels are one point in the vast swamp of competing and overlapping proposals for records. I think they are summarise here: http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords I am unsure which of this list of proposals you are referring to. The URL you quote is this http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels but it doesn't seem to actually contain a design, merely some options for a design that is implicit. If you do have a design you advocate, it would be good to add it to the list at http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords perhaps explaining which of the other members of the list it subsumes. Because there are so many proposals I have not gone ahead with any of them. The most recent thread, articulated at http://hackage.haskell.org/trac/ghc/wiki/Records is to ask what is the *smallest change* that would solve the *most pressing problem*, namely the inability to use the same field name in different records. First class labels is (I assume) much more ambitious. But maybe not. Anything you can do to bring clarity to the swamp, by editing the above two pages, would be a great service to the community. At the moment, we are stuck in an infinite loop. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ** ** ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] ANNOUNCE: hxournal-0.5.0.0 - A pen notetaking
I got the program installed after creating the libstdc++.so symlink. No ink shows up from my drawing though. I am on a Thinkpad X201 Tablet and xournal works. I am glad you are experimenting with window splits. I think the worst part of xournal is it constrains you to a notebook-width piece of paper. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get a file path to the program invoked?
In addition to argv[0] http://hackage.haskell.org/packages/archive/system-argv0/0.1/doc/html/System-Argv0.html There is also this package: http://hackage.haskell.org/packages/archive/FindBin/0.0.5/doc/html/System-Environment-FindBin.html System-Argv0 has special cases for windows- FindBin may not work there. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Should GHC default to -O1 ?
How much does using ghc without cabal imply a newer programmer? I don't use
cabal when trying out small bits of code (maybe I should be using ghci),
but am otherwise always using cabal.
On Wed, Nov 9, 2011 at 3:18 AM, Duncan Coutts
duncan.cou...@googlemail.comwrote:
On 9 November 2011 00:17, Felipe Almeida Lessa felipe.le...@gmail.com
wrote:
On Tue, Nov 8, 2011 at 3:01 PM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
On Tuesday 08 November 2011, 17:16:27, Simon Marlow wrote:
most people know about 1, but I think 2 is probably less well-known.
When in the edit-compile-debug cycle it really helps to have -O off,
because your compiles will be so much quicker due to both factors 1
2.
Of course. So defaulting to -O1 would mean one has to specify -O0 in the
.cabal or Makefile resp. on the command line during development, which
certainly is an inconvenience.
AFAIK, Cabal already uses -O1 by default.
Indeed, and cabal check / hackage upload complain if you put -O{n} in
your .cabal file.
The recommended method during development is to use:
$ cabal configure -O0
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: log time instead of linear for case matching
I thought it could be a nice GHC feature to optimize string lookup, and that using case arrows could be a nice syntax for creating maps. We will be fine using a Map. Making sure that sum types are optimized was the important thing, thanks! On Mon, Oct 10, 2011 at 1:14 AM, Simon Peyton-Jones simo...@microsoft.comwrote: Greg ** ** In GHC, big cases are done as tables (if dense) or trees (if sparse). If you have some examples where things go bad, do submit a bug report. ** ** For big dispatches on strings, I’m pretty sure we do something linear, top to bottom. I’d be strongly inclined to use a proper Map structure if you want good performance on that. Is there some reason you don’t want to? Simon ** ** *From:* glasgow-haskell-users-boun...@haskell.org [mailto: glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Greg Weber *Sent:* 09 October 2011 17:39 *To:* GHC users *Subject:* log time instead of linear for case matching ** ** We have a couple use cases in Yesod that can potentially match many different patterns. Routing connects the url of an http request to a Haskell function. The current code just uses a pattern match, which scales linearly. So if a site has a hundred different routes (urls), it could take 100 comparisons to finally match the url to a function. Michael Snoyman is writing some code to make this issue obsolete. One of the things it does is use a Map lookup instead of a case match. ** ** More worrying is our system for internationalization of a website. A user is supposed to make a sum type with every custom message as a constructor in that sum type. ** ** data Msg = Model | Year | Please ** ** -- Rendering function for English. renderEnglish Model = Model renderEnglish Year = Year renderEnglish Please = Please fill in your car's details ** ** -- Rendering function for Swedish. renderSwedish Model = Modell renderSwedish Year = Årgång renderSwedish Please = Vänligen fyll i uppgifterna för din bil ** ** So if there are 100 custom messages on a site, that will setup a case match with potentially 100 comparisons. ** ** Note that we are using this technique for type safety- switching to a map here would be difficult. We want to know at compile time that a translation exists for every message. ** ** So first of all I am wondering if a sum type comparison does in fact scale linearly or if there are optimizations in place to make the lookup constant or logarithmic. Second, I as wondering (for the routing case) if Haskell can make a string case comparison logarithmic so that users can use case comparisons instead of maps for string collections that are known at compile time and won't change. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
