- Haskell-prime - Haskell.org

new extension in jhc: explicit namespaces in import/export lists
by John Meacham 13 Feb '12

13 Feb '12

Hi, I implemented an extension in jhc that I thought the community might have feedback on and feel that a variant of it would be a candidate for future standardization. Here is the section from the jhc manual describing it. The 'kind' information is specific to jhc, and with this extension I'd really like to get rid of the wart in haskell 98 that names in 'hiding' lists are treated differently than names otherwise. I will likely make that change in jhc in the future once I work out the details of the best way to be backwards compatible. I have seen this exact proposal more-or-less come up on the lists periodically, so I guess I am just pointing to a concrete implementation now. # Explicit namespaces in import/export lists jhc allows explicit namespaces in import export lists. In haskell 98, a name such as 'Foo' in an export list will indicate that all of a class named Foo, a type named 'Foo' and a data constructor named 'Foo' shoud be exported. Jhc allows finer grained control by prefixing exports with a namespace indicator. The valid namespace indicators are * 'type' - The name is a type, as in something defined by type , newtype , or data , or the constructors of a kind declaration. * 'class' - Specifies that the name is that of a class. * 'data' - Specifies that the name is a data constructor. * 'kind' - specifies that the name is a user defined kind. In addition, classes and types are in independent namespaces, so a type and a class of the same name may be in scope and not conflict. When an unqualified name is given in a import/export list then all names that match it that are in scope are matched. The only exception is a holdover from haskell 98 where in hiding lists data constructors are not matched. This behavior may change in the future when explicit namespaces are used, so it should not be relied upon when using explicit namespaces. John

2 2

Proposal: require spaces around the dot operator
by Greg Weber 12 Feb '12

12 Feb '12

Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the usage of the unspaced dot as a record field selector as shown in proposal #129. After this proposal shows clear signs of moving forward I will add a proposal to support a unicode dot for function composition. After that we can all have a lively discussion about how to fully replace the ascii dot with an ascii alternative such as <~ or <<< After that we can make the dot operator illegal by default. This has already been discussed as part of a records solution on the ghc-users mail list and documented here: http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator

13 23

Re: Proposal: require spaces around the dot operator
by Anthony Clayden 10 Feb '12

10 Feb '12

