February 2012 - Haskell-prime

Re: TypeFamilies vs. FunctionalDependencies & type-level recursion
by Anthony Clayden 11 Jun '12

11 Jun '12

> > Sorry for the late reply. Thanks Oleg, I take it the Northern hemisphere is now on academic summer holidays. > > [snip] > > > Finally, I still think most of the "magic" in everything > > we've been talking about boils down to being able to > > have a type variable that can take on any type *except* > > a certain handful. This would allow us to avoid > > overlapping instances of both classes and type families, > would allow us to define TypeEq, etc. Moreover, it would > > be a more direct expression of what programmers intend, > > and so make code easier to read. Such a constraint > cannot be part of the context, because > > Alas, such `type variables' with inequality constraints > are quite complex, and the consequences of their > introduction are murky. Let me illustrate. First of all, > the constraint /~ (to be used as t1 /~ Int) doesn't help > to define TypeEq, etc. because constraints are not used > when selecting an instance. ... Yes indeed we can't use constraints when selecting an instance, several posters have pointed this out. I've suggested we call these inequality 'restraints' rather than 'constraints'. And a different syntax has been proposed, similar to pattern guards: type instance TypeEq a b | a /~ b = HTrue > Instances are selected only by > matching a type to the instance head. Instance selection > based on constraints is quite a change in the type checker > , and is unlikely to be implemented. I agree that selecting instances based on constraints would be abig change, but ... Selecting instances based on inequalities is already implemented in GHC and Hugs. (And has been successfully used for over a decade.) You've used it extensively yourself in the HList work, and much other type-level manipulation (such as IsFunction). Unfortunately, it's not called 'instance selection based on inequalities' (or some such), and its implementation got all mixed up with Functional Dependencies, which to my mind is an orthogonal part of the design. Instance selection based on inequalities is called 'Overlapping Instances'. The difficulty in adopting it into Haskell prime is that it isn't thoroughly specified, and you can currently only use it with FunDeps. To avoid confusion with FunDeps, let's imagine we could use overlapping instances with Type Families: type family HMember e l type instance HMember a HNil = HFalse type instance HMember a (HCons a l') = HTrue type instance HMember a (HCons b l') = HMember a l' Selecting that last instance implies a /~ b. (Otherwise the HTrue instance would be selected). Using inequality restraints, we'd write that last instance as: type instance HMember a (HCons b l') | a /~ b = HMember a l' And by putting an explicit inequality we are in fact avoiding the trouble with overlaps and all their implicit logic: The compiler can check that although the instance heads do overlap, the inequality disambiguates the instances. So type inference could only select one instance at most. I think this could be implemented under the new OutsideIn(X) type inference: Inference for the ordinary instances proceeds as usual. Inequalities give rise to implication terms(as used for GADTs), with the inequality in the antecedent: (a /~ b) implies (TypeEq a b ~ HFalse) As with GADTs, inference needs evidence that a /~ b before applying the consequent. There is no danger of clashing with other instances of TypeEq, because the instance (including inequality) doesn't overlap any of them. (I made some long posts to the Haskell-prime list last month, explaining in more detail, and responding to your TTypeable suggestion.) > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime

7 22

FW: 7.4.1-pre: Show & Integral
by Simon Peyton-Jones 06 Mar '12

06 Mar '12

