September 2010 - Haskell-prime

Propsal: NoDatatypeContexts
by Ian Lynagh 21 Oct '10

21 Oct '10

Hi all, H98 and H2010 allow a context to be given for datatypes, e.g. the "Eq a" in data Eq a => Foo a = Constr a I have made a proposal to remove support for that context (ticket #139). More details are on the proposal wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts Thanks Ian

11 13

new keyword: infixlr?
by S. Doaitse Swierstra 19 Sep '10

19 Sep '10

Currently Haskell has infix, infixl and infixr operators. I see a use for infixlr as well. This indicates that the implemtation may assume the operator to be associative, and thus has the freedom to "balance" an expression containing several operator occurrences. The reason that I bring up this is that in a new combinator I have added to my parser library (the <||> in Text.ParserCombinators.UU.Derived) internally uses cartesian products, which are being constructed and updated. If the compiler had the right to interpret the expressions a <||> b <||>c <||> d as e.g. (a <||> b) <||> (c <||> d) then the updating time for would go down from O(n) to O(log n). I admit it is probably a minor point, but given the increased use of "type level" programming, and the use of cartesian products to keep "lists of values of a different type", I can also see many good uses for this. Any comments? Doaitse

9 10

Re: [Haskell-cafe] Reachable variables exercise
by Carlos Camarao 17 Sep '10

17 Sep '10

Ah... now I understand your concern; I should have written something like: where K +_t K' denotes the set of constraints from K plus those from K' that have type variables reachable from t. instead of: where K +_t K' denotes the constraint-set obtained by adding from K' only constraints with type variables reachable from t. Cheers, Carlos On Thu, Sep 16, 2010 at 6:56 PM, Luke Palmer <lrpalmer(a)gmail.com> wrote: > I am not totally sure if I understand your proposal correctly, but if > I do, then it has a flaw. Consider: > > class Boolable a where > boolify :: a -> Bool > > class O a where > o :: a > > main = print $ boolify o > > It seems like under your proposal this should not be a type error. > But if that is so, then what is its output? > > Luke > > On Thu, Sep 16, 2010 at 7:31 AM, Carlos Camarao > <carlos.camarao(a)gmail.com> wrote: > > Hi. Consider for example an expression e0 like: > > > > fst (True,e) > > > > where e is any expression. > > > > e0 should have type Bool IMHO irrespectively of the type of e. In Haskell > > this is the case if e's type is monomorphic, or polymorphic, or > > constrained and there is a default in the current module that removes > > the constraints. However, e0 is not type-correct if e has a > > constrained type and the constraints are not subject to > > defaulting. For example: > > > > class O a where o::a > > main = print $ fst(True,o) > > > > generates a type error; in GHC: > > > > Ambiguous type variable `a' in the constraint: > > `O a' arising from a use of `o' at ... > > Probable fix: add a type signature that fixes these type variable(s) > > > > A solution (that avoids type signatures) can be given as follows. > > > > The type of f e, for f of type, say, K=>t'->t and e of type K'=> t' > > should be: > > > > K +_t K' => t (not K U K' => t) > > > > where K +_t K' denotes the constraint-set obtained by adding from K' > > only constraints with type variables reachable from t. > > > > (A type variable is reachable if it appears in the same constraint as > > either a type variable free in the type, or another reachable type > > variable.) > > > > Comments? Does that need and deserve a proposal? > > > > Cheers, > > > > Carlos > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > >

1 0

Fwd: [Haskell-cafe] Reachable variables exercise
by Carlos Camarao 17 Sep '10

17 Sep '10

