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. >
No I think you're mis-apprehending. From the abstract to the group's SBLP2016 paper: "This depends on a modularization of instance visibility, as well as on a redefinition of Haskell’s ambiguity rule." You might remember early last year Carlos submitted a proposal (in two rounds). Your comments were very relevant https://github.com/ghc-proposals/ghc-proposals/pull/48#issuecomment-287124007 Relevant because not just was it difficult to understand the proposal, the proposal had no answer to how instance resolution was to behave. "expression ambiguity" turned out to mean: use module scope to resolve overloading. In the second round of the proposal and in an extended email exchange off-forum with (I think it was) Rodrigo Ribeiro in Carlos' group I tried to tease out how module-scoped instances were going to work for a method exported to a module where there was a different instance in scope. Of course 'orphan instances' are the familiar symptom in GHC. Wadler & Blott's 1988 paper last paragraph had already explained: "But there is no principal type! " Perhaps that is in line with your thinking. > Not at all. My thinking is coming directly from Wadler's early 1988 memo that I referenced (note *not* the W&B paper) + using some of GHC's more recent features like explicit type application in terms; and its counterpart: explicit method application in types. I wonder how different would have been the history of Haskell if Wadler had not borrowed the terminology "class" and "method". Since Helium has a focus on Haskell learners/beginners: I wonder how much confusion we might have saved those coming from OOP where the terms mean something really quite different. We might have avoided "class" altogether; and talked of "overloaded function". AntC *From:* Haskell-prime <haskell-prime-boun...@haskell.org> *On Behalf Of *Anthony > Clayden > *Sent:* 06 October 2018 04:19 > *To:* Petr Pudlák <petr....@gmail.com> > *Cc:* haskell-prime@haskell.org > *Subject:* Re: A question about run-time errors when class members are > undefined > > > > > > On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák <redir...@vodafone.co.nz> > wrote: > > > > IIRC one of the arguments against having many separate classes is that a > class is not a just set of methods, it's also the relations between them, > > > > Hi Petr, I was talking about splitting out Haskell's current class > hierarchy as a step towards doing away with classes altogether. If your > language insists on methods being held in classes, that's just tedious > bureacracy to invent class names. > > > > The relations between classes (including between single-method classes) > can be captured through superclass constraints. For example, in the Haskell > 2010 report > > > > class (Eq a, Show a) => Num a where ... > > > > such as the important laws between `return` and `>>=`. And then for > example a class with just `return` doesn't give any information what > `return x` means or what should be its properties. > > > > Then make Bind a superclass constraint on `return` (or vice versa, or both > ways). > > > > Just as the laws for Num's methods are defined in terms of equality > > > > x + negate x == fromInteger 0 -- for example > > > > Talking about laws is a red herring: you can't declare the laws/the > compiler doesn't enforce them or rely on them in any way. Indeed the > Lensaholics seem to take pleasure in building lenses that break the (van > Laarhoven) laws. > > > > > > > > That said, one of really painful points of Haskell is that refactoring a > hierarchy of type-classes means breaking all the code that implements them. > This was also one of the main reasons why reason making Applicative a > superclass of Monad took so long. It'd be much nicer to design type-classes > in such a way that an implementation doesn't have to really care about the > exact hierarchy. > > > > Yes that's what I was saying. Unfortunately for Haskell's Num class, I > think it's just too hard. So a new language has an opportunity to avoid > that. If OTOH Helium wants to slavishly follow Haskell, I'm wondering what > is the point of Helium. > > > > With Applicative, IIRC, refactoring had to wait until we got Constraint > kinds and type families that could produce them. Would Helium want to put > all that into a language aimed at beginners? > > > > > > For example, in Haskell we could have > > > > class (Return m, Bind m) => Monad m where > > > > without any methods specified. But instances of `Monad` should be only > such types for which `return` and `>>=` satisfy the monad laws. > > > > First: what does "satisfy the xxx laws" mean? The Haskell report and GHC's > Prelude documentation state a bunch of laws; and it's a good discipline to > write down laws if you're creating a class; but it's only documentation. > Arguably IO, the most commonly used Monad, breaks the Monad laws in rather > serious ways because it imposes sequence of execution; and it would be > unfit for purpose if it were pure/lazy function application. > > > > Then: what do you think a language could do to detect if some instance > satisfies the laws? (Even supposing you could declare them.) > > > > > > And this would distinguish them from types that have both `Return` and > `Bind` instances, but don't satisfy the laws. > > > > You could have distinct classes/distinct operators. Oh, but then `do` > dotation would break. > > > > > > Unfortunately I'm not sure if there is a good solution for achieving both > these directions. > > > > I don't think there's any solution for achieving "satisfy the xxx laws". > > > > > > AntC > > > > > > čt 4. 10. 2018 v 3:56 odesílatel Anthony Clayden < > anthony_clay...@clear.net.nz> napsal: > > > 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 > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhomepages.inf.ed.ac.uk%2Fwadler%2Fpapers%2Fclass-letter%2Fclass-letter.txt&data=02%7C01%7Csimonpj%40microsoft.com%7C5ec7c3a23a9746bb154b08d62b3a7ba2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636743927613528630&sdata=vXgR1YLqw8ERzEbhVZBGr%2FpB5fMLMmYtnwt6Bpp4wGs%3D&reserved=0> > > > > 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 > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fhaskell-prime&data=02%7C01%7Csimonpj%40microsoft.com%7C5ec7c3a23a9746bb154b08d62b3a7ba2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636743927613528630&sdata=%2FVDtNLEzevef69Qs9rzrd5V2lBJzMLjRAxBBYvbsPAs%3D&reserved=0> > >
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