> ... I'm struggling to see why people > are fighting so hard to get the dot character in > particular for field access. It seems like a huge amount > of work and discussion for a tiny bit of syntactic > convenience that we've only come to expect because of > exposure to other very different languages. Dan/all, I think yous should backtrack to SPJ's SORF and TDNR proposals, and the Yesod/Reddit discussion that triggered the latest 'Records in Haskell' threads. http://hackage.haskell.org/trac/ghc/wiki/Records SORF: "It is critical to support dot-notation." TDNR: "Exploting the power of the dot" TDNR: "a feature that has a _cultural_ connection to OO, but that turns out to be fully compatible with a functional language." TDNR: "I have deliberately used dot ..." "It's standard practice, and that counts for a lot." "Selecting a field from a record is a particularly convenient special case, ..." "... is doing the same job as Haskell's existing qualified names, ..." I guess the 'clincher' for me is that if we're going to ask SPJ to implement anything (and there's no-one else who's capable) we'd better have very powerful reasons to go against his so clearly expressed views. Remember GHC/Haskell Prime is not run as a democracy, it's a benevolent meritocracy. We've probaly only got one shot: if we don't include dot notation with whatever happens for 'Records in Haskell', we'll probably never get dot notation. SPJ has made it clear Records is not a priority. If it contues to be an area for hot dispute, it'll just die a death (again). I do, however, agree with you questioning the effort going into surface syntax vs. deep semantics. (The relative effort is confirming Wadler's rule.) Because what's not getting enough 'airtime' is how we address even the "narrow issue: namespacing for record field names." What we are tending to get (apart from the hatchet-job on the dot) is another bundle of half-baked suggestions for the impossibily difficult "broad issue: first class record types". I'm working towards a proposal for the narrow issue. I'm trying to make the changes to Haskell as minimal as possible. So far, I've built a prototype in GHC v 7.2.1 (with many record-oriented extensions), which gives me hope I'm mostly asking for syntactic sugar. It's been somewhat helpful with the design to 'test the water' through the discussion lists. It's also been distracting. I've only had one response that was really, really helpful and on-topic -- and that was from SPJ, who (heck knows) is a very busy person. I don't want the response to my proposal (if/when I get time to write it up convincingly) to focus on the dot. Luckily, under my design, the dot is very much syntactic sugar. (So actually, it would be absurdly simple to implement, and even simpler to leave out. That is, simple compared to implementing the semantics.) I don't need it. I'm in two minds whether even to mention it. AntC

1 0

left and right sections extended
by Christian Maeder 01 Oct '11

01 Oct '11

Hi, the following sections are currently legal in Haskell: (a + b +) and (++ a ++ b) because + is left and ++ is right associative. I would like to write (+ 1 +) and (++ " " ++) as legal generalized sections, too, to stay for (\ a -> (a + 1 +)) and (\ a b -> a ++ " " ++ b) respectively. The right-associative case would be "flip (\ b -> (++ " " ++ b))" Such an extension would be easy to implement and it would also be a generalization of putting parenthesis around symbols as in (+) or (++). Extending the grammar is easy: aexp -> ... | ( infixexp qop ) (left section) | ( qop⟨-⟩ infixexp ) (right section) Some thoughts are needed to exclude the illegal cases (as done for left and right sections). Is this worth a formal proposal or is this too confusing? Cheers Christian

2 1

Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
by Cale Gibbard 28 Sep '11

28 Sep '11

I just tried this in ghci-7.0.3: ghci> nubBy (>=) [1,2,3,4] [1] Think about what this is doing: it is excluding 2 from the list because 2 >= 1, rather than including it because 1 >= 2 fails. I think an important convention when it comes to higher order functions on lists is that to the extent which is possible, the function parameters take elements from the list (or things computed from those) in the order in which they occur in the original list. If we reimplement it in the obvious way: ghci> let nubBy f [] = []; nubBy f (x:xs) = x : filter (not . f x) (nubBy f xs) ghci> nubBy (>=) [1,2,3,4] [1,2,3,4] I'm aware that the Report (strangely!) explicitly leaves the behaviour of nubBy unspecified for functions which are not equivalence relations, but the behaviour given by the Report implementation (the opposite of the current behaviour in GHC) is useful and desirable nonetheless. I'm sure I've written about this before. I'm not entirely sure what happened to the previous thread of discussion about this, but it just came up again for me, and I decided that I was sufficiently irritated by it to post again. Another thing perhaps worth pointing out is that the parameters to mapAccumR have always been backwards (compare it with foldr). Few enough people use this function that I'm fairly sure we could just change it without harm. - Cale

5 8

Re: Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
by Christian Maeder 21 Sep '11

21 Sep '11

Am 20.09.2011 20:21, schrieb Edward Kmett: [...] > I would suggest you rephrase this as a formal proposal, then I can > happily vote +1. Seeing the "wonderful" interrelation between elem, nub, nubBy and i.e. unionBy eq xs ys = xs ++ foldl (flip (deleteBy eq)) (nubBy eq ys) xs intersectBy eq xs ys = [x | x <- xs, any (eq x) ys] (note that "any (eq x)" could be "elemBy eq") I see hardly a chance to make a sensible proposal. I think, it is wrong to change the implementation of "elem" and "notElem" since I expect the "key" to be the first argument of the eq-comparison (in contrast to the REPORT_PRELUDE!). But this all would not matter if the eq-function are always symmetric, which may be not the case in practise. So a change could break existing code. > I'd also suggest rephrasing rhe mapAccumR as a formal proposal. I'm not > sure yet of whether or not I'd be behind that one, but make both > proposals separately, so they can pass individually. I also don't see a relation to mapAccumR, so why don't you make such a separate proposal? C.

1 0

TypeFamilies vs. FunctionalDependencies & type-level recursion
by David Mazieres 05 Jul '11

05 Jul '11

I'm not sure if these extensions are still under discussion or if the topic is dead (wiki pages 5 years old). However, the Haskell' wiki page for FunctionalDependencies suggests AssociatedTypes is a more promising approach, yet the AssociatedTypes page misses a major Con compared to FunctionalDependencies that I think should be there. One of the more disgusting but also powerful implications of FunctionalDependencies is that, in conjunction with OverlappingInstances and UndecidableInstances, you can do recursive programming at the type level. This has been (ab)used to do some cool things (e.g., HList, HaskellDB, OOHaskell). As an example, consider the following simple (key, value) lookup function that operates at the type level (inspired by HList): {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} data HNil = HNil deriving (Show) data HCons h t = h :* t deriving (Show) infixr 2 :* data A = A deriving (Show) data B = B deriving (Show) data C = C deriving (Show) abc :: HCons (A, Int) (HCons (B, Int) (HCons (C, Int) HNil)) abc = (A, 1) :* (B, 2) :* (C, 3) :* HNil class HLookup k l v | k l -> v where hLookup :: k -> l -> v instance HLookup k (HCons (k, v) l) v where hLookup _ (h :* t) = snd h instance (HLookup k l v) => HLookup k (HCons h l) v where hLookup k (h :* t) = hLookup k t b :: Int b = hLookup B abc -- Returns 2 The key to hLookup is that OverlappingInstances selects the most specific match, thereby breaking the recursion when the requested key type matches the key of the pair at the head of the list. By contrast, TypeFamilies cannot permit a function such as hLookup. One may try something along the lines of: class HLookup k l where type HLookupResult k l hLookup :: k -> l -> HLookupResult k l instance HLookup k (HCons (k, v) l) where type HLookupResult k (HCons (k, v) l) = v hLookup _ (h :* t) = snd h instance (HLookup k l) => HLookup k (HCons h l) where type HLookupResult k (HCons h t) = HLookupResult k t hLookup k (h :* t) = hLookup k t But now you have overlapping type synonyms, which pose a safety threat where the more-specific instance is not in scope. Therefore, Haskell likely cannot be extended to accept code such as the above. One possible extension that *would* enable type-level recursive programming is the ability to constrain by inequality of types. I noticed GHC is on its way to accepting "a ~ b" as a constraint that types a and b are equal. If there were a corresponding "a /~ b", then one might be able to say something like: instance HLookup k (HCons (k, v) l) where ... instance (h /~ (k, v), HLookup k l) => HLookup k (HCons h l) where ... Of course, I have no idea how the compiler could know such constraints are sufficient to avoid overlapping types. I suspect figuring it out would be hard given that instance matching happens before context verification and that the overlapping errors must happen at instance matching time. My bigger point is that if the Haskell' committee ever considers adopting one of these proposals or one intended to supersede them, I hope there is a way to do recursive type-level programming. A likely corollary is the need for a mechanism to avoid instance overlap between recursive and base cases by asserting type inequality in the recursive case. David

12 38

Proposal: fix "simple pattern binding" and "declaration group"
by dm-list-haskell-prime＠scs.stanford.edu 01 Jul '11

01 Jul '11

The Haskell 2010 report contains ambiguous and sometimes contradictory definitions of the terms "simple pattern binding" and "declaration group". The confusion is compounded by the phrasing of the monomorphism restriction, which is carried over from the Haskell98 report in which a different definition of declaration group required a more complicated description of the monomorphism restriction. A recent thread on the haskell cafe mailing list summarizes the problem: http://www.haskell.org/pipermail/haskell-cafe/2011-June/093488.html To resolve this confusion, I propose applying the following changes to the Haskell 2010 report for the next revision of the language: In section "4.4.3.2 Pattern bindings", replace: - A pattern binding binds variables to values. A simple pattern - binding has form p = e. The pattern p is matched “lazily” as - an irrefutable pattern, as if there were an implicit ~ in - front of it. See the translation in Section 3.12. With the following: A pattern binding binds variables to values. A /simple/ pattern binding is one in which the pattern consists of a single variable, yielding a declaration of the form /var/ /rhs/. Recall from section 3.17 that such a pattern is always irrefutable. In section 4.5.1, replace this text: - A binding b1 depends on a binding b2 in the same list of - declarations if either - - 1. b1 contains a free identifier that has no type signature - and is bound by b2, or with the following: A binding b1 depends on a binding b2 in the same list of declarations if either 1. b1 contains a free identifier v, v is bound by b2, and the list of declarations does not contain a type signature for v; or Add the following text to the end of section 4.5.1: For example, the following two bindings form a single declaration group, as each contains a free identifier bound by the other and, despite the presence of expression type-signatures, the declaration list contains no type signatures: (x, y) = (z :: Int, 1 :: Int) -- binds y, has z free (z, t) = (2 :: Int, y :: Int) -- binds z, has y free Conversely, the following two bindings constitute two different declaration groups. Even though f and g contain each other as free identifiers, the declaration list contains a type signature for f, so g does not depend on f. f :: (Eq a) => (a, a) -> (Bool, a) f = \(x, y) -> (x == y, snd (g (x, y))) g pair = (fst (f pair), snd pair) Note that if b is a function binding or simple pattern binding and b is accompanied by a type signature, then b always constitutes a /singleton/ declaration group, regardless of what free identifiers it contains. (If b is a non-simple pattern binding, it may bind multiple variables simultaneously.) Finally, change Rule 1 of the monomorphism restriction in section 4.5.5, by replacing the following text: - We say that a given declaration group is unrestricted if and - only if: - - (a): every variable in the group is bound by a function - binding or a simple pattern binding (Section 4.4.3.2), - and - - (b): an explicit type signature is given for every variable in - the group that is bound by simple pattern binding. with the following: We say that a given declaration group is unrestricted if and only if: (a): every variable in the group is bound by a function binding, or (b): the group consists of exactly one binding, the binding is a simple pattern binding of some variable v, and the binding's declaration list contains an explicit type signature for v. If there is agreement on these changes or something along these lines, I can create a ticket and/or wiki page. I propose the name SimplePatternBinding for the change. David

3 5

Re: TypeFamilies vs. etc - TTypeable
by Anthony Clayden 28 Jun '11

28 Jun '11

Thank you Oleg >I have implemented type-level TYPEREP (along with a small library for >higher-order functional programming at the type level). Overlapping >instances may indeed be avoided. The library does not use functional >dependencies either. > ........ So this is essentially the approach discussed in the HList paper, translated to a Type Family context. Totally brilliant, and almost impenetrable. If I understand what's going on (big IF), I'm wondering a few things: - You've used type-level NAT to encode the type. What if two different types get encoded as the same NAT? In your MonadState example you've encoded StateT as FOUR ::: NAT, and W as FIVE. What if there's some other module (in a distant import) that also uses FOUR? In general, how do we co-ordinate the encoding of types to avoid duplicates? - Special instances: you say for MonadState' "add more if needed". But can we really do that? The default instance has constructor MState hard coded in the result of function MState'. - Groundedness issues (per Section 9 of the HList paper, 'Reification ...' subsection. The instances of TYPEOF require the type constructor to be grounded; and TYPEOF recurses to reify all the constructor's type arguments. Does this mean all types and arguments have to be fully grounded? Is this really gaining anything over the Type-indexed rows approach you discuss in the HList paper - that is, using instances instance TypeEq x x HTrue instance (b ~ HFalse) => TypeEq x y b -- (using ~ instead of TypeCast) except that it's avoiding fundeps and overlapping instances? That is: is the TYPEOF approach to type equality going to suffer the same issues discussed at the start of section 9 'By chance or by design'? I'm imagining a Haskell' with type functions and a restrained sort of instance overlap: type instance TypeEqF x x = HTrue type instance TypeEqF x y | x /~ y = HFalse (Which is roughly what last month's Haskell-prime discussion talked about, and SPJ picked up on at the start of this TypeFamilies thread.) AntC