---------- Forwarded message ---------- From: Carlos Camarao <carlos.camarao(a)gmail.com> Date: Fri, Sep 17, 2010 at 12:01 AM Subject: Re: [Haskell-cafe] Reachable variables exercise To: Luke Palmer <lrpalmer(a)gmail.com> boolify o has type Boolable a => Bool under the proposal, then we have ambiguity, type error, right? In general, consider 'e' as (g:: K=>a -> t) (o:: O a=>a); then the type of 'e' has constraint (O a) iff 'a' occurs in t. Let's think about how could 'a' not occur in t. That happens if 'o' is not needed for computing the result; well, or, as in your example, 'g' is overloaded and requires the argument to resolve the overloading ('a' occurs in K and does not occur in t), in which case K=>t is ambiguous. Cheers, Carlos On Thu, Sep 16, 2010 at 6:56 PM, Luke Palmer <lrpalmer(a)gmail.com> wrote: > I am not totally sure if I understand your proposal correctly, but if > I do, then it has a flaw. Consider: > > class Boolable a where > boolify :: a -> Bool > > class O a where > o :: a > > main = print $ boolify o > > It seems like under your proposal this should not be a type error. > But if that is so, then what is its output? > > Luke > > On Thu, Sep 16, 2010 at 7:31 AM, Carlos Camarao > <carlos.camarao(a)gmail.com> wrote: > > Hi. Consider for example an expression e0 like: > > > > fst (True,e) > > > > where e is any expression. > > > > e0 should have type Bool IMHO irrespectively of the type of e. In Haskell > > this is the case if e's type is monomorphic, or polymorphic, or > > constrained and there is a default in the current module that removes > > the constraints. However, e0 is not type-correct if e has a > > constrained type and the constraints are not subject to > > defaulting. For example: > > > > class O a where o::a > > main = print $ fst(True,o) > > > > generates a type error; in GHC: > > > > Ambiguous type variable `a' in the constraint: > > `O a' arising from a use of `o' at ... > > Probable fix: add a type signature that fixes these type variable(s) > > > > A solution (that avoids type signatures) can be given as follows. > > > > The type of f e, for f of type, say, K=>t'->t and e of type K'=> t' > > should be: > > > > K +_t K' => t (not K U K' => t) > > > > where K +_t K' denotes the constraint-set obtained by adding from K' > > only constraints with type variables reachable from t. > > > > (A type variable is reachable if it appears in the same constraint as > > either a type variable free in the type, or another reachable type > > variable.) > > > > Comments? Does that need and deserve a proposal? > > > > Cheers, > > > > Carlos > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > >

1 0

Reachable variables exercise
by Carlos Camarao 16 Sep '10

16 Sep '10

Hi. Consider for example an expression e0 like: fst (True,e) where e is any expression. e0 should have type Bool IMHO irrespectively of the type of e. In Haskell this is the case if e's type is monomorphic, or polymorphic, or constrained and there is a default in the current module that removes the constraints. However, e0 is not type-correct if e has a constrained type and the constraints are not subject to defaulting. For example: class O a where o::a main = print $ fst(True,o) generates a type error; in GHC: Ambiguous type variable `a' in the constraint: `O a' arising from a use of `o' at ... Probable fix: add a type signature that fixes these type variable(s) A solution (that avoids type signatures) can be given as follows. The type of f e, for f of type, say, K=>t'->t and e of type K'=> t' should be: K +_t K' => t (not K U K' => t) where K +_t K' denotes the constraint-set obtained by adding from K' only constraints with type variables reachable from t. (A type variable is reachable if it appears in the same constraint as either a type variable free in the type, or another reachable type variable.) Comments? Does that need and deserve a proposal? Cheers, Carlos

1 0

Re: new keyword: infixlr?
by Ian Lynagh 12 Sep '10

12 Sep '10

On Fri, Sep 10, 2010 at 11:14:53PM +0200, S. Doaitse Swierstra wrote: > > On 10 sep 2010, at 20:13, Ian Lynagh wrote: > > > On Fri, Sep 10, 2010 at 07:51:10PM +0200, S. Doaitse Swierstra wrote: > >> > >> Currently Haskell has infix, infixl and infixr operators. I see a use for infixlr as well. This indicates that the implemtation may assume the operator to be associative, and thus has the freedom to "balance" an expression containing several operator occurrences. > > > > Would it be restricted to use with operators with types that are (a -> a > > -> a) (or more specific)? > > This is what I would normally expect from an infix operator. I assume you mean "an associative operator", but even then it's not true for (.). And just because it is what you would expect, does not mean that people will only use it in that way if the type system does not enforce it! A detail is whether x ^^^ y = x ^ y infixlr ^^^ is rejected, or gives (^^^) :: (Num a, Integral a) => a -> a -> a Although I guess if you require the compiler to give you the balanced parse, there's no technical need to restrict the type of the operator as it's deterministic. Overall, my feeling is that this syntax feels very specialised and fiddly, and would be better handled by a more general machanism similar to GHC's RULE pragma, or by quasi-quotes or TH, or even by a domain specific optimiser plugin which can see the result of inlining etc. Thanks Ian

1 0