Re: [Haskell] Rank-N types with (.) composition
There is no special type for ($). The name is simply special cased in the
compiler. The rule is something like:
Whenever you see: f Prelude.$ x
instead try to type check: f x
That may not be the exact behavior, but it's close. To fix (.) (in a
similar fashion) you would have to have a similar rule, like:
Whenever you see: f Prelude.. g
instead try to type check: \x -> f (g x)
-- Dan
On Tue, Feb 10, 2015 at 6:19 PM, Tyson Whitehead
wrote:
> On February 10, 2015 16:28:56 Dan Doel wrote:
> > Impredicativity, with regard to type theories, generally refers to types
> > being able to quantify over the collection of types that they are then a
> > part of. So, the judgment:
> >
> > (forall (a :: *). a -> a) :: *
> >
> > is impredicative, because we have a type in * that quantifies over all
> > types in *, which includes itself. Impredicativity in general refers to
> > this sort of (mildly) self-referential definition.
>
> Thanks Dan and David,
>
> That was informative. Also very interesting that ($) is a special case.
> I tried this
>
> newtype Wrap = Wrap { extract :: forall f. Functor f => f Int }
>
> trip'' :: Wrap -> Wrap
> trip'' a = Wrap $ extract a
>
> and the compiler was happy. Wrapping ($) as ($') gave an error as you
> implied it would
>
> trip''' :: Wrap -> Wrap
> trip''' a = Wrap $' extract a
> where ($') = ($)
>
> With regard to my earlier comment about translating the (.) version
>
> trip' :: Wrap -> Wrap
> trip' = Wrap . extract
>
> to core, I can see it's actually okay. A most you may need is a lambda to
> float the implicit parameters backwards
>
> trip' :: Wrap -> Wrap
> trip' = Wrap . (\a f fDict -> extract f fDict a)
>
> as GHC seems to always float them as far leftward as possible
>
> extract :: Functor f => Wrap -> f Int
>
> I take it there are no user supplied types a person can give to overcome
> the predicative assumption?
>
> Out of curiosity, how would you write the special internal type that ($)
> has that separates it from ($') above?
>
> Thanks! -Tyson
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Rank-N types with (.) composition
Well, that might also be surprising, unless ($) is also magically made to work like a standard operator (just off the top of my head; there may be other confusing aspects). Really, I think the least ad-hoc solution (other than a hypothetical best-of-both-worlds inference algorithm) would be to allow code like: runST do ... where you can apply expressions directly to certain syntactic constructs without an operator in between. I suspect the majority of cases where 'runST $' is used are followed by a 'do,' and not having the remaining ones wouldn't be nearly as painful to use with parentheses (since they likely wouldn't be multi-line). And this extension is desirable for other reasons as well (though I can't recall any specifics off the top of my head). But I wouldn't hold your breath for that. On Tue, Feb 10, 2015 at 4:37 PM, David Feuer wrote: > On Tue, Feb 10, 2015 at 4:28 PM, Dan Doel wrote: > > > Also, I think ($) is the way it is specifically because 'runST $ ...' is > > considered useful and common enough to warrant an ad-hoc solution. There > > have been other ad-hoc solutions in the past, but redesigning inference > to > > not be ad-hoc about it would be very difficult at best. > > > > -- Dan > > Of the ad-hoc solutions available, I'd personally think the least > surprising would be to make f $ x special syntax instead of an > operator. The main tricky bit would be preserving source for error > messages; the type checker would have to keep track, for each > application, of whether it was a standard juxtaposition or whether it > used $. > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Rank-N types with (.) composition
Impredicativity, with regard to type theories, generally refers to types
being able to quantify over the collection of types that they are then a
part of. So, the judgment:
(forall (a :: *). a -> a) :: *
is impredicative, because we have a type in * that quantifies over all
types in *, which includes itself. Impredicativity in general refers to
this sort of (mildly) self-referential definition.
GHC will tell you that the above judgment is true, but things aren't that
simple. The type inference algorithm can either try to make use of such
impredicative instantiations, or act like everything is predicative. And
aspects of GHC's algorithm are either simplified or made possible at all
because of assumptions of predicativity.
Also, I think ($) is the way it is specifically because 'runST $ ...' is
considered useful and common enough to warrant an ad-hoc solution. There
have been other ad-hoc solutions in the past, but redesigning inference to
not be ad-hoc about it would be very difficult at best.
-- Dan
On Tue, Feb 10, 2015 at 3:51 PM, David Feuer wrote:
> The problem is that GHC's type system is (almost entirely)
> predicative. I couldn't tell you just what that means, but to a first
> approximation, it means that type variables cannot be instantiated to
> polymorphic types. You write
>
> trip = Wrap . extract
>
>
> which means
>
> (.) Wrap extract
>
> (.)::(b->c)->(a->b)->a->c
>
> Wrap :: (forall f. Functor f => f Int) -> Wrap
>
> The trouble here is that the type variable b in the type of (.) isn't
> allowed to be polymorphic, but Wrap's argument must be.
>
> Note that there's a weird exception: ($) actually has an impredicative
> type, because it's a special case in the type checker. This is largely
> for historical reasons.
>
> On Tue, Feb 10, 2015 at 3:38 PM, Tyson Whitehead
> wrote:
> > I came across something that seems a bit strange to me. Here is a
> simplified version (the original was trying to move from a lens ReifiedFold
> to a lens-action ReifiedMonadicFold)
> >
> > {-# LANGUAGE RankNTypes #-}
> >
> > import Control.Applicative
> >
> > newtype Wrap = Wrap { extract :: forall f. Functor f => f Int }
> >
> > trip :: Wrap -> Wrap
> > trip a = Wrap (extract a)
> >
> > The compiler is okay with this. It chokes on this alternative though
> >
> > trip :: Wrap -> Wrap
> > trip = Wrap . extract
> >
> > giving (GHC 7.8.2)
> >
> > Couldn't match type ‘f0 Int’
> >with ‘forall (f :: * -> *). Functor f => f Int’
> > Expected type: f0 Int -> Wrap
> >Actual type: (forall (f :: * -> *). Functor f => f Int) -> Wrap
> > In the first argument of ‘(.)’, namely ‘Wrap’
> > In the expression: Wrap . extract
> >
> > I'm guessing this is because the compiler fancy footwork to handle the
> implicit parameters, something like
> >
> > trip a = Wrap (\f fDict -> extract a f fDict)
> >
> > where f is the Functor type and fDict is the associated dictionary,
> isn't compatible with the (.) definition of
> >
> > f . g = \x -> f (g x)
> >
> > Is this correct? I would appreciate anyone insight here. Is there a
> way combine these (.) style?
> >
> > Thanks! -Tyson
> > ___
> > Haskell mailing list
> > Haskell@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: vector-algorithms 0.5.2
Greetings, Following some work at hac-phi, I've finally put together a new release of vector-algorithms. It should now be available via hackage, or you can pull from code.haskell.org if you prefer: hackage: http://hackage.haskell.org/package/vector-algorithms/ latest: darcs get http://code.haskell.org/~dolio/vector-algorithms/ The highlights of the new release are as follows: - Some bit rot in the test suite has been fixed - Some strictness has been added to the merge sort to improve unboxing on current GHCs - A couple out-of-bounds errors have been caught and fixed - An entirely new sort---American flag sort---has been added to the line-up * American flag sort is an in-place bucket sort, which only uses a constant amount of auxiliary heap space (determined by the element type). And unlike a typical radix sort, it is actually suitable for sorting arrays of variable-length (O(1) lookup) strings. To this end, there is a (strict) ByteString instance for the relevant class, and possibly more such instances to come. Bug reports, patches, requests, etc. can be sent to me at this address. Enjoy, -- Dan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: uvector-algorithms 0.2
Greetings, It is my pleasure to announce version 0.2 of the uvector-algorithms package. The package so far has implementations of several sorting and selection algorithms for use on the mutable arrays from the uvector library, as well as combinators for applying them to immutable arrays. New developments in this version include: - A simple benchmarking program for testing the performance of the algorithms (it's what I use to measure them, but I only have one computer to run it on, so perhaps other folks might want to see how it works on their machine) - A testing program, written with quick check to verify properties of the algorithms - Several bugs found and fixed due to the above tests and using HPC to verify good program coverage - Combinators for Schwartzian transform - Reworking radix sort to be more amenable to optimization. It's now around twice as fast. - A Radix instance for strict pairs, and a radix sortBy - Merge sort is now slightly faster due to memcpy in uvector :) The library can be found at hackage: http://hackage.haskell.org/package/uvector-algorithms or in its darcs repository: http://code.haskell.org/~dolio/uvector-algorithms/ As always, I can be notified of any issues. Enjoy. -- Dan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Definitions of purity and Lazy IO
On Thursday 05 March 2009 11:48:33 pm Jonathan Cast wrote: > > That is, for any program context C[] such that C[f1] is well-typed, > > the program C[f2] must too be well-typed, and if one can observe the > > result of C[f1] and of C[f2], the two observations must be identical. > > Every time? For every context? What about the context > > do > x <- getStdRandom random > y <- getStdRandom random > print $ [] x y > > ? By the standard above, f1 is not even observationally equivalent to > *itself*. One could theoretically dismiss this by saying that any particular IO context contains some random seed that determines the results of generating the random numbers. So, when you run the program and get different results, that's due to your actually running it in different contexts (with different seeds). However, it's possible to get this sort of non-determinism in other ways. For instance, consider the following fragment: do ctr <- newMVar 0 let inc = do i <- takeMVar ctr ; putMVar ctr (i+1) ; return i v1 <- newEmptyMVar v2 <- newEmptyMVar forkIO $ do inc >>= putMVar v1 forkIO $ do inc >>= putMVar v2 i1 <- takeMVar v1 i2 <- takeMVar v2 print $ i1 - i2 If forkIO provides real concurrency, this fragment should be capable of displaying either -1 or 1 (of course, everything happens too fast here, so I always end up getting -1, but I think the point is sound). So it's another context where (-) isn't equivalent to itself. So, to fix this up in the same way as the random example, you have to add something to the context that will supposedly completely determine the scheduling order of the threads in the program, so that when threads run in a different order, and you get a different result, you can say that you ran the program in a different context. But once we start doing that, how much more contrived is it to say that each context has some hidden state that determines how effects are interleaved with unsafeInterleaveIO such that we see the results we do (even though we know that isn't what's going on operationally; it isn't what's going on operationally with concurrency, either). The real issue is that lazy IO sometimes leads people to write buggier programs than they otherwise might. The same is true of, say, head and tail, but they are not impure by Sabry's definition, nor do they break referential transparency. They're 'impure' in that they're partial functions, but I'm not sure everyone's ready for Haskell to become a total language yet. :) Cheers, -- Dan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Lazy IO breaks purity
On Wednesday 04 March 2009 9:12:20 pm o...@okmij.org wrote:
> We demonstrate how lazy IO breaks referential transparency. A pure
> function of the type Int->Int->Int gives different integers depending
> on the order of evaluation of its arguments. Our Haskell98 code uses
> nothing but the standard input. We conclude that extolling the purity
> of Haskell and advertising lazy IO is inconsistent.
>
> Henning Thielemann wrote on Haskell-Cafe:
> > Say I have a chain of functions: read a file, ... write that to a file,
> > all of these functions are written in a lazy way, which is currently
> > considered good style
>
> Lazy IO should not be considered good style. One of the common
> definitions of purity is that pure expressions should evaluate to the
> same results regardless of evaluation order, or that equals can be
> substituted for equals. If an expression of the type Int evaluates to
> 1, we should be able to replace every occurrence of the expression with
> 1 without changing the results and other observables.
>
> The expression (read s) where s is the result of the (hGetContents h1)
> action has the pure type, e.g., Int. Yet its evaluation does more than
> just producing an integer: it may also close a file associated with
> the handle h1. Closing the file has an observable effect: the file
> descriptor, which is a scarce resource, is freed. Some OS lock the
> open file, or prevent operations such as renaming and deletion on the
> open file. A file system whose file is open cannot be
> unmounted. Suppose I use an Haskell application such as an editor to
> process data from a removable drive. I mount the drive, tell the
> application the file name. The (still running) application finished
> with the file and displayed the result. And yet I can't unplug the
> removable drive, because it turns out that the final result was
> produced without needing to read all the data from the file, and the
> file remains unclosed.
>
> Some people say: the programmer should have used seq. That is the
> admission of guilt! An expression (read s)::Int that evaluates to 1 is
> equal to 1. So, one should be able substitute (read s) with 1. If the
> result of evaluating 1 turns out not needed for the final outcome,
> then not evaluating (read s) should not affect the outcome. And yet it
> does. One uses seq to force evaluation of an expression even if the
> result may be unused. Thus the expression of a pure type
> has *side-effect*.
>
> The advice about using seq reminds me of advice given to C programmers
> that they should not free a malloc'ed pointer twice, dereference a
> zero pointer and write past the boundary of an array. If lazy IO is
> considered good style given the proper use of seq, then C should be
> considered safe given the proper use of pointers and arrays.
>
> Side affects like closing a file are observable in the external
> world. A program may observe these effects, in an IO monad. One can
> argue there are no guarantees at all about what happens in the IO
> monad. Can side-effects of lazy IO be observable in _pure_ Haskell
> code, in functions with pure type? Yes, they can. The examples are
> depressingly easy to write, once one realizes that reading does have
> side effects, POSIX provides for file descriptor aliasing, and sharing
> becomes observable with side effects. Here is a simple Haskell98 code.
>
> > {- Haskell98! -}
> >
> > module Main where
> >
> > import System.IO
> > import System.Posix.IO (fdToHandle, stdInput)
> >
> > -- f1 and f2 are both pure functions, with the pure type.
> > -- Both compute the result of the subtraction e1 - e2.
> > -- The only difference between them is the sequence of
> > -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1
> > -- For really pure functions, that difference should not be observable
> >
> > f1, f2:: Int -> Int -> Int
> >
> > f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2
> > f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2
> >
> > read_int s = read . head . words $ s
> >
> > main = do
> >let h1 = stdin
> >h2 <- fdToHandle stdInput
> >s1 <- hGetContents h1
> >s2 <- hGetContents h2
> >print $ f1 (read_int s1) (read_int s2)
> >-- print $ f2 (read_int s1) (read_int s2)
>
> One can compile it with GHC (I used 6.8.2, with and without -O2) and
> run like this
>~> /tmp/a.out
>1
>2
>-1
> That is, we run the program and type 1 and 2 as the inputs. The
> program prints out the result, -1. If we comment out the line
> "print $ f1 (read_int s1) (read_int s2)" and uncomment out the last
> line the transcript looks like this
>~> /tmp/a.out
>1
>2
>1
>
> Running the code with Hugs exhibits the same behavior. Thus a pure
> function (-) of the pure type gives different results depending on the
> order of evaluating its arguments.
>
> Is 1 = -1?
This does not conclusively demonstrate a violation of referential
transparency. One can still consign the impurity to the IO monad. One just
needs to speci
[Haskell] ANNOUNCE: uvector-algorithms 0.1
Hello, I've been sitting on this for a while, waiting for some changes to uvector to go in, but finally decided I should just release it, and fix it up if and when said changes go in. So, I'm announcing the first release of uvector- algorithms. What it is is a library of algorithms (mostly sorting) for the mutable arrays defined in uvector. It has several varieties of sorting, including introsort (quicksort which falls back on heapsort in bad cases), heapsort, a simple top- down merge sort and a radix sort (as well as insertion sort, and optimal sorting for length<=4 arrays, which probably won't get much use outside of the implementation of the other sorts). All modules attempt to export as uniform an interface as possible, so that one can substitute between them freely, say when trying to determine which algorithm is best suited for your particular datasets. Also exposed are the operations that allow you to use the arrays as heaps (which is the basis for implementing heapsort), and partial sorts and selects in heap and intro variety. Lastly, there is a combinator for safely using these mutable array algorithms to sort immutable arrays. All of these algorithms have been painstakingly profiled, and their generated core examined to do as little heap allocation and as much unboxing as possible, and to inline and specialize for maximum performance (unless, of course, I've managed to miss anything). I've been running a relatively simple benchmarking suite that tests various kinds of inputs, and in my experience, the sorts herein tend to beat glibc's sort, and do relatively well compared to GNU's STL sorts over vector<>s (taking 50% or so more time at present, although this library may well be better at heapsorting random arrays, if you want something to brag about :)). For future work, I've been working on an implementation of Python's timsort (which is a very fancy bottom-up merge sort), but it's not ready yet. I'd also like to introduce some combinators for easy Schwartzian transforms, but that again requires modifications to uvector. I may also look at moving some of my benchmark program into the package. Suggestions for other algorithms people would like to see are of course welcome (especially if accompanied by papers/references on how to implement them if they're not well known). The hackage page is here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector-algorithms Enjoy, and please let me know of any issues. -- Dan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: category-extras 0.2
Hello, all. After quite a bit of collaboration with Edward Kmett over the past few days, I've rolled up a new release of category-extras. Perhaps the most significant addition is the generalized hylomorphism he first blogged about here: http://comonad.com/reader/2008/generalized-hylomorphisms/ added to Control.Recursion under the name 'refoldWith', as all other combinators in the library turn out to be special cases of it. Other changes include: * Data.BranchingStream moves to Control.Comonad.Cofree, and various functions are renamed accordingly, as it is the cofree comonad of a functor: Cofree F A = nu X. A * FX * Similarly, a new module has been added: Control.Monad.Free, the free monad of a functor. Free F A = mu X. A + FX * Several new recursion combinators have been added to Control.Recursion. The generalized hylomorphism 'refoldWith' was mentioned above, but we now also have: - Futumorphisms (futu, g_futu) - Chronomorphisms (chrono, g_chrono; name coined by edwardk; they're a combination of a histomorphism and a futumorphism). - Dynamorphisms (dyna, g_dyna; formalize dynamic programming) - Codynamorphisms (codyna, g_codyna; these apparently don't appear in any literature (like chronomorphisms), and we didn't attempt to give them a name, but once one sees dynamorphisms in terms of chronomorphisms/ g_hylomorphisms, this becomes fairly obvious). As can be seen, there's quite a glut of these combinators, and they all correspond to choices of distributive laws for refoldWith, so in the future, it may be better to talk about those directly. For now, though, we have lots of functions with fancy-sounding names. I believe those are the significant updates for this release. Enjoy. hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/category-extras-0.2 darcs: darcs get http://code.haskell.org/~dolio/category-extras/ -- Dan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Announce: category-extras 0.1
Hello everyone, While fooling about with generalized tries a night or two ago, I found myself once again interacting with fixed points of shape functors and the like, and so decided it was time to finish cabalizing David Menendez' excellent category theory inspired modules.[1] So, it is my pleasure to announce version 0.1 of category-extras. This is an initial import of the code, with only what work it took to get things compiling properly. As such, some of the documentation is a bit scanty, and there is some overlap with other packages (notably, TypeCompose, off the top of my head), but I hope to rectify that later. Notable bits include: * Control.Comonad * Control.Comonad.Context -- the state-in-context monad * Control.Functor.Adjunction -- a class for adjoint functors, and their associated (co)monads * Control.Recursion -- Various generalized recursion operators (cata/zygo/histo/apomorphisms) -- A class for associating fixpoint data types to their shape functors Also included are some Data.* modules with some comonadic data types (infinite trees and streams, for instance), but they are in the as-yet-poorly-documented section of the package. Haddock 2.0 is required to build what documentation there is for Control.Functor.Transform, as it uses type operators. However, the rest should be compatible with earlier versions of haddock. Some modules are portable Haskell98, but many use various extensions (rank-2 types and functional dependencies being the most common). Links: * hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/category-extras-0.1 * darcs: http://code.haskell.org/~dolio/category-extras/ If you identify any issues with the package, or simply have some wild category theoretic abstractions that you think should be made available to Haskell programmers at large, feel free let me know. -- Dan Doel [1] The original home of these modules is here: http://www.eyrie.org/~zednenem/2004/hsce/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Announce: CC-delcont 0.2
Hello all, After much distraction and laziness on my part (my apologies), I have finally gotten around to putting together a new release of the delimited continuations library CC-delcont. It is now available on hackage. Relevant changes include: * Now builds in GHC-6.8.x * Builds with -Wall (and the code was cleaned up to make as little noise as possible) (Thanks to gwern for the above) Also included is a new module, Control.Monad.CC.Cursor, which provides some functions for reifying traversals into cursors that can be passed around and manipulated. It's still in its infancy, but I hope to eventually include generalized zippers and such. GHC 6.8 or greater is required to build, and haddock 2.0 or greater is required to generate the documentation. Links: * hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CC-delcont-0.2 * darcs: http://code.haskell.org/~dolio/CC-delcont/ * a brief tutorial: http://haskell.org/haskellwiki/Library/CC-delcont (I've not had too much feedback on this, so if anyone has trouble following some sections, or has ideas on how to better explain delimited continuations, changes are welcome.) Once again, if you discover any bugs, or have any suggestions, don't hesitate to let me know. -- Dan Doel ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Functor ((,) a)
On Wednesday 19 September 2007, Janis Voigtlaender wrote: > Hi, > > the Prelude docs found via > > http://haskell.org/hoogle/hoodoc.cgi?module=Prelude&name=Functor&mode=class > > claim that there is an instance > > Functor ((,) a) > > And yet, I get (in GHC, but similarly in Hugs): > > Prelude> fmap (+1) (undefined,2) > > :1:0: > No instance for (Functor ((,) a)) >arising from use of `fmap' at :1:0-22 > Possible fix: add an instance declaration for (Functor ((,) a)) > In the expression: fmap ((+ 1)) (undefined, 2) > In the definition of `it': it = fmap ((+ 1)) (undefined, 2) > > What do I have to import to get the Functor ((,) a) instance? > > (Of course, I can define it myself, but this is not the point.) In GHC 6.6 and above, you'll need to import Control.Monad.Instances (a bit of a weird place to put it, but I guess there's no Control.Functor and such). If you have an earlier version than that, I'd say import Control.Monad.Writer at a guess. -- Dan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: CC-delcont-0.1; Delimited continuations for Haskell
n't be able to restart as closely to an error as one that, say, saved after each input but resumed when legitimately bad input automatically kicked the parser to Done. Whether this is enough motivation to push monads further into one's data structures, or drop Haskell and go with implicitly monadic code everywhere in OCaml is left as an exercise to the reader. :) Anyhow, I hope I've demonstrated something of interest, and given you a taste of what you can do with this library, and how to do it. There is some more explanation and some elementary examples in the haddock, although due to the code's use of some exotic GHC-isms, haddock.ghc, at the least, will be needed to generate the documentation, and I have yet to get that fully working here, so there may still be bugs in the haddock. Cheers, Dan Doel ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: CC-delcont-0.1; Delimited continuations for Haskell
Hello, After a bit of hacking, and much documenting, I'm pleased to announce a preliminary release of a delimited continuation library for Haskell. The implementation is drawn from "A Monadic Framework for Delimited Continuations"[1] by Dybvig, Petyon Jones and Sabry, although it has some abstraction available over said implementation (there is both a monad and a transformer; control operations will work interchangeably with either. In addition, all four control operators from "Shift to Control"[2] are implemented). In addition, I have done the adaptation necessary to include the Haskell implementation of the dynamic scoping investigated in "Delimited Dynamic Binding"[3] by Kiselyov, Shan and Sabry, and it has been included. One can think of it as embeddings of the reader or state monads into the delimited control monads (only more flexible). In the future, I'd like to also, possibly, include something like Oleg's generic zippers, and possibly other useful abstractions based on delimited continuations, if I find them. But that's work for another day, I suppose. If you wish to try it out, a package is available on hackage: Page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CC-delcont-0.1 Tabrall: http://hackage.haskell.org/packages/archive/CC-delcont/0.1/CC-delcont-0.1.tar.gz However, I should warn that it's fairly dependent on GHC HEAD at the moment: 1) It uses the Unsafe.Coerce module 2) It uses GADTs to store type class evidence 3) It uses GHC-features that haddock will choke on, so haddock.ghc will be required for docs (and I haven't gotten that working yet to check that the haddock is bug-free), which in turn requires GHC HEAD. 1 & 2 could be relaxed if there's interest. Please feel free to let me know if you find any bugs, or have any suggestions for improvements. I'll follow up this message with a message containing an example program and a discussion thereof. Cheers, Dan Doel 1: http://www.cs.indiana.edu/~sabry/papers/monadicDC.pdf 2: http://www.cs.rutgers.edu/~ccshan/recur/recur.pdf 3: http://okmij.org/ftp/papers/DDBinding.pdf ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: logict-0.2
Hello all, I've just completed a library adapting the logic programming monad from the "Backtracking, Interleaving, and Terminating Monad Transformers" paper[1] into a format typical of the hierarchical libraries (based on MTL). It uses the two-continuation passing implementation described therein. Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logict-0.2 Tarball: http://hackage.haskell.org/packages/archive/logict/0.2/logict-0.2.tar.gz Feel free to let me know if your find any bugs, or have suggestions. Dan Doel [1]: http://okmij.org/ftp/papers/LogicT.pdf ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
