On Tue, Jul 7, 2009 at 10:27 AM, Bulat Ziganshin wrote:

Hello Simon,

Tuesday, July 7, 2009, 6:04:46 PM, you wrote:

i can't understand. does this list supposed to be full list of changes in haskell'? it seems to include mainly supplementary syntax changes while even Rank2Types are not here, the same for assoc. types, GADTs and other fundamental type system improvements

This is not a complete list of what would be in a next "major Haskell standard (what we've all been calling Haskell'). The problem of producing a new major standard in one step has proven intractable to date. Instead, given the state of completed addenda beyond Haskell 98, this is a provisional list of features that the Haskell' committee thinks would be feasible to include in a 2010 revision of the Haskell standard. We're *very* open to considering features not on this list (consider the results of the various straw polls, for example), but to be eligible for consideration for Haskell 2010 any additional proposals would need a completed, high-quality addendum by August, so the clock is ticking... - Ravi

On 07/07/2009 15:27, Bulat Ziganshin wrote:

Tuesday, July 7, 2009, 6:04:46 PM, you wrote:

i can't understand. does this list supposed to be full list of changes in haskell'? it seems to include mainly supplementary syntax changes while even Rank2Types are not here, the same for assoc. types, GADTs and other fundamental type system improvements

Perhaps you didn't read the Process page? This is the list of changes that are provisionally in Haskell 2010. Haskell' is an ongoing process, producing a new revision every year. The reason that many extensions are not ready to be in the standard is that they haven't been formally specified; indeed, many of them are still changing (e.g. GADTs).

and btw - from my user's POV, we can just start with common GHC& Hugs subset, remove a few features, add a few GHC-specific features and will become close to what should be named next Haskell standard, standard de-facto of Haskell used in last years. why so much time spent on this process..

For the language standard, we need to be absolutely precise about what each extension to the language means. Most of the extensions that GHC implements are barely specified at all. How would you go about implementing, say, scoped type variables in another Haskell compiler? Cheers, Simon

On 07/07/2009 16:40, Claus Reinke wrote:

...

At last year's Haskell Symposium, it was announced that we would change the Haskell Prime process to make it less monolithic. .. In the coming weeks we'll be refining proposals in preparation for Haskell 2010.

Given the incremental nature of the new standards, would it be useful to switch back to version numbers, eg "Haskell 2.0.0 (2010)" instead of "Haskell 2010"? Otherwise, we'll end up with half a dozen more or less current Haskells related by no obvious means. "Haskell'98" was chosen because it projected more permanence than the Haskell 1.x line of Haskell revisions that came before it.

The relationship between the versions will be quite clear: each revision will be specified by a set of deltas to the previous one. I think the year-based naming scheme is fine, especially since we're planning to produce annual revisions. An important question though is what we should call the major versions. There it will probably make sense to use "Haskell 2", "Haskell 3", and so on. I imagine the first major version won't be for a few years, though.

Having API instead of date encoded in the name would support deprecations, breaking changes, or additions as well as make it clear whether a new year's version does break anything or not.

Btw, once upon a time, there was a discussion about an even more modular approach, standardising language extensions without saying which extensions made up a standard language. That would give support to the status quo, where people want to use, say, Haskell'98+FFI+Hierarchical Modules+MPTC+..

In other words, existing language extensions (LANGUAGE pragmas) ought to be standardized (currently, they mean different things in different implementations), independent of whether or not the committee decides to group them into a Haskell X.

