Re: Arrow Development
On Fri, Feb 20, 2015 at 02:58:14AM -0500, Thomas Bereknyei wrote:
I am looking at the proc notation de-sugar and I see results like this when
using a Free Arrow (mostly copied from [1]):
line2 = proc n - do
Effect getURLSum *** Effect getURLSum - n
Seq [Pure ] (Seq [Pure ] (Seq [Pure ] (Seq [Pure ](Par Effect {Effect } )
) ) )
while this is so much simpler:
line2 = Effect getURLSum *** Effect getURLSum
Par Effect {Effect }
Those `Seq [Pure ]` sequences come from application of (.) and I have noticed
many similar inefficiencies in the Arrow preprocessor. Eventually the goal
would be to optimize when possible, for example I started looking into this in
order to use `concurrently` for (***) when in IO.
There was a rewrite mentioned here [2]. The deSugar/DsArrows.hs [3] looks
convoluted. Any progress or work needed? Or are Arrows not used much and not
worth the effort?
I don't think it's feasible to try to do optimization in the desugarer,
which certainly is convoluted. You might have more luck using RULES to
simplify the output.
(The desugarer could be simplified -- a lot of what it does probably belongs
in the renamer -- but I'm not sure that would help with optimization.)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Redundant constraints
On Wed, Jan 07, 2015 at 03:19:15PM +, Simon Peyton Jones wrote: I’ve pushed a big patch that adds –fwarn-redundant-constraints (on by default). It tells you when a constraint in a signature is unnecessary, e.g. f :: Ord a = a - a - Bool f x y = True I think I have done all the necessary library updates etc, so everything should build fine. Four libraries which we don’t maintain have such warnings (MANY of them in transformers) so I’m ccing the maintainers: I've fixed some of the warnings in transformers, but there are still 14 of them, triggered by Applicative becoming a superclass of Monad. I can't get rid of those because the package has to build with old GHCs when bootstrapping the compiler. On Wed, Jan 07, 2015 at 04:27:21PM +0100, Johan Tibell wrote: I had one thought though: consider an abstract data type with functions that operates over it. I might want to require e.g Ord in the definition of a function so I have freedom to change my implementation later, even though the current implementation doesn't need Ord. Think of it as separating specification and implementation. I think some of the changes already made are of this sort, exposing details of the GHC implementation, e.g. the changes to the public interface of Array and Ratio. For example, it's probably reasonable to remove the Ix constraint from Data.Array.bounds, but the portable reference implementation of Data.Array.elems requires Ix, even though the GHC implementation doesn't. Similarly a portable implementation of the Functor instance for Array i requires Ix, but the GHC implementation doesn't. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deep embeddings and Arrows Re: Uniquable RdrName instance
On Tue, Jun 17, 2014 at 03:10:14PM -0400, Carter Schonwald wrote: to clarify: having bind would be equivalent to having arr for the purposes of my question (assuming its the standard monadic bind). having arr :: (b - c) - a b c is tantamount to assuming that any haskell function can be embedded in an arrow instance which prevents a lot of interesting deep embedding uses of the Arrow abstraction/ or at least makes it a bit tricker. (eg things like writing circuits or certain types of compiled FRP models). I have two answers: First, it's not that difficult using the Arrow class. For example, see the netlist example at the end of my Fun of Programming slides (http://www.soi.city.ac.uk/~ross/papers/fop.html). The idea is that arr can take any function, but if you require the circuit to be parametric in the value types, you can limit the types of function the programmer can pass to arr to simple plumbing. Second, suppose we split arr :: forall b c. (b - c) - a b c into two primitives (^) :: forall b c d. (b - c) - a c d - a b d id :: forall b. a b b Arrow notation relies on (^) being a contravariant functor -- that's what allows the translation to manipulate environments, and it gives you a substitution property for commands. On the other hand it doesn't need id (or equivalently returnA). Perhaps the problem is the universally quantified b in the type of id. One might instead use a variant of id constrained to an ADT with just the operations you want. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Arrow notation vs RebindableSyntax
On Thu, Mar 13, 2014 at 04:36:54PM -0500, Nicolas Frisby wrote: The 7.8-rc2 User Guide for rebindable syntax includes: Arrow notation (see Section 7.16, Arrow notation) uses whatever arr, (), first, app, (|||) and loop functions are in scope. But unlike the other constructs, the types of these functions must match the Prelude types very closely. Details are in flux; if you want to use this, ask! I want to use this: my types for the functions apparently do not match the Prelude types closely enough. Whom should I ask about this? Daniel Winograd-Cort was looking at this, but I haven't heard anything for a while. My own view is that rebinding should be done at the control operator level rather than the level of arrow combinators. But what are the types of your functions? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: packages/base] master: Add fmapCoerce to Functor class. (3da4fd9)
On Wed, Sep 25, 2013 at 10:18:51PM +0200, Joachim Breitner wrote: given the recently intensified urge to make GHC a more community driven project, may I suggest to reduce the amount of off-list discussions? I find it very confusing if some discussions happen on list, some discussion on list with certain people explictily CC’ed, and some discusisons off-list, and some alternating between these. I believe we are all able to ignore discussions on the list that are not relevant for us, but on-list discussions are easily referenced and re-read later. I agree with all that, and also share Johan's alarm at the sudden appearance of coerce in this class. On the substance, I don't think Functor is the right place for this, as it's about lifting isomorphisms rather than functions, and type constructors don't have to be functors to support that. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH 1/2] System.IO.Unsafe: fix doc typo: 'System.IO.IO' to 'System.IO'
On Wed, Sep 18, 2013 at 04:22:47PM +0300, Roman Cheplyaka wrote: This may be not a typo, but rather a reference to the IO type from the System.IO module. Yes, if the module were intended it would be in double quotes. This change will break the link intended for the 'IO' monad. * sly...@gmail.com sly...@gmail.com [2013-09-18 16:07:03+0300] From: Sergei Trofimovich sly...@gentoo.org - -- * Unsafe 'System.IO.IO' operations + -- * Unsafe 'System.IO' operations ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: FW: [commit: ghc] tc-arrows: Rearrange the typechecking of arrows, especially arrow forms (49badc9)
On Thu, Feb 14, 2013 at 05:40:51PM +, Simon Peyton-Jones wrote: I've pushed a new branch, tc-arrows, for the new typechecking of arrows, based on the discussion we had last week. It all compiles, but won't work because I have done nothing to the desugaring. It uses our new representation with (env, nested-tuple-with-unit-at-end) rather than (nested-tuple-with-env-at-the-end), so desugaring needs significant attention. I think it's done. All but 4 of the tests pass: - I have new versions of arrowform1 and T5283 that pass. - The type error message for T5380 has changed. - The gimmick used by arrowapply4 is incompatible with the new representation, so this test should be dropped. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
