In case you want to try here is an updated lenses package.
Best,
Doaitse
PS: I contacted Job (the author) in order to get things updated
lenses.cabal
Description: Binary data
Setup.hs
Description: Binary data
LICENSE
Description: Binary data
Am Donnerstag, 22. Januar 2015, 11:19:37 schrieb Albert Y. C. Lai:
On 2015-01-21 10:36 AM, Volker Wysk wrote:
I have installed/registered a new version of a package with cabal by
accident. How can I remove it again?
See my http://www.vex.net/~trebla/haskell/sicp.xhtml#remove . In fact
Am Mittwoch, 21. Januar 2015, 19:39:50 schrieben Sie:
On 2015-01-21 at 16:36:08 +0100, Volker Wysk wrote:
I have installed/registered a new version of a package with cabal by
accident. How can I remove it again?
Not sure if this is what you want, but the `cab` tool has an `uninstall`
sub
On 2015-01-22 at 09:04:30 +0100, Volker Wysk wrote:
I have installed/registered a new version of a package with cabal by
accident. How can I remove it again?
Not sure if this is what you want, but the `cab` tool has an `uninstall`
sub-command to unregister and remove installed packages
On 2015-01-21 10:36 AM, Volker Wysk wrote:
I have installed/registered a new version of a package with cabal by accident.
How can I remove it again?
See my http://www.vex.net/~trebla/haskell/sicp.xhtml#remove . In fact,
read the whole thing
On 2015-01-21 at 16:36:08 +0100, Volker Wysk wrote:
I have installed/registered a new version of a package with cabal by
accident.
How can I remove it again?
Not sure if this is what you want, but the `cab` tool has an `uninstall`
sub-command to unregister and remove installed packages.
[1
I use a shell script. It's really useful, surely there's some
official way to do this?
#!/bin/zsh
package=$1
if ! ghc-pkg describe $package /dev/null; then
echo no such package: $package
exit 1
fi
ghcdir=$(ghc --print-libdir)
function field() {
ghc-pkg field $package $1 | cut -d
Hi!
I have installed/registered a new version of a package with cabal by accident.
How can I remove it again?
There is something in ~/.cabal/packages/hackage.haskell.org, but the defective
version isn't included.
bye
V.W.
___
Glasgow-haskell-users
On Wed, Jan 21, 2015 at 11:19 AM, Volker Wysk vertei...@volker-wysk.de
wrote:
I'm also missing a command to set the Default available version.
You don't set that; it's specified in the downloaded package index in the
package repo.
--
brandon s allbery kf8nh sine
Am Mittwoch, 21. Januar 2015, 23:56:53 schrieben Sie:
I use a shell script. It's really useful, surely there's some
official way to do this?
It looks like a remove command to cabal has been forgotten... This would
be a feature request.
I'm also missing a command to set the Default available
time (might be as short as an hour) before trying to install it from
Hackage.
You also need to run cabal update to download the updated package index
so your local cabal-install knows about the new package.
I'm not completely sure what happened, but now it seems to work. The Default
available
)
rejecting: hsshellscript-3.3.2, 3.3.1, 3.3.0, 3.2.0, 3.1.0 (global constraint
requires ==3.3.3)
Dependency tree exhaustively searched.
What does this mean...?
I've also in vain searched for a way to remove a cabal installed package.
Thanks,
Volker
...
Configuring hsshellscript-3.3.3...
Building hsshellscript-3.3.3...
Preprocessing library hsshellscript-3.3.3...
In-place registering hsshellscript-3.3.3...
Creating package registration file: /tmp/pkgConf-hsshellscript-3.37397.3
Installing library in
/home/v/.cabal/lib/x86_64-linux-ghc-7.8.3
to install it from
Hackage.
You also need to run cabal update to download the updated package index
so your local cabal-install knows about the new package.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb
I've just taken over maintainership of the boxes package, and will be
making a maintenance release shortly (as soon as I figure out how and get
added to the maintainers group). The package, however, currently suffers
from a paucity of bug reports (no problem) and feature requests (not so
great
You can specify the pre-processor in the `ghc-options' field in the
cabal file, e.g.
ghc-options: -pgmPcpphs
Francesco
On 23 December 2014 at 17:14, Brandon Allbery allber...@gmail.com wrote:
On Tue, Dec 23, 2014 at 11:10 AM, Dominic Steinitz domi...@steinitz.org
wrote:
How very clever
I forgot to mention that `cpphs' can mimick gcc's cpp, with the flag
`-cpp'. In Agda we have
ghc-options: -pgmPcpphs -optP--cpp
Francesco
On 24 December 2014 at 10:50, Francesco Mazzoli f...@mazzo.li wrote:
You can specify the pre-processor in the `ghc-options' field in the
cabal file,
Thank you very much everyone. I now have a version of yarr which compiles under
ghc 7.8.3. I have yet to do the conditional compilation hackery to support back
versions but then I can make a release.
What a great community :-)
Dominic Steinitz
domi...@steinitz.org
Erik,
Thank you very much. With that clue the compilation now doesn’t fail at that
particular point.
The bad news is it now fails to compile this module
https://hackage.haskell.org/package/yarr-1.3.2/docs/src/Data-Yarr-Utils-Primitive.html#clampM%27
with a parse error(!). Not only do I
is it now fails to compile this module
https://hackage.haskell.org/package/yarr-1.3.2/docs/src/Data-Yarr-Utils-Primitive.html#clampM%27
with a parse error(!). Not only do I not have much experience with TH
but this has now exposed my ignorance of CPP.
Data/Yarr/Utils/Primitive.hs:119:126
On Tue, Dec 23, 2014 at 10:46 AM, Dominic Steinitz domi...@steinitz.org
wrote:
To restate the problem: this is from code that has not been changed for 2
years. I get
Examples.hs:42:42: Parse error in pattern: con
Failed, modules loaded: none.
I think I see the problem. Are you by any
How very clever of you and thank you very much. Changing ‘ to 1 does fix the
problem.
I would have thought this would work
cabal install --with-gcc=gcc-4.9
But sadly I still got the same error.
Do I need a special version of cpphs?
Dominic Steinitz
domi...@steinitz.org
https://hackage.haskell.org/package/yarr-1.3.2/docs/src/Data-Yarr-Utils-Primitive.html#clampM%27
with a parse error(!). Not only do I not have much experience with TH but
this has now exposed my ignorance of CPP.
Data/Yarr/Utils/Primitive.hs:119:126: Parse error in pattern: con
If I
On Tue, Dec 23, 2014 at 11:10 AM, Dominic Steinitz domi...@steinitz.org
wrote:
How very clever of you and thank you very much. Changing ‘ to 1 does fix
the problem.
I would have thought this would work
cabal install --with-gcc=gcc-4.9
But sadly I still got the same error.
I think that
On Wednesday 09 April 2014, 23:42:26, Carter Schonwald wrote:
i bet you have cabal --version reply with 1.16
1) cabal update
2) cabal install cabal-install
3) rm ~/.cabal/config # old pre 1.18 config should go!
4) cabal update # also probably add ~/.cabal/bin to path
There should be a
of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
Data/Vector/Fusion/Stream/Monadic.hs,
dist/build/Data/Vector/Fusion/Stream/Monadic.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading
On 2014-04-10 at 06:00:43 +0200, Vivian McPhail wrote:
Indeed.
It was using the wrong cabal-install version. Even though I had installed
the newest cabal-install I needed to restart the xterm I was working
in.
Lemme guess, you're using Bash, and you installed cabal-install into a
new
Yes, exactly.
On 10 April 2014 22:03, Herbert Valerio Riedel h...@gnu.org wrote:
On 2014-04-10 at 06:00:43 +0200, Vivian McPhail wrote:
Indeed.
It was using the wrong cabal-install version. Even though I had
installed
the newest cabal-install I needed to restart the xterm I was
Yes, exactly. Thank you.
On 10 April 2014 22:03, Herbert Valerio Riedel h...@gnu.org wrote:
On 2014-04-10 at 06:00:43 +0200, Vivian McPhail wrote:
Indeed.
It was using the wrong cabal-install version. Even though I had
installed
the newest cabal-install I needed to restart the xterm
Hi,
Ubuntu 12.04, 64 bit x86, ghc 7.8.1 gives the following:
# cabal install --global vector
...
[ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
Data/Vector/Fusion/Stream/Monadic.hs,
dist/build/Data/Vector/Fusion/Stream/Monadic.o )
Loading package ghc-prim ... linking ... done.
Loading
haskell.vivian.mcph...@gmail.com wrote:
Hi,
Ubuntu 12.04, 64 bit x86, ghc 7.8.1 gives the following:
# cabal install --global vector
...
[ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
Data/Vector/Fusion/Stream/Monadic.hs,
dist/build/Data/Vector/Fusion/Stream/Monadic.o )
Loading package
,
Ubuntu 12.04, 64 bit x86, ghc 7.8.1 gives the following:
# cabal install --global vector
...
[ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
Data/Vector/Fusion/Stream/Monadic.hs,
dist/build/Data/Vector/Fusion/Stream/Monadic.o )
Loading package ghc-prim ... linking ... done.
Loading
Albert Y. C. Lai wrote
On 13-07-25 03:14 PM, harry wrote:
How can I change the location that ghc and ghc-pkg use for the user's
package
directory? I'm running GHC in a very restricted environment where I don't
have access to $HOME, but I can use specific subdirectories.
Cannot. But you
harry wrote
$ ghc-pkg check --package-db=~/cabal
ghc-pkg: ~/cabal: openFile: does not exist (No such file or directory)
$ ls ~/cabal
package.cache
Ah, the ~ seems to have been tripping it up. Thank you.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/change-location
On Sun, Jul 28, 2013 at 5:35 AM, harry volderm...@hotmail.com wrote:
$ ghc-pkg check --package-db=~/cabal
ghc-pkg: ~/cabal: openFile: does not exist (No such file or directory)
$ ls ~/cabal
package.cache
Yet another reason to avoid ~... it's (a) only expanded by the shell, and
(b
How can I change the location that ghc and ghc-pkg use for the user's package
directory? I'm running GHC in a very restricted environment where I don't
have access to $HOME, but I can use specific subdirectories.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/change
On 13-07-25 03:14 PM, harry wrote:
How can I change the location that ghc and ghc-pkg use for the user's package
directory? I'm running GHC in a very restricted environment where I don't
have access to $HOME, but I can use specific subdirectories.
Cannot. But you have another option. GHC
NoImplicitPrelude #-}
| everywhere and import stuff explicitly. base-pure would probably
| provide its subset of the Prelude in Prelude.Pure, to be
| imported explicitly.
| 2. Prelude goes to a separate shim package, base-prelude. Extra
| dependency required
this?
Sure, done, including stated opinions so far:
http://hackage.haskell.org/trac/ghc/wiki/SplitBase#HandlingPrelude
I also noticed an advantage of (P2) (No Prelude in any of the shim
packages, but in a separate base-prelude package): It allows programmers
to mix conveniently the shim packages
lets make sure
there's still a base package to import that gives people what they have
before. :) Other than that I'm quite excited about the prospects of
splitting up base a bit.
-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users
would probably
provide its subset of the Prelude in Prelude.Pure, to be
imported explicitly.
2. Prelude goes to a separate shim package, base-prelude. Extra
dependency required, packages that want to only depend on
base-pure have no Prelude to use, same problem
functions),
but having a shim package purely for the Prelude seems excessive.
This is a problem regardless of whether we do A or B or both.
I think we should avoid getting bogged down in one small detail at this
stage. If we make the bulk of the changes now then we still have a few
months to polish
not sure it is just a small detail: The handling of Prelude will
influence how practical it is to use the shim package, and how practical
it is to use just some of the shim packages.
If you don't like the idea of putting it in its own package, then I
think either the file-io package (as that's
On Tue, Mar 12, 2013 at 03:58:28PM +0100, Joachim Breitner wrote:
Both have issues: Putting it in file-io will cause everyone to depend on
file-io
If it ended up there, then we'd presumably encourage people to use
NoImplicitPrelude and import e.g. list functions from Data.List rather
than
-pure provides the pure Prelude and base-io adds the IO
functions.
I like this proposal, but it goes further than necessary for your goal,
and it could lead to some messy conflicts. All you need is
2. Prelude goes to a separate shim package, base-prelude. Extra
dependency
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Joachim Breitner
| Sent: 07 March 2013 20:22
| To: glasgow-haskell-users@haskell.org
| Subject: Re: base package -- goals
|
| Hi,
|
| Am Dienstag
On Mon, Mar 11, 2013 at 4:45 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
B Better for internal implementation (eg using containers or bytestring in
base)
Note that this also means better code for external clients, as we can offer
e.g. a better System.IO that lets people use Handles to
Hi,
Am Dienstag, den 26.02.2013, 10:08 + schrieb Simon Peyton-Jones:
I think it would be vv helpful to have all these goals articulated on
the wiki page.
http://hackage.haskell.org/trac/ghc/wiki/SplitBase
well, all the goals are there (or are they not sufficiently well
On 25/02/13 18:05, Ian Lynagh wrote:
On Mon, Feb 25, 2013 at 06:38:46PM +0100, Herbert Valerio Riedel wrote:
Ian Lynagh i...@well-typed.com writes:
[...]
If we did that then every package would depend on haskell2010, which
is fine until haskell2013 comes along and they all need to be changed
now we have bits and
pieces of unix/Win32 in the base package, some of which have to be
re-exported via internal modules in base to unix/Win32 proper
(System.Posix.Internals).
I seem to recall the situation with signal handlers being a bit of a
mess: the code to handle signals is in base
On Wed, Feb 27, 2013 at 04:54:35PM +, Simon Marlow wrote:
On 25/02/13 18:05, Ian Lynagh wrote:
Personally, I don't think the language report should be specifying the
content of libraries at all,
It's not that straightforward, because the language report refers to
various library
be interesting to see if Text and Bytestring (without the file
IO parts) can be compiled using the base-foreign package extracted here
https://github.com/nomeata/packages-base/tree/base-split/base-foreign.
Looking at the imports, it seems possible. Then a base-io-system package
can indeed depend
I think it would be vv helpful to have all these goals articulated on the wiki
page.
http://hackage.haskell.org/trac/ghc/wiki/SplitBase
For the avoiding version bump goal, I still don't see why having a simple
shim package on top whose API is stable, and whose version number changes
Hi,
Am Samstag, den 23.02.2013, 10:27 + schrieb Simon Peyton-Jones:
I’d like to be very clear about goals, though. I have not been
following this thread closely enough, but is there a Wiki page that
explains what the goals of the base-package break-up is?
I added a Goals section
be useful.
SImon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Joachim Breitner
| Sent: 25 February 2013 13:32
| To: glasgow-haskell-users@haskell.org
| Subject: Re: base package -- goals
|
| Hi
is, and why a
simple API wrapper approach would not solve it, would be useful.
On the wiki page you say:
SPJ: But that goal needs a bit of unpacking. Suppose we divided base
into six, base1, base2, base3, etc, but each was a vertical silo and
every other package depended on all six
the problem: What and where is the Prelude...
but maybe let’s postpone this.
I'd put it in its own package for now, and then look at whether/what it
should be merged with later.
I'm in 2 minds about it. On the one hand, I'm sure that lots of people
won't like a single-module package that essentially
Somebody claiming to be Ian Lynagh wrote:
On Mon, Feb 25, 2013 at 02:31:56PM +0100, Joachim Breitner wrote:
In any case there is still the problem: What and where is the Prelude...
but maybe let’s postpone this.
I'd put it in its own package for now, and then look at whether/what it
should
* Stephen Paul Weber singpol...@singpolyma.net [2013-02-25 11:29:42-0500]
Why shouldn't Prelude (and other really stable, standard modules)
just live in the `haskell2010` package?
Because then we can't make changes to it without producing a new
language standard.
Roman
Somebody claiming to be Roman Cheplyaka wrote:
* Stephen Paul Weber singpol...@singpolyma.net [2013-02-25 11:29:42-0500]
Why shouldn't Prelude (and other really stable, standard modules)
just live in the `haskell2010` package?
Because then we can't make changes to it without producing a new
it in its own package for now, and then look at whether/what it
should be merged with later.
Why shouldn't Prelude (and other really stable, standard modules)
just live in the `haskell2010` package?
If we did that then every package would depend on haskell2010, which is
fine until haskell2013
Ian Lynagh i...@well-typed.com writes:
[...]
If we did that then every package would depend on haskell2010, which
is fine until haskell2013 comes along and they all need to be changed
(or miss out on any improvements that were made).
...wouldn't there also be the danger of type(class
On Mon, Feb 25, 2013 at 06:38:46PM +0100, Herbert Valerio Riedel wrote:
Ian Lynagh i...@well-typed.com writes:
[...]
If we did that then every package would depend on haskell2010, which
is fine until haskell2013 comes along and they all need to be changed
(or miss out on any
Hi all,
Let me add the goals I had in mind last time I considered trying to split
base.
1. I'd like to have text Handles use the Text type and binary Handles use
the ByteString type. Right now we have this somewhat awkward setup where
the I/O APIs are spread out and bundled with pure types.
It's great work, thanks Joachim.
I'd like to be very clear about goals, though. I have not been following this
thread closely enough, but is there a Wiki page that explains what the goals of
the base-package break-up is?
I believe that the driving goal is:
*to allow changes
* Simon Peyton-Jones simo...@microsoft.com [2013-02-23 10:27:46+]
I believe that the driving goal is:
*to allow changes to internals without forcing a version-bump
on 'base', on which every package depends
This is a good goal.
Another goal could be to make the packages more
somewhere... And
the same question will arise if Data.Date should go to a package of its
own.
Also, I notice that there is an issue with “internal” modules (mostly
GHC.something) that should not be part of some stable API, but needed to
implement packages further down. Should they just
Hi Joachim.
Glad to see you're making progress on this. Once we're done exploring how
fine-grained we can make the division we might want to pull back a bit and
consider what logical groupings makes sense. For example, even if the float
functionality can be split from the int functionality, I
Hi,
Am Freitag, den 22.02.2013, 11:38 -0800 schrieb Johan Tibell:
In addition, I don't think we want to say that e.g. pure data
structures can't depend on the FFI. While their current implementation
might not use the FFI, what if we want to use it in the future. We'd
have to reshuffle the
+ specific re-exporting
packages approach, which wasn’t particularly well received here.
I don't know about entangled implementations. But I'd like to have a base
package (e.g. your base-pure) that has a consistent set of basic data types
e.g. Int, Word, Float, Double, Char, String, ByteString, Text
On Fri, Feb 22, 2013 at 07:52:00PM +0100, Joachim Breitner wrote:
Of course with too much splitting one runs in the Bane of the Orphaned
Instances – neither should base-foreign require base-float nor the other
way around, but Storable Double needs to be define somewhere...
This is no
their current implementation might not use
the FFI, what if we want to use it in the future. We'd have to reshuffle
the packages again.
I think the issue is what a package exports, rather than what it depends
on. Changing the package dependencies later won't affect users of the
package.
Thanks
Comparing hash, ptr, str gives you a pretty good acceptance/rejection test.
hash for the quick rejection, ptr for quick acceptance, str for accuracy.
Especially since the particular fingerprints for Typeable at least are
usually made up of 3 bytestrings that were just stuffed in and forgotten
+-- report
+data IOFail = IOFail String
+
+instance Typeable IOFail -- deriving does not work without package
+instance Show IOFail -- name changes to GHC
+instance Exception IOFail
+
I like the idea of making IOFail a separate exception type.
-instance Exception IOException
+instance
On 20/02/13 17:12, Ian Lynagh wrote:
On Fri, Feb 15, 2013 at 02:45:19PM +, Simon Marlow wrote:
Remember that fingerprinting is not hashing. For fingerprinting we
need to have a realistic expectation of no collisions. I don't
think FNV is suitable.
I'm sure it would be possible to
Hi,
Am Donnerstag, den 21.02.2013, 09:42 + schrieb Simon Marlow:
The trick is indeed neat, but only if it is possible to make IOFail
completely invisible. If it isn't possible to make it completely
invisible, then I would prefer IOFail to be a first-class exception type
without the
it to a Maybe Handle. This
way, the base-io package does not have to include the definition, but
the IOError data type still has place for it.
If the NotYetAHandle constructor is not exported, and base-io-file
defines functions NotYetAHandle - Handle and Handle - NotYetAHandle
via unsafeCoerce
instance of IOException will also catch this, converting the
+-- IOFail to a UserError, for compatibility and consistency with the Haskell
+-- report
+data IOFail = IOFail String
+
+instance Typeable IOFail -- deriving does not work without package
+instance Show IOFail -- name changes to GHC
On Fri, Feb 15, 2013 at 02:45:19PM +, Simon Marlow wrote:
Remember that fingerprinting is not hashing. For fingerprinting we
need to have a realistic expectation of no collisions. I don't
think FNV is suitable.
I'm sure it would be possible to replace the C md5 code with some
are going to end up using forkOS?
Another good reason to try to have a pure ground library.
Based on base-pure, the next step would be to check if FFI can be
provided without IO (but I doubt that is difficult), so there would be
an base-io package on top of base-pure, and then bytestring can depend
| Doesn't the FFI pull in some part of the I/O layer, though? In
| particular threaded programs are going to end up using forkOS?
|
| Another good reason to try to have a pure ground library.
Remember that we have UNSAFE ffi calls and SAFE ones.
The SAFE ones may block, cause GC etc. They
/tree/base-io
GHC would complain that the CInt type is not valid in a ffi call
(probably due to the different package name), so I replaced foreign
declarations by regular ones defined using “undefined” – after all I’m
just trying to discover how things can be split at all and just work
towards
On 15/02/13 09:36, Simon Peyton-Jones wrote:
| Doesn't the FFI pull in some part of the I/O layer, though? In
| particular threaded programs are going to end up using forkOS?
|
| Another good reason to try to have a pure ground library.
Remember that we have UNSAFE ffi calls and SAFE ones.
On 15/02/13 08:36, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 14.02.2013, 21:41 -0500 schrieb brandon s allbery
kf8nh:
On Thursday, February 14, 2013 at 8:14 PM, Johan Tibell wrote:
On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner
m...@joachim-breitner.de wrote:
I don't think having FFI
On 15/02/13 12:22, Joachim Breitner wrote:
Hi,
more progress: On top of base-pure, I created base-io involving GHC/IO
and everything required to build it (which pulled in ST, some of Foreign
and unfortunately some stuff related to Handles and Devices, because it
is mentioned in IOException).
On Thu, Feb 14, 2013 at 03:48:51PM +0100, Joachim Breitner wrote:
Yesterday, I experimented a bit with base’s code, [...]
Maybe the proper is to reverse the whole approach: Leave base as it is,
and then build re-exporting smaller packages (e.g. a base-pure) on top
of it. The advantage is:
On Thu, Feb 14, 2013 at 6:48 AM, Joachim Breitner
m...@joachim-breitner.dewrote:
Maybe the proper is to reverse the whole approach: Leave base as it is,
and then build re-exporting smaller packages (e.g. a base-pure) on top
of it. The advantage is:
* No need to rewrite the tightly
As a super obvious aside, we could just switch code paths based on
platform/environment. That lets you keep the fast code path and have a pure
fallback for the javascripters. Just propagate an FFI_AVAILABLE flag into the
compilation unit. We're going to have a number of these points which force
Hi,
Am Freitag, den 15.02.2013, 14:50 + schrieb Simon Marlow:
On 15/02/13 12:22, Joachim Breitner wrote:
Hi,
more progress: On top of base-pure, I created base-io involving GHC/IO
and everything required to build it (which pulled in ST, some of Foreign
and unfortunately some stuff
Hi,
Am Donnerstag, den 14.02.2013, 02:21 + schrieb Ian Lynagh:
On Wed, Feb 13, 2013 at 07:32:06PM +0100, Joachim Breitner wrote:
I have started a wikipage with the list of all modules from base,
for a
first round of shuffling, grouping and brainstorming:
.
so it is not clear how to pull out a pure base without IO and Foreign.
Are there any good tricks how to break these interdependencies?
We'll probably end up with a package (let's say ghc-bottom for now)
right at the bottom of the hierarchy which contains a minimal set of
definitions for Typeable
Hi,
I made a little progress after crippling GHC.Fingerprint:
The package at
https://github.com/nomeata/packages-base/tree/base-pure
(Branch base-pure) builds and contains just these modules:
./Control/Applicative.hs
./Control/Arrow.hs
./Control/Category.hs
./Control/Monad/Fix.hs
./Control
On Thu, Feb 14, 2013 at 8:45 AM, Joachim Breitner
m...@joachim-breitner.dewrote:
./Control/Applicative.hs
./Control/Arrow.hs
./Control/Category.hs
./Control/Monad/Fix.hs
./Control/Monad.hs
./Data/Bits.hs
./Data/Bool.hs
./Data/Either.hs
./Data/Eq.hs
./Data/Foldable.hs
./Data/Function.hs
Hi,
Am Donnerstag, den 14.02.2013, 13:19 -0800 schrieb Johan Tibell:
That's great. I'm curious I was under the impression that it was hard
to split out a pure subset as functions might call 'error' (e.g. due
to incomplete pattern matches) and that would pull in the whole I/O
subsystem. How
On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner
m...@joachim-breitner.dewrote:
Hi,
Am Donnerstag, den 14.02.2013, 13:19 -0800 schrieb Johan Tibell:
That's great. I'm curious I was under the impression that it was hard
to split out a pure subset as functions might call 'error' (e.g. due
On Thursday, February 14, 2013 at 8:14 PM, Johan Tibell wrote:
On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner m...@joachim-breitner.de
(mailto:m...@joachim-breitner.de) wrote:
I don't think having FFI far down the stack is a problem. There are lots of
pure data types we'd like in the pure
* Simon Marlow marlo...@gmail.com [2013-02-13 09:00:15+]
It's feasible to split base, but to a first approximation what you
end up with is base renamed to ghc-base, and then the new base
contains just stub modules that re-export stuff from ghc-base.
It would be great to have a portable
Hi,
Am Mittwoch, den 13.02.2013, 11:34 +0200 schrieb Roman Cheplyaka:
It would be great to have a portable base, without any GHC-specific
stuff in it. After all, modules like Control.Monad or Data.Foldable
are pure Haskell2010.
while you are considering to split base, please also consider
Somebody claiming to be Roman Cheplyaka wrote:
* Simon Marlow marlo...@gmail.com [2013-02-13 09:00:15+]
It's feasible to split base, but to a first approximation what you
end up with is base renamed to ghc-base, and then the new base
contains just stub modules that re-export stuff from
Hi,
Am Mittwoch, den 13.02.2013, 13:58 + schrieb Ian Lynagh:
If we go this route, then we would probably want to end up without a
package called 'base', and then to make a new package called 'base'
that just re-exports modules from all the new packages.
can you transparently re-export
1 - 100 of 410 matches
Mail list logo