What you're suggesting is not incompatible with Haskell'. In Haskell', each change to the language will be independently specified, as an addendum, before being accepted as part of the language. So a side-effect of the standardisation process is a set of addenda, that you could mix and match. GHC will still support one flag per extension, where it makes sense (there's not much point making a flag for fixes and trivial changes). So in GHC, {-# LANGUAGE Haskell2010 #-} could be expanded to the set of extensions in Haskell 2010, and will probably be implemented that way. Cheers, Simon

Isaac Dupree wrote:

Simon Marlow wrote:

...

Remove n+k patterns

oh also -- anything like this that we remove should get a LANGUAGE flag to go along with it. I don't see NPlusKPatterns in Language.Haskell.Extension yet :-) -Isaac

On 07/07/2009 20:17, Simon Peyton-Jones wrote:

| There are a couple sensible removals here. Do we also want to get rid | of the useless class contexts on data-declarations? (that look like | "data Ord a => Set a = Set ...")

Yes! Yes! Kill them.

(In GHC's source code these contexts are consistently called stupid_theta.)

This is listed as "Remove class context on data definitions" in the list of proposals. It doesn't have an owner or a wiki page yet. Any volunteers? Cheers, Simon

On Wed, Jul 08, 2009 at 10:07:21AM +0100, Simon Marlow wrote:

As a reminder, here is the provisional list for 2010:

...

ForeignFunctionInterface LineCommentSyntax PatternGuards DoAndIfThenElse Remove n+k patterns RelaxedDependencyAnalysis EmptyDataDeclarations HierarchicalModules NonDecreasingIndentation remove FixityResolution from the context-free grammar change the syntax of QualifiedOperators

These have already been done, so don't really need owners:

...

LineCommentSyntax DoAndIfThenElse PatternGuards

I plan to take ownership of the following:

...

HierarchicalModules change the syntax of QualifiedOperators remove FixityResolution from the context-free grammar

That leaves the following proposals needing owners:

...

ForeignFunctionInterface Remove n+k patterns RelaxedDependencyAnalysis EmptyDataDeclarations NonDecreasingIndentation

Volunteers please!

I'll volunteer for RelaxedDependencyAnalysis -- it's mostly done already.

Ok, I've put together a page on EmptyDataDecls: http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls Cheers, Stephanie

I think that a natural extension to allowing empty data declarations would be to allow empty case expressions. On Wed, Jul 29, 2009 at 7:34 PM, Stephanie Weirich wrote:

Ok, I've put together a page on EmptyDataDecls:

http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls

Cheers, Stephanie _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

So is there a volunteer to flesh out the details of a proposal? On 31/07/2009 16:53, Iavor Diatchki wrote:

+1. I completely agree.

On Fri, Jul 31, 2009 at 6:04 PM, Lennart Augustsson wrote:

...

I think that a natural extension to allowing empty data declarations would be to allow empty case expressions.

On Wed, Jul 29, 2009 at 7:34 PM, Stephanie Weirich wrote:

...

Ok, I've put together a page on EmptyDataDecls:

http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls

Cheers, Stephanie _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

I thought that the intended semantics was supposed to be that the only element is bottom (hence the proposal to add a related empty case construct)? On Thu, Aug 6, 2009 at 3:49 PM, Ross Paterson wrote:

On Wed, Jul 29, 2009 at 02:34:26PM -0400, Stephanie Weirich wrote:

...

Ok, I've put together a page on EmptyDataDecls:

http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls

I think this needs a sentence about semantics, to the effect that the type is abstract.  (Not that its only element is bottom.) _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

Ross Paterson wrote:

On Sat, Aug 08, 2009 at 10:09:38AM +0100, Iavor Diatchki wrote:

...

I thought that the intended semantics was supposed to be that the only element is bottom (hence the proposal to add a related empty case construct)?

If that were the case, a compiler could legitimately discard any value of such a type, because it could be easily reconstructed. I don't think that is what is intended.

Actually, I think it is. I think that's a natural consequence of the way Haskell is specified. GHC tries to pick the kind of bottom that you expected, but it doesn't always work really well, because it's not actually specified in any sort of formal way... Now, with imprecise exceptions, I'm not sure a compiler could legitimately discard the value. (by the way, for a type that you can unsafeCoerce anything to, GHC has a special type named "Any". Which is not the same as a data type with no constructors.) -Isaac

On Thu, Aug 20, 2009 at 01:45:08PM +0100, Simon Marlow wrote:

On 08/08/2009 10:24, Ross Paterson wrote:

...

On Sat, Aug 08, 2009 at 10:09:38AM +0100, Iavor Diatchki wrote:

...

I thought that the intended semantics was supposed to be that the only element is bottom (hence the proposal to add a related empty case construct)?

If that were the case, a compiler could legitimately discard any value of such a type, because it could be easily reconstructed. I don't think that is what is intended.

Just in case this question is still open: an empty data declaration declares a type that has exactly zero constructors, not an abstract type. What would it mean to define an abstract types? Haskell only allows one definition of any given type.

Yes, I take it back. Such types are typically used as phantom type arguments, e.g. the argument of Ptr, so the question I raised doesn't arise.

I have fleshed out the report delta for

...

remove FixityResolution from the context-free grammar

http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution Please take a look and comment. This fixes a nasty bug in the Haskell syntax - albeit one that doesn't cause problems in practice, but still. I think the changes make the grammar look nicer, and help compiler implementers by providing a sample implementation of fixity resolution. We better be sure the sample implementation is correct! I've tested it fairly well, but I wouldn't rule out corner cases being wrong, especially with prefix negation. Cheers, Simon

On 31/07/2009 14:51, Neil Mitchell wrote:

Hi

...

...

...

remove FixityResolution from the context-free grammar

http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution

Please take a look and comment. This fixes a nasty bug in the Haskell syntax - albeit one that doesn't cause problems in practice, but still. I think the changes make the grammar look nicer, and help compiler implementers by providing a sample implementation of fixity resolution.

We better be sure the sample implementation is correct! I've tested it fairly well, but I wouldn't rule out corner cases being wrong, especially with prefix negation.

The code in Resolve.hs has been used by HLint for months, and is the basis of the resolution used in haskell-src-exts 1.0.0. In that time I haven't seen any bugs with the fixity resolution.

I updated the code on the wiki page: the previous version didn't handle prefix negation - did you implement that yourself in HLint? Cheers, Simon

...

I updated the code on the wiki page: the previous version didn't handle prefix negation - did you implement that yourself in HLint?

No, I didn't implement prefix negation in HLint - it never came up as an issue. Perhaps the underlying HSE library dealt with it for me - Niklas would know.

In haskell-src-exts (and haskell-src, since that's inherited), unary minus binds tighter than any infix operator:

exp0b :: { PExp } : exp0b qop exp10b { InfixApp $1 $2 $3 } | dvarexp { $1 } | exp10b { $1 }

exp10b :: { PExp } : 'case' exp 'of' altslist { Case $2 $4 } | '-' fexp { NegApp $2 } | 'do' stmtlist { Do $2 } | 'mdo' stmtlist { MDo $2 } | fexp { $1 }

It has never come up as a problem. Guess that's a point in case for getting rid of unary minus as an operator. :-) Cheers, /Niklas

Don Stewart wrote:

Tom Lokhorst suggests[1]

Haskell'10

[1] http://twitter.com/tomlokhorst/statuses/2539313506

How pessimistic. Some people expect Haskell and/or Haskell' not to be around anymore in 2110? Wolfram