- Haskell-prime - Haskell.org

LAST CALL to comment on the Appicative/Monad Proposal
by Mario Blažević 02 Apr '19

02 Apr '19

The very first RFC created (https://github.com/haskell/rfcs/pull/1) the Applicative/Monad Proposal, has now reached the Last Call stage. In order to ground the discussion, I have taken some time to update the Prelude and the text of the Haskell Report with its effects before the call. The rendered report is available at https://github.com/blamario/rfcs/blob/amp/report/report/haskell.pdf for your review. TL;DR: The proposed changes to the report add the latest design of the Applicative and Alternative classes, but otherwise are intentionally minimal. Any further modifications, like the MonadFail proposal or moving return out of the Monad class, should be relegated to new RFCs. In some more detail, the changes are: 1. Applicative has been added as a subclass of Functor and superclass of Monad, its methods and laws as currently defined in the base library. The class and all its methods (pure, (<*>), (<*), (*>), and liftA2) are exported from Prelude, but no other Applicative-related functions (like liftA3) are. 2. The Functor class definition has been moved from module Control.Monad to Control.Applicative in order to avoid circular imports. Note that neither module is a part of the language specification. 3. The Monad class has been left unmodified, apart from making Applicative its superclass and adding return a == pure a as a law. 4. Alternative has been added to the Control.Applicative module, but not to Prelude. This is the same treatment already meted to MonadPlus. I'm unsure why MonadPlus even exists in the report, as it has no relevance to the language specification, and I would gladly remove both classes. Please take some time within the following three weeks (including some extra allowance for the upcoming holiday breaks) to vote for or against the proposal, or to leave a comment with suggestions for its improvement.

8 25

Re: LAST CALL to comment on the Appicative/Monad Proposal
by Doug McIlroy 18 Dec '18

18 Dec '18

I am very glad to see Applicative take its place in the report: one less mystery in understanding Haskell in the wild. The following comments pertain to presentation. 13.1 Functor class "The Functor class is used for types that can be mapped over." "is used for" is extremely vague. Better wording would be "The functor class comprises types that can be mapped over." The same comment applies to section 6.3.5. 13.2 Applicative class A verbal hint about the mnemonic intent of liftA2, like those for liftA and liftA3 in 13.4, would be helpful. Why is the "methods" subsection empty? 13.3 Alternative class This class hasn't been fully integrated into the report. It is missing from the Standard Prelude (Section 9) and from its natural place after 6.3.6. <|> appears here without definition and is not in the index. Why is the "methods" subsection empty? Doug McIlroy

2 1

Re: Helium II
by Anthony Clayden 03 Dec '18

03 Dec '18

On *Thu Nov 29 15:00:19 UTC 2018, Doug McIlroy wrote:* > >* Frankly after you've filtered out all that, I'd be astonished if you** have anything left. It seems to be usual practice on Hackage to switch** on a swag of LANGUAGE pragmas even if this module isn't using them.* >>* (MPTCs, FlexibleInstances/Contexts in particular.)* > A depressing remark, which comes close to saying > there is no true Haskell. ? There wasn't a true Haskell in 1998. Already Hugs (in HugsMode) and GHC (with glasgow-extns) had MPTCs, FlexibleInstances/Contexts, FunDeps, UndecidableInstances. Overlapping instances was optional extra. > It's one reason I hang mostly with Hugs. Interesting. Does that mean Hugs98? How on earth do you manage without at least some of the above? > GHC pretty well repudiates Haskell 2010. So does Hugs (in HugsMode): a large proportion of the extra features in H2010 were suggested by the Hugs teams; and Hugs 2006 was already far advanced beyond it. > May Haskell 2020 receive more respect! I think you'll need to adjust your expectations: I doubt H2020 will happen. There was a glimmer of activity last month, but this list has resumed its moribund state. So I think we can put last month down to dead cat bounce. If H2020 does happen, HugsMode will still be well ahead of whatever gets added. AntC

3 2

Re: Helium II
by Doug McIlroy 29 Nov '18

29 Nov '18

> Frankly after you've filtered out all that, I'd be astonished if you > have anything left. It seems to be usual practice on Hackage to switch > on a swag of LANGUAGE pragmas even if this module isn't using them. > (MPTCs, FlexibleInstances/Contexts in particular.) A depressing remark, which comes close to saying there is no true Haskell. It's one reason I hang mostly with Hugs. GHC pretty well repudiates Haskell 2010. May Haskell 2020 receive more respect! Doug

1 0

Re: Helium II
by Anthony Clayden 28 Nov '18

28 Nov '18

*On 2018-11-28 14:03:30 UTC, **Mario Blažević wrote:* >> On 2018-11-28 2:17 a.m., Jurriaan Hage wrote: > >>* do we actually have something like an extensive set of tests* >>* to throw at any Haskell 2010 compliant compiler that would help find mistakes on our parr?* > If you want to be really thorough: > > 1. start with all of Hackage, > > 2. filter out all packages with the extensions: field in the cabal file, > > 3. filter out all modules with the {-# LANGUAGE ... #-} pragma, > > 4. recursively filter out all modules that import any filtered-out module, > > 5. you're left with a large set of pure Haskell 2010 modules. At 3.b. also filter out anything with inline pragmas like {-# OVERLAPS/PING/ABLE, INCOHERENT #-}. Note that GHC allows "the possibility" of instances to overlap even without any flags/pragmas set. It's only if you try to use them that it starts insisting on pragmas. Whereas the H2010 standard is clear that overlaps are not allowed. What about anything that relies on the FTP changes to Prelude? Has Juriaan's team upgraded their Prelude? Frankly after you've filtered out all that, I'd be astonished if you have anything left. It seems to be usual practice on Hackage to switch on a swag of LANGUAGE pragmas even if this module isn't using them. (MPTCs, FlexibleInstances/Contexts in particular.) AntC

1 0

Helium II
by Jurriaan Hage 28 Nov '18

28 Nov '18

Dear all, We’ve been active since September making the Helium compiler more Haskell 2010 compliant. In particular, we have a branch with support for Haskell 2010 type classes, a branch that supports import/export following the standard, and a branch that compiles to LLVM instead of the `old’ Helium-specific LVM that has become harder and harder to maintain. These still need to be integrated. When I find time for that is hard to say. Another project will be taking place in the period Feb-Apr and I expect we can tie up a lot of loose ends then. Current loose ends include newtype, record syntax, integration of previous projects, Cabal support, Quickcheck, strict data fields, improving the LLVM back-end. One thing I have wondered about: do we actually have something like an extensive set of tests to throw at any Haskell 2010 compliant compiler that would help find mistakes on our parr? My students have come up with a range of examples to test their implementations, but there is nothing like a set of programs you’ve never seen or heard about. We shall also be adding support for GADTs as part of a reseach project this course year. Again, a large range of examples would be welcome indeed. best, Jur

2 1

The first proposal has been merged
by Mario Blažević 27 Nov '18

27 Nov '18

Break out the champagne, because the first Haskell 2020 proposal has been fully merged [1]. By fully merged, I mean that the text of the report has been updated, so we have accomplished something material. Should the Haskell 2020 commitee agree so, we now have the option to declare the Haskell 2018 standard finished, merge the report text back into the official Haskell Report, and hand it over to future generations. Admittedly the RFC in question, -XRelaxedPolyRec, was probably the most trivial possible. My preference would be for the members of the committee to follow the lead of this proposal and apply the same process to more significant issues. The process to follow is: 1. Take any RFC you're interested in from the In Discussion column of the repo project (https://github.com/haskell/rfcs/projects/1) Alternatively, write up a new proposal, put it up for discussion, and wait a decent time. 2. If there is no serious objection to the proposal after a while, make sure all technical objections are addressed and move the RFC to the Last Call column. Declare on the mailing list that you've done so. 3. Modify the text of the report on the same branch where the RFC is written up. If there is no objection to the proposal in the Last Call status in the following two weeks (and there is some approval), move the proposal into the Ready for Report column and declare so on the mailing list. 4. Leave at least another two weeks to refine the details of the Report text, then merge the RFC. [1] https://github.com/haskell/rfcs/pull/17

2 1

LAST CALL to comment on the RelaxedPolyRec proposal
by Mario Blažević 18 Nov '18

18 Nov '18

I hereby officially announce that the RFC for the relaxed dependency analysis (https://github.com/haskell/rfcs/pull/17) has attained the rarefied status of Last Call. Please take some time within the following two weeks to vote for or against the proposal, or just leave a comment to indicate you're still alive but didn't form an opinion on it.

1 1

Report merged, steps to follow
by Mario Blažević 05 Nov '18

05 Nov '18

Four weeks having passed since the previous discussion with no objections, I have now merged the content of the Haskell Report from https://github.com/haskell/haskell-report into https://github.com/haskell/rfcs To remind everybody again, the point of this move was to enable adding an actionable change to the report to every RFC. From this point on, any proposal that passes the full process to becoming accepted can update the report by the simple act of getting merged. In order to test this process, over a year ago I've picked and submitted the least controversial RFC I could find, namely https://github.com/haskell/rfcs/pull/17. There has been no objection to the proposal. In fact there has been no comment whatsoever, but I suppose that's beside the point. So today I have moved the RFC to the "Last Call" column (https://github.com/haskell/rfcs/projects/1) as the first and only proposal to gain that awesome status. It's not at all clear what should happen to the RFC between this point and it getting merged, but I'm determined to test drive the process with it. This is my plan: 1. I'm going to add update the report with a patch to the report content, then 2. wait another two weeks for any objection before 3. moving the proposal from the Last Call to the Ready for Report status, then 4. announce that the proposal is Ready for Report and 5. wait another two weeks for the full approval, then finally 6. merge the RFC. The only flaw in my cunning plan above is defining what constitutes "the full approval". The committee being rather ... disengaged and scattered, there is little hope of getting 50% of votes from all its members. The criteria of no raised objection, which I've used so far, seems much too lax for a full approval. I think the only reasonable fair criteria of success would be a public and unanimous approval by at least N committee members. I have no idea what N should be, but I know that if this test proposal can't garner N approvals, no proposal will ever pass the hurdle. To make it plain, I suggest we take the number of committee members that comment on the test proposal as the maximum bound of N. I do hope max(N) > 1.

3 2

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