Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
On 12/05/2011 18:24, dm-list-haskell-c...@scs.stanford.edu wrote: At Thu, 12 May 2011 16:45:02 +0100, Simon Marlow wrote: There are no locks here, thanks to the message-passing implementation we use for throwTo between processors. Okay, that sounds good. So then there is no guarantee about ordering of throwTo exceptions? That seems like a good thing since there are other mechanisms for synchronization. What kind of ordering guarantee did you have in mind? We do guarantee that in throwTo t e1 throwTo t e2 Thread t will receive e1 before e2 (obviously, because throwTo is synchronous and only returns when the exception has been raised). ... Pending exceptions are processed in LIFO order (for no good reason other than performance)... I mean, suppose you have three CPUs, A, B, and C running threads ta, tb, and tc. Then should the following order of events be permitted? AB C throwTo tc e1 throwTo tb e2 catch e2 poke p x peek p (sees x) catch e1 I would argue that this is just fine, that one should rely on MVars if one cares about ordering. But I'm not sure what Pending exceptions are processed in LIFO order means in the presence of relaxed memory consistency. Oh, that can't happen. A's first throwTo only returns when the exception has been raised in C - throwTo is like a synchronous communication in this sense. We went to-and-fro on this aspect of the throwTo design a few times. The synchronous semantics for throwTo tends to be more useful for the programmer, but is harder to implement. If you want asynchronous throwTo, you can always get it with forkIO.throwTo. As far as memory consistency goes, we claim to provide sequential consistency for IORef and IOArray operations, but not for peeks and pokes. The reason I'm asking is that I want to make sure I never end up having to pay the overhead of an MFENCE instruction or equivalent every time I use unmaskAsyncExceptions#... Right, I don't think that should be necessary. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Sending messages up-and-down the iteratee-enumerator chain [Was: iterIO-0.1]
David Mazie'res wrote:
What you really want is the ability to send both upstream and
downstream control messages. Right now, I'd say iterIO has better
support for upstream control messages, while iteratee has better
support for downstream messages, since iteratee can just embed an
Exception in a Stream. (I'm assuming you could have something like a
'Flush' exception to cause output to be flushed by an Iteratee that
was for some reason buffering some.)
Can you explain how iteratee could keep track of the stream position?
I'm not saying it's impossible, just that it's a challenging puzzle to
make the types come out and I'd love to see the solution.
The code described in this message does exactly that. We illustrate
enumerator's telling something to iteratees in the middle of the stream
(to Flush their buffers) as well as iteratee's asking an enumerator of
something (the stream position). The chunk of a stream and
EOF are themselves `control' messages that an enumerator may send;
the request for a new chunk, just like the request for a stream position,
is just one of the requests an iteratee may ask.
The set of messages an enumerator may send and the set of requests an
iteratee may ask are both treated as open unions. We illustrate the
explicit coding of open unions, to let the type checker ensure that
what an iteratee may ask an enumerator can answer, and what an
enumerator may tell an iteratee can understand.
In process calculus lingo, we implement external (to iteratee) choice,
internal choice, and a form of session types.
For clarity, we implement a greatly simplified version of
iteratees. We assume a single-character chunk, which an iteratee
always consumes. Chunking of a stream and look-ahead are orthogonal
concerns and have been discussed already.
The stream represents the external, producer choice:
data Stream ie =
Chunk Char -- the current character
| SExc ie -- A message from the enumerator
The chunk is an ever-present option; other choices include EOF and
Flush:
data EOF = EOF
data Flush = Flush
The iteratee represents the internal, consumer choice:
data Iter ee ie a =
Done a
| Cont (Stream ie - Iter ee ie a)
| IExc (ee (Iter ee ie) a)-- other requests
Cont is a typical request from an iteratee. It is so typical that we
wire it in (we could've treated it as other requests, like Tell).
The iteratee is parametrised by what messages it understands
and what requests it may ask.
Iteratees compose as a monad:
instance Bindable ee = Monad (Iter ee ie) where
return = Done
Done a = f = f a
Cont k = f = Cont (\x - k x = f)
IExc ee = f = IExc (comp ee f)
All requests must be bindable, so they can percolate
class Bindable ee where
comp :: Monad m = ee m a - (a - m b) - ee m b
An exception is a sort of request (especially if the exception
is resumable)
data Err m a = Err (() - m a)
instance Bindable Err where
comp (Err k) f = Err (\x - k x = f)
Another sort of request is to tell the position
data Tell m a = Tell (Int - m a)
instance Bindable Tell where
comp (Tell k) f = Tell (\x - k x = f)
We use Either (or higher-kinded E2) to build unions:
class Sum e c where
inj :: e - c
prj :: c - Maybe e
class Sum2 (e :: (* - *) - * - *) (c :: (* - *) - * - *) where
inj2 :: e m a - c m a
prj2 :: c m a - Maybe (e m a)
Iteratees are explicit in what they receive on the stream,
the external choices they may handle.
But they leave the requests polymorphic to ease composing with
other iteratees which may asks more requests.
Here is the simplest iteratee, which doesn't do anything but asks for
trouble
ierr :: Sum2 Err c = Iter c ie a
ierr = IExc . inj2 $ Err (\_ - ierr)
A typical iteratee, like the head below, asks for little and accepts
little:
iehead :: Sum2 Err c = Iter c EOF Char
iehead = Cont step
where
step (Chunk a) = Done a
step (SExc EOF) = ierr
We can ask for the current position:
itell :: Sum2 Tell c = Iter c ie Int
itell = IExc . inj2 $ Tell Done
Enumerators, in contrast, are explicit in what requests they may
satisfy, but implicit in what they may send on the stream.
A typical, small enumerator requires that an iteratee understand at
least EOF, and answers no requests beyond errors.
en_str :: Sum EOF ie = String - Iter Err ie x - Iter Err ie x
en_str _ i@Done{} = i
en_str _ (IExc x) | Just (Err _) - prj2 x = ierr
en_str (Cont k) = k eof
en_str (h:t) (Cont k) = en_str t $ k (Chunk h)
A typical enumeratee, like the following keeper of
positions, is explicit in requests it accepts: only Tell and Err.
The Tell requests are satisfied and not propagated.
The stream messages are relayed from the outer to the inner stream:
en_pos :: Int - Iter (E2 Err Tell) ie x - Iter Err ie x
en_pos _ (Done x) = return x
en_pos n (Cont k) = Cont (\s - en_pos (n+1) (k s))
en_pos _ (IExc x) | Just (Err _) - prj2
Re: [Haskell-cafe] how to force hackage to use ghc 6.12.3
On Monday 09 May 2011 12:09:22 Ross Paterson wrote: That will stop users from building it with ghc 7.0, but I'm afraid the build client only uses the latest version, so these won't be fixed until ghc 7.2 is released. Daniel, Ross, Thank you for your help. I decided to add base 4.3 to stop users trying to compile it with ghc 7.* and provided links to haddock documentation hosted elsewhere for the time being. Michal -- |o| Michal Konecny mikkone...@gmail.com |o|http://www-users.aston.ac.uk/~konecnym/ |o|office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston 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
Re: [Haskell-cafe] Using cmake with haskell
Talking about that, what are the differences between cabal-install and cabal-dev? Is cabal-dev (which I've never used nor installed) more suited for incremental development? 2011/5/12 Jason Dagit dag...@gmail.com On Wed, May 11, 2011 at 6:13 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: [snip] 1) Cabal is a tool that can only be used to build Haskell packages with some supporting C/C++ code thrown in and 2) Cabal is currently the only tool that can realistically be used to properly build and install Haskell packages due to the great complexity involved with getting all the details right I agree with much of what you said. I created this feature request for cabal, that I think would go quite aways towards addressing the problem, but someone marked it as wontfix: http://hackage.haskell.org/trac/hackage/ticket/815 In my opinion, the two most valuable things about cabal are its good dependency calculation and it allowed hackage to gain momentum. Unfortunately, we are also forced to use it as a build system and it's quite inadequate for that task. I say forced because there is no standard way to extract the dependency calculations from it. You have to write a Setup.hs file to extract it and it's not trivial. If you succeed at that task, then you can't even reuse the code without copypasting it later. In fact, I never invoke cabal-install directly anymore. I've corrupted my package databases too many times. I make sure to always use cabal-dev for everything. I think that says something about cabal's efficacy as a build system. Jason ps. As soon as I figure out a way to get infinite free time I'll implement the translation to makefiles myself... ___ 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] ANN: AERN-Real-Double-2011.1
Dear all, I am pleased to announce the first release of (a large part of) a newly designed AERN. AERN (approximating exact real numbers) is a set of Haskell libraries providing arbitrary precision interval arithmetic, polynomial arithmetic and distributed lazy exact real computation. Anyone is welcome to join in the development of AERN via http://code.google.com/p/aern/ . This release contains the following features: * Type classes for rounded arithmetic and rounded interval arithmetic with explicit control of rounding direction and the possibility to increase the rounding precision arbitrarily for types that support it. For example, type classes for types with rounded addition, multiplication, exponentiation etc. * Over 150 QuickCheck properties for these type classes, such as associativity of multiplication modulo rounding. * Interval arithmetic using Double endpoints, rounded outwards or inwards. Outwards rounding allows to safely approximate exact real arithmetic while a combination of both outwards and inwards rounding allows one to safely approximate exact interval arithmetic. Inverted intervals with Kaucher arithmetic are also supported. * For most of the type classes there are also in-place versions that act in the ST monad on mutable variables containing numbers or intervals. This facilitates some explicit memory allocation optimisation, especially for data on the C heap. The best starting point for experimenting with these features are the demo programs included in the bundle and the documentation for the AERN-Real-Double package: http://www-users.aston.ac.uk/~konecnym/aern/AERN-Real-Double (The HackageDB page does not have Haddock documentation because AERN fails to build with ghc 7.0.* due to a compiler bug.) The following features are planned for future releases: * Interval arithmetic with MPFR arbitrary precision endpoints. * Polynomial interval arithmetic with an optimised C core * Distributed exact real and geometric computation with lazy query-driven communication. For those familiar with the old AERN design, the main changes in the new design are: * use of many smaller type classes instead of few large ones * use of associated types instead of multi-parameter type classes * a much more systematic approach to representing the numerical order on real numbers and the information refinement (ie the inverse set inclusion) order on intervals * ability to specify different effort indicator types for each type of operation and each numerical type instead of Int. (For example, Double has () as its effort indicator for almost all operations while MPFR will have Precision as the effort indicator type.) * a more systematic approach to specifying QuickCheck properties and applying them to form test suites * a unified implementation of interval elementary operations (only sqrt and exp at the moment) that is efficient when applied to Double intervals as well as polynomial intervals * new support for in-place rounded numerical operations The current development team will be grateful for any feedback and suggestions. Best regards, Michal -- |o| Michal Konecny mikkone...@gmail.com |o|http://www-users.aston.ac.uk/~konecnym/ |o|office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston 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
Re: [Haskell-cafe] Using cmake with haskell
On Fri, May 13, 2011 at 7:47 AM, Yves Parès limestr...@gmail.com wrote: Talking about that, what are the differences between cabal-install and cabal-dev? Is cabal-dev (which I've never used nor installed) more suited for incremental development? Cabal-dev is a wrapper around caba-install that primarily adds sandboxing but also adds support for loading your project into ghci. The sandboxing makes it possible to install multiple versions without disrupting other things. It gives you isolation so that if cabal-install overwrites a package it only affects your current build dir. I've completely stopped getting the diamond of death in my dependencies since I started using it. Someone made a great write up of how to get started with cabal-dev: http://www.reddit.com/r/haskell/comments/f3ykj/psa_use_cabaldev_to_solve_dependency_problems/ It's actually very easy to get started with but extra documentation never hurts :) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] old versions of cabal install
If you search for cabal install, the first link is http://hackage.haskell.org/trac/hackage/wiki/CabalInstall, which in turn leads to http://haskell.org/cabal/download.html. It looks very official and canonical and all that, but that page has an old version of cabal install that will no longer compile with ghc7 because it requires old libraries. Of course it won't tell you that right off, first it will install a whole bunch of old stuff, charge you a fiver, and then emit some constraint can't be satisfied msgs which if you have some experience with haskell and cabal already should eventually tip you off that something's wrong. Is there someone out there who has permissions to either take that page down, or replace it with a link to the new version at http://hackage.haskell.org/package/cabal-install? I updated http://hackage.haskell.org/trac/hackage/wiki/CabalInstall to point to the platform and to the hackage page, but the cabal page at http://haskell.org/haskellwiki/Cabal-Install still links to http://haskell.org/cabal/download.html. Should I just replace the haskellwiki page with a link to the hackagewiki one? I would try to port over any up to date info of course. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using cmake with haskell
A little self-promotion, but I wrote this today: http://users.utu.fi/machra//posts/2011-05-13-environment.html A post about interfacing vim and cabal-dev. pgpE2vFrpuUPH.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Sending messages up-and-down the iteratee-enumerator chain [Was: iterIO-0.1]
At Fri, 13 May 2011 02:57:38 -0700 (PDT), o...@okmij.org wrote: The code described in this message does exactly that. Hey, Oleg. This is really cool! In particular, your Bindable class has the potential to unify a whole bunch of request types and both simplify and generalize code. Also, Sum is clearly a more elegant solution that just requiring everything to be Typeable. It may solve some problems I had where I wanted to send messages in exceptions that contained types I didn't know to be Typeable. I need to digest the code a bit more, but it may make sense for me to use this technique in a future version of iterIO. (Much of iterIO is obviously inspired by your stuff as it is.) However, I still have two questions. First, the Iter type in your message seems more like your first iteratee implementation, which is the approach iterIO and enumerator now take. I wonder if it's possible to implement something like Tell your current, CPS-based iteratee. Part of the reason I didn't take a CPS-based approach for Iter was that I couldn't get the upward control requests to work. (Also I wanted pure iteratees, which reduced the gain from CPS.) A challenge for Tell is that you need to know the size of buffered data and not move the input stream. So the control handler needs to decide what happens to residual data (since Seek does flush the input). Conceptually, it seems like it ought to be doable to pass residual data up and down the enumerator/iteratee stack in a CPS style. But when I try to represent residual input as something like: data Input r m s = forall a. Input ((Stream s - Iteratee s m a) - m r) I just can't get the types to work out. The second question is what happens to residual data for downstream requests. In the prototype code of your message, the Stream is over Chars, which are not a Monoid. In practice, you obviously want iteratees to be able to look arbitrarily far ahead--for instance an iteratee that returns a number of digits that is a multiple of 8 might have 8 characters of residual data (if the first 7 are digits). So what I'm stuck on is figuring out the right way to sequence the downstream requests with respect to the input data, particularly when you have enumeratees transcoding from one type to the other. Any thoughts? Thanks, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators
On 13 May 2011 19:06, Simon Marlow marlo...@gmail.com wrote: As far as memory consistency goes, we claim to provide sequential consistency for IORef and IOArray operations, but not for peeks and pokes. Hi Simon, Could you please point me to more information about the sequential consistency of IORefs? I was looking for something about this recently but couldn't find it. I don't see anything in the Haddock for Data.IORef. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exception for NaN
On Thu, May 12, 2011 at 5:50 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: Prelude Data.List maximum [0,-1,0/0,-5,-6,-3,0/0,-2] 0.0 Prelude Data.List minimum [0,-1,0/0,-5,-6,-3,0/0,-2] -2.0 Prelude Data.List sort [0,-1,0/0,-5,-6,-3,0/0,-2] [-6.0,-5.0,-2.0,NaN,-3.0,NaN,-1.0,0.0] Wow, that's the best example of NaN poison I've seen. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal-latest
On Thu, May 12, 2011 at 7:24 AM, Guy guytsalmave...@yahoo.com wrote: http://www.haskell.org/cabal/release/cabal-latest/ points to version 1.8.0.4. Is this correct? Replying to this on Haskell-Cafe and cabal-dev lists. The latest version is 1.10.x and ships with the HP. I bet that link is just needs to be updated. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exception for NaN
On Fri, May 13, 2011 at 4:48 PM, Luke Palmer lrpal...@gmail.com wrote: On Thu, May 12, 2011 at 5:50 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: Prelude Data.List maximum [0,-1,0/0,-5,-6,-3,0/0,-2] 0.0 Prelude Data.List minimum [0,-1,0/0,-5,-6,-3,0/0,-2] -2.0 Prelude Data.List sort [0,-1,0/0,-5,-6,-3,0/0,-2] [-6.0,-5.0,-2.0,NaN,-3.0,NaN,-1.0,0.0] Wow, that's the best example of NaN poison I've seen. Somewhat less impressive, but would everyone expect these functions to be equivalent up to performance characteristics? f :: (Eq a) = [a] - [a] f = nub . concatMap (replicate 5) g :: (Eq a) = [a] - [a] g = nub If the answer that springs to mind is yes, for any well-behaved instance of Eq, well... Bonus question: Should this function ever return False? h :: (Ord a) = a - a - Bool h x y = case compare x y of GT - x y EQ - x == y LT - x y - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Work on Collections Processing Arrows?
David Barbour dmbarb...@gmail.com writes: I wonder if I need something like your use of 'representation' types, i.e. to restrict what sort of elements can be stored in a collection. ... I'll admit to some reluctance, however, to clutter up several typeclasses with four more types. What are your thoughts regarding this issue? Yes, they certainly do clutter things up... but really, the whole representation business is in there mostly to show that the functor is identity-on-objects requirement of Freyd categories need not apply to generalized arrows. If you want to reduce the clutter, the simple trick I'm experimenting with now works like this: start with your multi-parameter class class GArrow g (**) u where ... Then, for all but the first type argument, create a type family indexed by the first type argument: type family GArrowTensor g :: * - * - * -- (**) type family GArrowUnit g :: * -- u And then use -XFlexibleContexts to declare a wrapper class with only one argument: class (GArrow g (GArrowTensor g) (GArrowUnit g), GArrowCopy g (GArrowTensor g) (GArrowUnit g), GArrowSwap g (GArrowTensor g) (GArrowUnit g), ... ) = GArrowWrappedUp g I'm sure you could do something similar with the type parameters c and r. The only price is that you can then have only one instance in scope at any given point in time. - a ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exception for NaN
You can set and clear float exception flags directly with ieee-utils: http://hackage.haskell.org/packages/archive/ieee-utils/0.4.0/doc/html/Numeric-IEEE-FloatExceptions.html It looks like it needs a few tweaks to build with GHC 7, but even then that particularly module should still build fine. So before a complicated numeric calculation, clear the flags. Then, after forcing the result, check to see if any flags have been triggered and take appropriate action. This is more efficient than checking the flags after every operation anyway. Cheers, Sterl. On May 12, 2011, at 1:14 PM, Grigory Sarnitskiy wrote: How do I make my program stop whenever it gets somewhere NaN as a result during a calculation? If there is no appropriate flag for ghc maybe there exist flags for C to use in optc. I don't want NaN to propagate, it is merely stupid, it should be terminated. ___ 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] Manatee-0.2.2 release!
Hi all, Manatee-0.2.2 release! New features in Manatee-0.2.2: * Build new package manatee-all, now you just need command cabal install manatee-all to upgrade new version. * Make keymap window and completion window will show correctly in Gnome3. * Fixed webkit-0.12.2 depend problem, because webkit-0.12.2 need some APIs just exist in gtk2hs darcs, so manatee-0.2.2 use webkit-0.12.1 * Fixed curl compile problem, at least curl-1.3.7, curl-1.3.6 have compile problem with GHC-0.7.3 Please let me know if you have problem about Manatee. :) Cheers, -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
