October 2018 - Haskell-prime

Re: A question about run-time errors when class members are undefined
by Anthony Clayden 24 Oct '18

24 Oct '18

> We are adding classes and instances to Helium. > We wondered about the aspect that it is allowed to have a class instance > of which not all fields have a piece of code/value associated with them, ... I have a suggestion for that. But first let me understand where you're going with Helium. Are you aiming to slavishly reproduce Haskell's classes/instances, or is this a chance for a rethink? Will you want to include associated types and associated datatypes in the classes? Note those are just syntactic sugar for top-level type families and data families. It does aid readability to put them within the class. I would certainly rethink the current grouping of methods into classes. Number purists have long wanted to split class Num into Additive vs Multiplicative. (Additive would be a superclass of Multiplicative.) For the Naturals perhaps we want Presburger arithmetic then Additive just contains (+), with `negate` certainly in a different class, perhaps (-) subtract also in a dedicated class. Also there's people wanting Monads with just `bind` not `return`. But restructuring the Prelude classes/methods is just too hard with all that legacy code. Even though you should be able to do: class (Additive a, Subtractive a, Negative a, Multiplicative a, Divisive a) => Num a Note there's a lot of classes with a single method, and that seems to be an increasing trend. Historically it wasn't so easy in Haskell to do that superclass constraints business; if it had been perhaps there would be more classes with a single method. Then there's some disadvantages to classes holding multiple methods: * the need to provide an overloading for every method, even though it may not make sense (or suffer a run-time error, as you say) * the inability to 'fine tune' methods for a specific datatype [**] * an internal compiler/object code cost of passing a group of methods in a dictionary as tuple (as apposed to directly selecting a single method) [**] Nats vs Integrals vs Fractionals for `Num`; and (this will be controversial, but ...) Some people want to/some languages do use (+) for concatenating Strings/lists. But the other methods in `Num` don't make any sense. If all your classes have a single method, the class name would seem to be superfluous, and the class/instance decl syntax seems too verbose. So here's a suggestion. I'll need to illustrate with some definite syntax, but there's nothing necessary about it. (I'll borrow the Explicit Type Application `@`.) To give an instance overloading for method `show` or (==) show @Int = primShowInt -- in effect pattern matching on the type (==) @Int = primEqInt -- so see showList below That is: I'm giving an overloading for those methods on type `Int`. How do I declare those methods are overloadable? In their signature: show @a :: a -> String -- compare show :: Show a => a -> String (==) @a :: a -> a -> Bool Non-overladable functions don't have `@a` to the left of `::`. How do I show that a class has a superclass constraint? That is: a method has a supermethod constraint, we'll still use `=>`: show @a :: showsPrec @a => a -> String -- supermethod constraint show @[a] :: show a => [a] -> String -- instance decl, because not bare a, with constraint => show @[a] xss = showList xss (*) @a :: (+) @a => a -> a -> a Is this idea completely off the wall? Take a look at Wadler's original 1988 memo introducing what became type classes. http://homepages.inf.ed.ac.uk/wadler/papers/class-letter/class-letter.txt It reviews several possible designs, but not all those possibilities made it into his paper (with Stephen Blott) later in 1988/January 1989. In particular look at Section 1's 'Simple overloading'. It's what I'm suggesting above (modulo a bit of syntax). At the end of Section 1, Wadler rejects this design because of "potential blow-ups". But he should have pushed the idea a bit further. Perhaps he was scared to allow function/method names into type signatures? (I've already sneaked that in above with constraints.) These days Haskell is getting more relaxed about namespaces: the type `@`pplication exactly allows type names appearing in terms. So to counter his example, the programmer writes: square x = x * x -- no explicit signature given square :: (*) @a => a -> a -- signature inferred, because (*) is overloaded rms = sqrt . square -- no explicit signature rms :: sqrt @a => a -> a -- signature inferred Note the inferred signature for `rms` doesn't need `(*) @a` even though it's inferred from `square`. Because (*) is a supermethod of `sqrt`. `sqrt` might also have other supermethods, that amount to `Floating`. > ... a run-time error results. > > Does anyone know of a rationale for this choice, since it seems rather unhaskell-like. If you allow default method implementations (in the class, as Cale points out), then I guess you have to allow instance decls that don't mention all the methods. I think there should at least be a warning if there's no default method. Also beware the default method might have a more specific signature, which means it can't be applied for some particular instance. Altogether, I'd say, the culprit is the strong bias in early Haskell to bunch methods together into classes. These days with Haskell's richer/more fine-tuned typeclass features: what do typeclasses do that can't be done more precisely at method level -- indeed that would _better_ be done at method level? AntC

9 16

Re: A question about run-time errors when class members are undefined
by Anthony Clayden 14 Oct '18

14 Oct '18

On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote You may be interested in Carlos Camarao’s interesting work. For a long > time now he has advocated (in effect) making each function into its own > type class, rather that grouping them into classes. Perhaps that is in > line with your thinking. > Could I ask Simon direct, since it was he who introduced the topic. When you say "interesting work", what is that evaluation based on? Is there a paper or summary you've seen that expresses the ideas? (Because despite the exhaustive and exhausting rounds on github last year, and further comment on this thread, I just can't see anything workable. And the papers that Carlos references ring alarm bells for me, just looking at the Abstracts, let alone delving into the impenetrable type theory.) And could I ask Carlos: are we allowed to know who peer-reviewed your papers? Specifically, was it someone who's up with the state of the art in GHC? Carlos/his team are making bold claims: to provide the functionality of FunDeps/Type functions, Overlapping Instances/Closed Type Families, to avoid the infamous `read . show` ambiguity, to avoid the equally infamous 'orphan instances' incoherence, to preserve principal typing, and to keep it "simple". Then I have to say that if there's evidence for those claims, it's not appearing in the papers. Really the only example presented is `read . show` (plus record field disambiguation). Yes I'd hope the approach for a simple example is "simple". It doesn't seem any more simple than putting an explicit type signature (or we could use type application `@` these days). But I don't expect that would be the place to show off the power/expressivity. Thank you AntC

2 2

Re: Quo vadis?
by Anthony Clayden 09 Oct '18

09 Oct '18

> There was no Haskell 2020 meeting this year at ICFP. Sadly, interest seems to have waned here... Yes that is sad. So either Haskell 2020 won't happen, or it'll be only minor tweaks over H2010, as that was over H98. It's hard to imagine any serious Haskelling without FlexibleInstances/FlexibleContexts, MultiParamTypeClasses, UndecidableInstances -- and yet all of those are beyond Haskell 2010. And they were available in at least 2 compilers by around 2000. (Possibly they weren't by then entirely polished. I saw a claim on a StackOverflow answer that Hugs, last release 2006, is not H2010 compliant: not true; indeed several of the H2010 changes since H98 were proposed by the Hugs dev team, and agreed by the GHC team because GHC had copied Hugs.) I've had comments from non-Haskellers that they won't take Haskell seriously, because it seems to be a bunch of 'risky'/unstable/experimental features. Whereas I know those features have been stable at least a dozen years. And yet we still face the same conundrums as did H2010: With FlexibleInstances we can write overlapping instances. With FlexibleContexts we can put overlapping constraints on an instance, even if the head's types are H98 (non-Flexible). With MultiParamTypeClasses (which were anticipated in Wadler's very earliest 1988 proposal for typeclasses) we're bound to choose FunDeps and/or type families. FunDep instances either need repeated tyvars -- which brings us straight back to FlexibleInstances, or UndecidableInstances -- which will almost certainly lead to FlexibleInstances somewhere. I feel those parts of Haskell have been in suspended animation/arrested development since ~2006: that was the last release of Hugs; the 'FunDeps via CHRs' paper [**]; the start of associated types/type families. [**] AFAICT, that paper was a purely academic exercise: GHC was not changed in light of its findings, so has a bogus implementation of FunDeps that persists to this day. The paper did not address the combo of FunDeps + Overlaps, so said nothing about what had been a stable cottage industry of type-level programming since at least 2004 (the HList paper). Is there a terms of ref for Haskell 2020? Would any of the above issues be within its scope? (Supposing there were any interest ...) AntC

7 14

Quo vadis?
by Mario Blažević 04 Oct '18

04 Oct '18

I could not attend ICFP this year. Has there been any discussion at all of Haskell 2020 there? If so, can the rest of us get a summary?

2 1

A question about run-time errors when class members are undefined
by Jurriaan Hage 01 Oct '18

01 Oct '18

Hello, We are adding classes and instances to Helium. We wondered about the aspect that it is allowed to have a class instance of which not all fields have a piece of code/value associated with them, and that as a result when you happen to call these, a run-time error results. (see Sec. 4.3.2 of the Haskell 2010 report). Does anyone know of a rationale for this choice, since it seems rather unhaskell-like. best, Jur

2 1