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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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 ++
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
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
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
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
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
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
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:
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
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.
28 matches
Mail list logo
