Re: [Haskell-cafe] ghc-mod v3.0.0
Is this backward compatible with older versions of Cabal? I am considering whether to migrate HaRe to use this, I would prefer not to have it then fail to work on older systems that are constrained not to be able to update Cabal. Alan On Fri, Sep 6, 2013 at 7:29 AM, Kazu Yamamoto k...@iij.ad.jp wrote: Hi all, I have just uploaded ghc-mod v3.0.0 to Hackage. In this version, ghc-mod supports the sandbox feature of cabal-install. Instead, it stopped supporting cabal-dev. If you want to use ghc-mod v3.0.0, I would recommand to install cabal-install 1.18. The sandbox in your package is automatically detected by ghc-mod if exists. --Kazu ___ 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] ghc-mod v3.0.0
Alan, Is this backward compatible with older versions of Cabal? I am considering whether to migrate HaRe to use this, I would prefer not to have it then fail to work on older systems that are constrained not to be able to update Cabal. The sandbox is a feature of cabal-install, not Cabal lib. I carefully implemented this version not using Cabal 1.18. --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc-mod v3.0.0
Ok, thanks. On Fri, Sep 6, 2013 at 9:52 AM, Kazu Yamamoto k...@iij.ad.jp wrote: Alan, Is this backward compatible with older versions of Cabal? I am considering whether to migrate HaRe to use this, I would prefer not to have it then fail to work on older systems that are constrained not to be able to update Cabal. The sandbox is a feature of cabal-install, not Cabal lib. I carefully implemented this version not using Cabal 1.18. --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] interactive-diagrams: call for suggestions
Good time of day, everyone! As some of you may know, I am developing an interactive-diagrams pastebin as part of the GSoC program [1]. The demo is live at http://paste.hskll.org, feel free to play around with it. This week I plan to migrate to the PostgreSQL database (right now all the information is stored using sqlite). And since I am already going to write code for migration I might as well implement some changes to the DB schema. That's why I am asking you to provide any suggestions on what (front-end) features would you like to see, that are most likely require to change the DB schema. Right now I plan on implementing changes that would allow the following: - Ability to annotate pastes. Pastes may have parent pastes and child pastes. - Logins (via GitHub), in addition to pseudonymous-pastes where user can just enter any text as his nickname. This will also allow user to make collections of his pastes. - Stars. Logged in users may star pastes they like. Please report your suggestions here or on GitHub [2]. Thanks! [1] https://gist.github.com/co-dan/437e9694563c0c13dd8e [2] https://github.com/co-dan/interactive-diagrams/issues/16 -- Sincerely yours, -- Daniil Frumin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
Hello all, I have an issue that has been nagging me for a while, and I'd like to make sure I haven't missed a solution to it. I'm the maintainer for the buildwrapper package. This package has dependencies on the Cabal and GHC libraries, and also uses the cabal-install executable. For example it will run cabal configure by invoking the executable, then it will load the LocalBuildInfo via the Cabal API, and extract the relevant information to start a GHC session with the proper flags, etc. Now yesterday some great news were announced, a new version of Cabal! However, I can't use it. I can of course install the Cabal library and rebuild the cabal executable but - buildwrapper will only use the version of the Cabal library that was bundled with GHC, since the GHC library has a dependency on that version of Cabal - so the library access will be using Cabal 1.16, but the executable will be 1.18 - and the library checks when reading the setup-config file that the Cabal versions match. Hence, running configure with 1.18 create build information I can't read back in 1.16. So I'm stuck. People can easily install cabal 1.18 and build their projects with it, but I can't use it in conjunction with buildwrapper. Some solutions I've considered - do not use the Cabal API and write my own code to read the local build info, and to replace all the Cabal library code I use - do not use the cabal-install executable but do everything by the API Both solutions reek of madness, and involve rewriting code that others have already written, and a maintenance nightmare with each Cabal release. So, do I have to wait a new release of GHC/Haskell Platform or is there a better solution? I suspect ghc-mod and other similar packages have the same issues. Thanks for any help! -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
I spent some time looking into the touch points between ghc and cabal in the past, and the first oddity i saw was a direct dependency from ghc to the cabal sources. After taking a closer look it seems that ghc shares some common, low level modules with cabal that didnt seem to justify the whole dependency. The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue. Re: specific workaround i am not sure. On Friday, September 6, 2013, JP Moresmau wrote: Hello all, I have an issue that has been nagging me for a while, and I'd like to make sure I haven't missed a solution to it. I'm the maintainer for the buildwrapper package. This package has dependencies on the Cabal and GHC libraries, and also uses the cabal-install executable. For example it will run cabal configure by invoking the executable, then it will load the LocalBuildInfo via the Cabal API, and extract the relevant information to start a GHC session with the proper flags, etc. Now yesterday some great news were announced, a new version of Cabal! However, I can't use it. I can of course install the Cabal library and rebuild the cabal executable but - buildwrapper will only use the version of the Cabal library that was bundled with GHC, since the GHC library has a dependency on that version of Cabal - so the library access will be using Cabal 1.16, but the executable will be 1.18 - and the library checks when reading the setup-config file that the Cabal versions match. Hence, running configure with 1.18 create build information I can't read back in 1.16. So I'm stuck. People can easily install cabal 1.18 and build their projects with it, but I can't use it in conjunction with buildwrapper. Some solutions I've considered - do not use the Cabal API and write my own code to read the local build info, and to replace all the Cabal library code I use - do not use the cabal-install executable but do everything by the API Both solutions reek of madness, and involve rewriting code that others have already written, and a maintenance nightmare with each Cabal release. So, do I have to wait a new release of GHC/Haskell Platform or is there a better solution? I suspect ghc-mod and other similar packages have the same issues. Thanks for any help! -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote: The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue. This sounds very right to me. There should be something that describes what a GHC package database is, as minimally as possible (perhaps even only the data types). In the end, ghc is the defining side here - cabal is only a tool that builds on top of these definitions. Then ghc could finally be decoupled from Cabal. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
The right solution for Cabal would be not to know anything about the GHC's database format at all. GHC and cabal communicate via a command line interface (`ghc-pkg dump` in our direction; `ghc-pkg update` in the other). So it would suffice to have a library which implements parsing and printing of the package description, and have that library shared between GHC and Cabal. (Which I think is more or less what you guys are suggesting, only I'd like to point out that we should be focusing on the protocol instead of the database format. The latter should be opaque.) Roman * Niklas Hambüchen m...@nh2.me [2013-09-06 22:42:28+0900] On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote: The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue. This sounds very right to me. There should be something that describes what a GHC package database is, as minimally as possible (perhaps even only the data types). In the end, ghc is the defining side here - cabal is only a tool that builds on top of these definitions. Then ghc could finally be decoupled from Cabal. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote: I spent some time looking into the touch points between ghc and cabal in the past, and the first oddity i saw was a direct dependency from ghc to the cabal sources. After taking a closer look it seems that ghc shares some common, low level modules with cabal that didnt seem to justify the whole dependency. The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue. [...] fyi, a similiar/related discussion took place few months ago on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html hth, hvr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
On Fri 06 Sep 2013 22:52:40 JST, Roman Cheplyaka wrote: The right solution for Cabal would be not to know anything about the GHC's database format at all. GHC and cabal communicate via a command line interface (`ghc-pkg dump` in our direction; `ghc-pkg update` in the other). So it would suffice to have a library which implements parsing and printing of the package description, and have that library shared between GHC and Cabal. You are right. This is better. GHC's dependency on cabal seems to actually be quite minimal! I did a quick grep: % grep -rI import Distribution --include *.hs --include *.lhs* . | grep -v libraries/ | grep -v Setup.hs | grep -v Setup.lhs | grep -v utils/haddock ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Check hiding (doesFileExist) ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Configuration ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Parse ./utils/ghc-cabal/Main.hs:import Distribution.System ./utils/ghc-cabal/Main.hs:import Distribution.Simple ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Configure ./utils/ghc-cabal/Main.hs:import Distribution.Simple.LocalBuildInfo ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program.HcPkg ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Utils (defaultPackageDesc, writeFileAtomic, toUTF8) ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Build (writeAutogenFiles) ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Register ./utils/ghc-cabal/Main.hs:import Distribution.Text ./utils/ghc-cabal/Main.hs:import Distribution.Verbosity ./utils/ghctags/Main.hs:import Distribution.Simple.GHC ( componentGhcOptions ) ./utils/ghctags/Main.hs:import Distribution.Simple.Configure ( getPersistBuildConfig ) ./utils/ghctags/Main.hs:import Distribution.Simple.Compiler ( compilerVersion ) ./utils/ghctags/Main.hs:import Distribution.Simple.Program.GHC ( renderGhcOptions ) ./utils/ghctags/Main.hs:import Distribution.PackageDescription ( library, libBuildInfo ) ./utils/ghctags/Main.hs:import Distribution.Simple.LocalBuildInfo ./utils/ghc-pkg/Main.hs:import Distribution.InstalledPackageInfo.Binary() ./utils/ghc-pkg/Main.hs:import Distribution.ModuleName hiding (main) ./utils/ghc-pkg/Main.hs:import Distribution.InstalledPackageInfo ./utils/ghc-pkg/Main.hs:import Distribution.Compat.ReadP ./utils/ghc-pkg/Main.hs:import Distribution.ParseUtils ./utils/ghc-pkg/Main.hs:import Distribution.Package hiding (depends) ./utils/ghc-pkg/Main.hs:import Distribution.Text ./utils/ghc-pkg/Main.hs:import Distribution.Version ./compiler/ghci/Linker.lhs:import Distribution.Package hiding (depends, PackageId) ./compiler/main/Packages.lhs:import Distribution.InstalledPackageInfo ./compiler/main/Packages.lhs:import Distribution.InstalledPackageInfo.Binary ./compiler/main/Packages.lhs:import Distribution.Package hiding (PackageId,depends) ./compiler/main/PackageConfig.hs:import Distribution.InstalledPackageInfo ./compiler/main/PackageConfig.hs:import Distribution.ModuleName ./compiler/main/PackageConfig.hs:import Distribution.Package hiding (PackageId) ./compiler/main/PackageConfig.hs:import Distribution.Text ./compiler/main/PackageConfig.hs:import Distribution.Version ./compiler/main/Finder.lhs:import Distribution.Text ./compiler/main/Finder.lhs:import Distribution.Package hiding (PackageId) As you can see, there are only 4 files in ghc itself that depend on Cabal: ./compiler/ghci/Linker.lhs ./compiler/main/Packages.lhs ./compiler/main/PackageConfig.hs ./compiler/main/Finder.lhs (plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs) The ones in GHC core seem to rely only on quite basic data types. From this, I would boldly claim that people have spent more time making the GHC build system work with this Cabal dependency than it would take stripping it off! (In fact, I would try to do this right now if the GHC build system wouldn't take so long to compile even the smallest changes ...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
Interesting: in the ghc-devs discussion, Duncan talks about a cabal-lib and a cabal-build-simple split ( http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html). That would solve my problem nicely (GHC could depend on cabal-lib only, that wouldn't have to change as often as cabal-build-simple). I don't see a trace of that split in 1.18, anybody knows if it's still on the map? And thanks everybody for the contributions, it looks I'm not the only one that had thought about that issue... JP On Fri, Sep 6, 2013 at 4:32 PM, Herbert Valerio Riedel h...@gnu.org wrote: On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote: I spent some time looking into the touch points between ghc and cabal in the past, and the first oddity i saw was a direct dependency from ghc to the cabal sources. After taking a closer look it seems that ghc shares some common, low level modules with cabal that didnt seem to justify the whole dependency. The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue. [...] fyi, a similiar/related discussion took place few months ago on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html hth, hvr -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
It looks to me that technically it should be easy to split off the part required by GHC. Maybe somebody could just try that (currently it does not seem to take longer than a few hours) so that we have some basic proposal and momentum. On 07/09/13 00:04, JP Moresmau wrote: Oh, I'm happy to help as well if somebody is needed to do the change ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unary functions and infix notation
On Fri, Sep 6, 2013 at 11:04 AM, Johannes Emerich johan...@emerich.dewrote: Desugaring of an equivalent source file shows that id is applied to the anonymous function, which is then applied to 1. The following example of a function that is not polymorphic in its return type behaves closer to what I would have expected: It does not work. Prelude let z = (\y - True) :: a - Bool Prelude :t (`z` True) interactive:1:2: The operator `z' takes two arguments, but its type `a0 - Bool' has only one In the expression: (`z` True) What is the purpose/reason for this behaviour? Coming from another language, where functions aren't first class, you will probably be used to the notion that a function type is somehow different from any other type. You'll need to unlearn that for functional languages: function types are just as real as (Integer) is, and if I have a type variable somewhere which doesn't have constraints otherwise preventing it, that type variable can end up being (Integer) or (a - a) or (Num c = c - c - c) or (Maybe [x]) or (Maybe (a - a)) or any other (rank-1, i.e. no internal foralls) type. (id) has the type (a - a); in the use mentioned in the first quoted paragraph, this has unified (a) with (b - b) to produce (id :: (b - b) - (b - b)) in order for the whole expression to be typeable. In your second example, you don't have polymorphism where it's needed so it can't infer a type that will work. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
We just had a short discussion on #ghc, I copy-paste: http://lpaste.net/92639 dcoutts_: nh2: Cabal does not depend on the ghc-pkg format. Cabal specifies a compiler-independent package registration format. GHC uses it in its external interface (and internally too). It uses the Cabal lib for the parser+printer because it's easier than making its own and keeping up with spec changes.. dcoutts_: type+parser+printer nh2: dcoutts_: would it still not be easier to make this package database specification a separate thing that both ghc and cabal can depend on? It seems to me that this would be much less a moving target than Cabal-the-build-system is dcoutts_: nh2: what does make sense is to split the Cabal lib into the Distribution.* bits and the Distribution.Simple.* bits dcoutts_: nh2: it's not a natural split hvr: nh2: btw, a related thread: http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html dcoutts_: nh2: there's a lot of types shared between the .cabal format and the InstalledPackageInfo type dcoutts_: as well as parser + printer infrastructure dcoutts_: nh2: it makes sense to keep that all together, that's the Distribution.* stuff dcoutts_: as I said, what does make sense to split (it's been deliberately kept mostly-separate) is the Distribution.Simple.* part dcoutts_: nh2: and we need a parser for that part, that's the dependency that's annoying thoughtpolice: so yes, i'm going to look into it today if at all possible nh2: dcoutts_: that makes sense. ghc does not depend on Distribution.PackageDescription either, right? dcoutts_: nh2: right, it doesn't need the source package type (PackageDescription), just the installed package type (InstalledPackageInfo) dcoutts_: nh2: but splitting these into different packages would not buy us much and it's not a natural split nh2: leaving away Distribution.Simple.*, the remaining part is already so small that it indeed looks like a small enough interface dcoutts_: nh2: it'd only help JP M if the remaining part (lets call it cabal-build-simple) could build with an earlier core part (lets call it cabal-lib) (in his request in http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html) dcoutts_: nh2: and doesn't help me with my parser problems, we still cannot depend on a decent parser combinator lib dcoutts_: still have to use the crappy ReadP nh2: dcoutts_: Distribution.PackageDescription is the .cabal file format itself, right? Not sure if that should be part of the package DB spec, it changes more often and ghc can't make use of it nh2: why is it that you cannot depend on something better? dcoutts_: nh2: because ghc cannot depend on parsec easily dcoutts_: because it pulls in too many other things dcoutts_: the ghc devs objected to my suggestion dcoutts_: nh2: that's true but what does it really buy us if they're in separate packages? We still cannot guarantee to support JP M's request dcoutts_: e.g. in the switch to 1.18, there have been enough changes that we'd need the latest version of the InstalledPackageInfo hvr: dcoutts_: ...seems you have to explain that again everytime somebody brings it up =) nh2: dcoutts_: but do I not understand it right that if you put PackageDescription not into cabal-lib and only in Cabal, Cabal could actually depend on a proper parser since GHC doesn't depend on it any more? dcoutts_: nh2: it's not a monolithic parser dcoutts_: nh2: we have that Text class dcoutts_: with the combinator parsers for all the various types used in .cabal and installed package files dcoutts_: these types + parser/printer infrastructure are shared between the source and installed package files dcoutts_: so even if we split it, we still have the problem of needing a parser lib lemao: dcoutts_: I hear you wrt to the difficulties and mixed results of splitting Distribution.Simple at the same time that this GHC dependency on cabal is really problematic for all the reasons already discussed dcoutts_: lemao: I don't think splitting it would fix that lemao: dcoutts_: yes, I hear you. Maybe the right solution here is to have GHC own their own internal package info impl so Cabal and GHC can go their separate ways dcoutts_: you'd still have ghc depending on this smaller part, and Cabal/cabal-install would still depend on (usually) the latest version of that dcoutts_: lemao: but that's also not satisfactory (for cabal-lib to be a private dep of ghc) because ghc api exposes the InstalledPackageInfo type dcoutts_: it's not a private dependency of the ghc api package, it's a public dependency lemao: dcoutts_: I guess what I meant is that ghc-pkg package format/parser/etc would be a complete fork dcoutts_: which then means you cannot pass the InstalledPackageInfo from ghc api functions to anything else lemao: dcoutts_: at the same time that there are issues with the split there are real issues witht he current status quo dcoutts_: as well as meaning it'd get out of sync nh2: dcoutts_: InstalledPackageInfo looks like a very
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
Oh, I'm happy to help as well if somebody is needed to do the change, since I have much to win in the future if EclipseFP can take advantage of a new version of Cabal without having to wait for a new GHC. The split in two libraries that Duncan mentions seems the best approach to me, having InstalledPackageInfo and related classes + parsers + pretty printers available as one reasonably stable library, while having another one for the real Cabal functionality... JP On Fri, Sep 6, 2013 at 5:00 PM, Yuri de Wit yde...@gmail.com wrote: Alejandro, that is correct, as I see it. Duncan has very good points there but it seems to me that we need a concrete proposal so we can propose solutions to the problem. The fact is that the current situation is a middle of the ground that doesn't help Cabal nor Ghc. On Fri, Sep 6, 2013 at 10:54 AM, Alejandro Serrano Mena trup...@gmail.com wrote: I'm willing to help in the process, if some directions were given to me on how to tackle this problem. In any case, for me is seems fine to have a dependency from cabal to ghc, the only problem is the converse: ghc depending on cabal. Is this right? 2013/9/6 Herbert Valerio Riedel h...@gnu.org On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote: I spent some time looking into the touch points between ghc and cabal in the past, and the first oddity i saw was a direct dependency from ghc to the cabal sources. After taking a closer look it seems that ghc shares some common, low level modules with cabal that didnt seem to justify the whole dependency. The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue. [...] fyi, a similiar/related discussion took place few months ago on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html hth, hvr ___ 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 -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unary functions and infix notation
As is well known, any binary function f can be turned into an infix operator by surrounding it with backticks: f a b -- prefix application a `f` b -- infix application It is then possible to take left and right sections, i.e. partially applying f: (a `f`) -- equivalent to \b - a `f` b (`f` b) -- equivalent to \a - a `f` b This extends relatively naturally to functions of arity greater than two, where usage of a function in infix notation produces a binary operator that returns a function of arity n-2. Weirdly, however, infix notation can also be used for unary functions with polymorphic types, as the following ghci session shows: Prelude :t (`id` 1) (`id` 1) :: Num a = (a - t) - t Prelude (`id` 1) (\y - show y ++ .what) 1.what Desugaring of an equivalent source file shows that id is applied to the anonymous function, which is then applied to 1. The following example of a function that is not polymorphic in its return type behaves closer to what I would have expected: It does not work. Prelude let z = (\y - True) :: a - Bool Prelude :t (`z` True) interactive:1:2: The operator `z' takes two arguments, but its type `a0 - Bool' has only one In the expression: (`z` True) What is the purpose/reason for this behaviour? Thank you, --Johannes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unary functions and infix notation
The observation that this only applies to functions with a polymorphic return type is key. id :: a - a This can be instantiated at id' :: (a-b) - (a-b) id' :: (a-b) - a - b-- these are the same What this means is that id is a function with arity-2 whenever the first argument is arity-1, and generally id is a function of arity x+1 where x is the argument arity. Incidentally, this is exactly the same as the ($) operator. John L. On Fri, Sep 6, 2013 at 10:04 AM, Johannes Emerich johan...@emerich.dewrote: As is well known, any binary function f can be turned into an infix operator by surrounding it with backticks: f a b -- prefix application a `f` b -- infix application It is then possible to take left and right sections, i.e. partially applying f: (a `f`) -- equivalent to \b - a `f` b (`f` b) -- equivalent to \a - a `f` b This extends relatively naturally to functions of arity greater than two, where usage of a function in infix notation produces a binary operator that returns a function of arity n-2. Weirdly, however, infix notation can also be used for unary functions with polymorphic types, as the following ghci session shows: Prelude :t (`id` 1) (`id` 1) :: Num a = (a - t) - t Prelude (`id` 1) (\y - show y ++ .what) 1.what Desugaring of an equivalent source file shows that id is applied to the anonymous function, which is then applied to 1. The following example of a function that is not polymorphic in its return type behaves closer to what I would have expected: It does not work. Prelude let z = (\y - True) :: a - Bool Prelude :t (`z` True) interactive:1:2: The operator `z' takes two arguments, but its type `a0 - Bool' has only one In the expression: (`z` True) What is the purpose/reason for this behaviour? Thank you, --Johannes ___ 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] GHC API + Cabal API + Cabal version checks: is there a way out?
I'm willing to help in the process, if some directions were given to me on how to tackle this problem. In any case, for me is seems fine to have a dependency from cabal to ghc, the only problem is the converse: ghc depending on cabal. Is this right? 2013/9/6 Herbert Valerio Riedel h...@gnu.org On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote: I spent some time looking into the touch points between ghc and cabal in the past, and the first oddity i saw was a direct dependency from ghc to the cabal sources. After taking a closer look it seems that ghc shares some common, low level modules with cabal that didnt seem to justify the whole dependency. The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue. [...] fyi, a similiar/related discussion took place few months ago on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html hth, hvr ___ 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] Unary functions and infix notation
On Fri, Sep 06, 2013 at 05:04:12PM +0200, Johannes Emerich wrote: Weirdly, however, infix notation can also be used for unary functions with polymorphic types, as the following ghci session shows: Prelude :t (`id` 1) (`id` 1) :: Num a = (a - t) - t Prelude (`id` 1) (\y - show y ++ .what) 1.what There's nothing special about infix notation here: Prelude :t \x - id x 1 \x - id x 1 :: Num a = (a - t) - t Prelude (\x - id x 1) (\y - show y ++ .what) 1.what Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
Alejandro, that is correct, as I see it. Duncan has very good points there but it seems to me that we need a concrete proposal so we can propose solutions to the problem. The fact is that the current situation is a middle of the ground that doesn't help Cabal nor Ghc. On Fri, Sep 6, 2013 at 10:54 AM, Alejandro Serrano Mena trup...@gmail.comwrote: I'm willing to help in the process, if some directions were given to me on how to tackle this problem. In any case, for me is seems fine to have a dependency from cabal to ghc, the only problem is the converse: ghc depending on cabal. Is this right? 2013/9/6 Herbert Valerio Riedel h...@gnu.org On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote: I spent some time looking into the touch points between ghc and cabal in the past, and the first oddity i saw was a direct dependency from ghc to the cabal sources. After taking a closer look it seems that ghc shares some common, low level modules with cabal that didnt seem to justify the whole dependency. The right solution, imho, is to review these dependencies and move the low level ones out into a separate package that is shared by both ghc and cabal and that will rarely change. The direct side effect of this is that ghc would not be tied directly to a specific cabal version and you would not have to deal with this issue. [...] fyi, a similiar/related discussion took place few months ago on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html hth, hvr ___ 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] GHC API + Cabal API + Cabal version checks: is there a way out?
I have filed a GHC ticket under http://ghc.haskell.org/trac/ghc/ticket/8244 I hope this way we can find a solution soon. On 07/09/13 00:04, JP Moresmau wrote: Oh, I'm happy to help as well if somebody is needed to do the change, since I have much to win in the future if EclipseFP can take advantage of a new version of Cabal without having to wait for a new GHC. The split in two libraries that Duncan mentions seems the best approach to me, having InstalledPackageInfo and related classes + parsers + pretty printers available as one reasonably stable library, while having another one for the real Cabal functionality... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange IO sequence behaviour (Was: sequence causing stack overflow on pretty small lists)
Ah, that's enlightening, and a good addition to http://ghc.haskell.org/trac/ghc/ticket/8189 On Sat 07 Sep 2013 04:31:31 JST, Tom Ellis wrote: FYI, rwbarton on Reddit produced a nice answer: http://www.reddit.com/r/haskell/comments/1luan1/strange_io_sequence_behaviour/cc32ec4 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange IO sequence behaviour (Was: sequence causing stack overflow on pretty small lists)
On Wed, Sep 04, 2013 at 04:35:17PM +0100, Tom Ellis wrote: As an addendum to the recent discussion, can anyone explain why main crashes quickly with a stack overflow, whereas main' is happy to print Hi for ages (eventually crashing due to an out of memory condition)? bignum = 100 * 1000 * 1000 main = replicateM bignum (return ()) main' = replicateM bignum (putStrLn Hi) FYI, rwbarton on Reddit produced a nice answer: http://www.reddit.com/r/haskell/comments/1luan1/strange_io_sequence_behaviour/cc32ec4 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a little parsec enhancement
Dne 09/05/2013 01:38 PM, Roman Cheplyaka napsal(a): * Petr Pudlák petr@gmail.com [2013-09-05 11:18:25+0200] Unfortunately |ParsecT| constructor isn't exported so I'm not able to implement it outside /parsec/. No, but there's an 'mkPT' function which is equivalent to the ParsecT constructor. (Although I, too, wish the ParsecT constructor were exposed.) Roman Yes, I tried to use `mkPT`, but the result looked very complicated and I wasn't quite sure if it'll be working correctly in all cases. Implementing the same thing with the `ParsecT` constructor is simple and comprehensible. Best regards, Petr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Any Haskell events in Madrid next week?
Hi, There is a workshop on Functional Programming and also a conference on programming languages http://babel.ls.fi.upm.es/tpf2013/cfp_english.txt If interested, you can contact the organizers... Regards, Salvador. El 06/09/13 22:59, Joachim Breitner escribió: Hi, I'll be visiting Madrid next week (research visit) and I'm wondering if there are any Haskell or FP Group meeting or other events that might be interesting? I could possibly contribute a talk. (Both preferably in English.) Wednesday or Thursday evening might would most convenient. Greetings, Joachim ___ 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] Unary functions and infix notation
But we can do next: Prelude :set XPostfixOperators Prelude let z = (\y - True) :: a - Bool Prelude :t (True `z`) But still `z` True ~\a - a `z` True~ \a - z a True and `z` must be a function with minimum 2 arguments -- View this message in context: http://haskell.1045720.n5.nabble.com/Unary-functions-and-infix-notation-tp5735766p5735807.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a little parsec enhancement
The exported `mkPT` is equivalent to the old 'ParsecT' data constructor from parsec 3.0.x. I wouldn't mind exporting a similar alias for the new 'ParsecT' constructor from 3.1.x. On Fri, Sep 6, 2013 at 2:21 PM, Petr Pudlák petr@gmail.com wrote: Dne 09/05/2013 01:38 PM, Roman Cheplyaka napsal(a): * Petr Pudlák petr@gmail.com [2013-09-05 11:18:25+0200] Unfortunately |ParsecT| constructor isn't exported so I'm not able to implement it outside /parsec/. No, but there's an 'mkPT' function which is equivalent to the ParsecT constructor. (Although I, too, wish the ParsecT constructor were exposed.) Roman Yes, I tried to use `mkPT`, but the result looked very complicated and I wasn't quite sure if it'll be working correctly in all cases. Implementing the same thing with the `ParsecT` constructor is simple and comprehensible. Best regards, Petr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Any Haskell events in Madrid next week?
Hi, I’ll be visiting Madrid next week (research visit) and I’m wondering if there are any Haskell or FP Group meeting or other events that might be interesting? I could possibly contribute a talk. (Both preferably in English.) Wednesday or Thursday evening might would most convenient. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