2 2

Re: TypeFamilies vs. etc - restrined instance overlap type inference
by Anthony Clayden 26 Jun '11

26 Jun '11

Hi all some more, Continuing the idea of a restrained form of instance overlap for type functions ... Type inference I don't expect to be totally decidable, so that may torpedo the idea altogether. I do expect it to be more coherent than GHC's current handling of overlap with fundeps. What's impressive is how much of a 'cottage industry' has grown up using overlaps. Do we really want to throw all that away? SPJ summarises that the idea is that: > ... type inference only picks > an equation when all the earlier equations are guaranteed > not to match. So there is no danger of making different > choices in different parts of the program (which is what > gives rise to unsoundness). In my earlier post I proposed how to validate instances so that they don't overlap (although the instance heads might do), by using type inequality restraints. In an ancient mail list discussion of similar ideas [haskell-prime February 2006 'overlapping instances and constraints'] when type families were first mooted, SPJ commented: "Concerning [a suggested approach] it involves *search* which the current mechanism does not. Presumably you have in mind that the type system should "commit" only when there is only one remaining instance declaration that can fit. You need to be very careful not to prune off search branches prematurely, because in a traditional HM type checker you don't know what all the type are completely. And you need to take functional dependencies into account during the search (but not irrevocably). I have not implemented this in GHC. I don't know anyone who has. I don't even know anyone who has specified it. All good stuff to debate. [...] In general, I think that type-system proposals are much easier to evaluate when accompanied with formal type rules. It's not just a macho thing -- it really helps in debugging the dark corners. " Inference for instances without restraints proceeds as usual. Instances with type inequality restraints are validated not to overlap those without, so if there's an instance that fits, we can apply it confidently. What we do need is rules for how type inference gathers evidence of a type inequality from the type environment. Once we've inferred that evidence, we can 'fit' to the instance head and apply the RHS of the type function (or apply the type Class). Evidence of type inequality: Base case: T t1 t2 ... tn /~ U u1 u2 ... um, where T, U type constructors and T /= U n, m >= 0 Derived case: T t1 t2 ... tn /~ T u1 u2 ... un, where T type constructor And ti /~ ui for some i (I suspect this is far as GHC tries currently to discriminate overlaps, based on the groundedness experiments discussed in the HList paper section 9. I think it's possible to get a bit further ...) also derived: t t1 t2 ... tn /~ t u1 u2 ... un, where t is a type term AND ti /~ ui (t can be type term except a type function) and: T t1 t2 ... tn /~ t u1 u2 ... un, if ti /~ ui, where T type constructor (again t can be any type term except a type function note that matching type args is from the right-hand end, because t might turn out to be of the form (tt uu1 uu2 ...) essentially: whatever t resolves to, the overall types must be unequal) as well: T t1 t2 ... tn /~ t u1 u2 ... um, where T type constructor And m > n (t any type term except a type function, if m > n then t's arity is more than T's, so they can't be the same.) Algebra: Type inequality is symmetric: t /~ u ==> u /~ t transitive across equality: t /~ u, u ~ v ==> t /~ v My (highly hand-wavy) understanding from the 'outside-in' papers of how type inference proceeds is that the possible instances 'compete' to apply until one fits. (If there would be several that might fit, it's 'first come first served'. So it's essential under GHC's current forms of type families that overlapping instances are confluent.) With type inequality restraints we keep to that rule: inference must not apply an instance until the type environment provides evidence of the inequality. AntC

1 0