I'm confused too. I'd welcome clarification from the Haskell Prime folk. S -----Original Message----- From: Serge D. Mechveliani [mailto:mechvel@botik.ru] Sent: 23 December 2011 17:36 To: Simon Peyton-Jones Subject: Re: 7.4.1-pre: Show & Integral On Thu, Dec 22, 2011 at 08:14:54PM +0000, Simon Peyton-Jones wrote: > | 2011/12/22 Edward Kmett <ekmett(a)gmail.com>: > | > The change, however, was a deliberate _break_ with the standard that > | > passed through the library review process a few months ago, and is now > | > making its way out into the wild. > | > | Is it reasonable to enquire how many standard-compliant implementations > | of Haskell there are? > > Just to be clear, the change IS the standard. GHC has to change to be compliant. > At least that's how I understand it. I am confused. I am looking now at the on-line specification of Haskell-2010, 6.3 Standard Haskell Classes. It shows that Integral includes Show: Eq Show \ / Num | Enum Real \ | Integral This is also visible in the further standard class declarations in this chapter. Hence, for `x :: Integral a => a' it is correct to write (shows x ""). And ghc-7.4.0.20111219 does not allow this. So, ghc-7.4.0.20111219 breaks the 2010 standard. Now, Edward Kmett writes that this break is done deliberately. Am I missing something? I witness this for the first time: that GHC deliberately breaks the current Haskell standard. Probably, many people (as myself) dislike this point of the standard. Well, they can write a dummy Show implementation for their type T: showsPrec _ _ = showString "(<t> :: T)", and wait for an improved standard, say, Haskell-II -- ? Regards, ------ Sergei mechvel(a)botik.ru

4 3

Re: simple extension to ghc's record disambiguation rules
by Anthony Clayden 18 Feb '12

18 Feb '12

> Hi, I'd like to propose an extremely simple extension to > ghc's record disambiguation rules, > John, I've just posted a proposal on the 'Records in Haskell' wiki that I think will do the job for you. "Declared Overloaded Record Fields" (DORF). I'd appreciate feedback. > my motivation is that I often have record types with > multiple constructors but common fields. > This is exactly the use case I'm aiming at. > > so, my proposal is that when you come across something > like > > (e::RecType) { blah = foo } > > (with an explicit type signature like shown) > ... My proposal is the same, except that you don't need a type sig (or not always). That record syntax desugars to a call to `set', which is a method of class `Has' (which also has method `get'). Has/get/set are overloaded for each record/field combination. The instance is generated at the record declaration, instead of the H98 record selector function. > > It is also backwards compatible for expressions, but would > be a new thing for patterns which generally don't allow > type signatures there. > DORF is backwards compatible with H98 record selectors, in the sense that polymorphic selectors (using `get') are just functions. > It sidesteps type checker interactions by only being > triggered when an explicit type annotation is included. > (DORF uses usual instance resolution by record type and field.) > ideally it would be combined with the 'update' and > 'label-based pattern-matching' extensions from this page > http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords > > John > DORF supports update and pattern matching by label, per -XDismabiguateRecordFields and friends. Anthony

1 0

simple extension to ghc's record disambiguation rules
by John Meacham 17 Feb '12

17 Feb '12

Hi, I'd like to propose an extremely simple extension to ghc's record disambiguation rules, my motivation is that I often have record types with multiple constructors but common fields. so the handy idiom of f Rec { .. } = do blah return Rec { .. } won't work, because I don't know the specific constructor. so, my proposal is that when you come across something like (e::RecType) { blah = foo } (with an explicit type signature like shown) You interpret 'blah' as if it is a field of the record of type 'Rec'. This gives the advantages of record field names being scoped by type but without you having to specify the precise constructor. It is also backwards compatible for expressions, but would be a new thing for patterns which generally don't allow type signatures there. It sidesteps type checker interactions by only being triggered when an explicit type annotation is included. ideally it would be combined with the 'update' and 'label-based pattern-matching' extensions from this page http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords John

1 0

Re: Proposal: require spaces around the dot operator
by Doug McIlroy 13 Feb '12

13 Feb '12

> +1 to the idea of requiring spaces around all operators. > It's just good style > Cutting things close syntactically just because you can is perhaps > not the best of ideas Haskell is mathematical both in substance and style. I would not lightly prohibit the use of spacing conventions that have proved over centuries to aid in understanding syntactic strucure. For example, this code fragment to define addition on lists is instantly intelligible. instance Num a => Num [a] where (f:fs) + (g:gs) = f+g : fs+gs But the formula becomes merely an obscure procession of symbols when rewritten with the operators set off by spaces: ( fs : gs ) + ( g : gs ) = f + g : fs + gs And it becomes too long and too subtly modulated to take in at a glance if more spacing is added to emphasize precedence: ( f : fs ) + ( g : gs ) = f + g : fs + gs Doug McIlroy

5 4

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 09 Feb '12

09 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