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 replace
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
about
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
>
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
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
On Thu, Feb 14, 2013 at 6:48 AM, Joachim Breitner
wrote:
> 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 intertwined base.
>
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
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). Thi
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
wrote:
I don't think having FFI far down the stack is a p
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.
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). This is the list of modules:
Foreign.C.
| > 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. The
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
> > wrote:
> > I don't think having FFI far down the stack is a problem. There are
> > lots of pur
On Thursday, February 14, 2013 at 8:14 PM, Johan Tibell wrote:
> On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner (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 data" layer (e.g. byt
On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner
wrote:
> 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
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. Ho
On Thu, Feb 14, 2013 at 8:45 AM, Joachim Breitner
wrote:
> ./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
> ./Data/Func
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/Monad
On Thu, Feb 14, 2013 at 03:48:51PM +0100, Joachim Breitner wrote:
>
> Yesterday, I experimented a bit with base’s code, first beginning with
> as few modules as possible and adding what’s required; then starting
> with the whole thing and trying to remove e.g. IO.
>
> But clearly it is not easy:
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:
> >
> > http://hackag
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:
>
> http://hackage.haskell.org/trac/ghc/wiki/SplitBase
Great, thanks for taking the lead on this!
On Wed, Feb 13, 2013 at 4:32 PM, Joachim Breitner
wrote:
>> No. But there are currently no packages that depend on both base and io,
>> and anyone adding a dependency on io would remove the base dependency at
>> the same time.
>
> hmm, that reminds me of how haskell98 was handled, and it was sligh
Somebody signing messages as 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:
http://hackage.haskell.org/trac/ghc/wiki/SplitBase
Looks like a good start!
Here's an idea: why not use the `haske
Hi,
I have started a wikipage with the list of all modules from base, for a
first round of shuffling, grouping and brainstorming:
http://hackage.haskell.org/trac/ghc/wiki/SplitBase
Am Mittwoch, den 13.02.2013, 18:09 + schrieb Ian Lynagh:
> On Wed, Feb 13, 2013 at 06:28:22PM +0100, Joachim B
On Wed, Feb 13, 2013 at 06:28:22PM +0100, Joachim Breitner wrote:
>
> 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-expor
Somebody claiming to be Roman Cheplyaka wrote:
* Simon Marlow [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
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 s
27 matches
Mail list logo
