- Haskell-prime - Haskell.org

fixity resolution
by Christian Maeder 15 Jul '10

15 Jul '10

http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch10.ht… "Fixity resolution also applies to Haskell patterns, but patterns are a subset of expressions so in what follows we consider only expressions for simplicity." The string "1 * - 1" is legal as pattern, but rejected as expression! Furthermore fixity resolution does not distinguish between constructors and other operators as it should according to the grammar: pat → lpat qconop pat (infix constructor) | lpat funlhs → var apat { apat } | pat varop pat | ( funlhs ) apat { apat } "a : b * c : d = undefined" is currently rejected with: "cannot mix `:' [infixr 5] and `Main.*' [infixl 9] in the same infix expression" but should be fine by the given grammar (rule "pat varop pat"). Cheers Christian P.S. like in my proposal for infixexp I would change pat to: pat → pat qconop pat (infix constructor) | lpat for the sake of a better presentation only.

6 20

Re: ANNOUNCE: Haskell 2010 Report (final)
by Christian Maeder 12 Jul '10

12 Jul '10

Simon Marlow schrieb: > PS. don't forget there will be a new revision of Haskell this year, and > time is getting short to submit proposals. For instructions on getting > involved, see > > http://hackage.haskell.org/trac/haskell-prime In fact, I want to make a proposal "PrefixMinusResolution" as described in http://www.haskell.org/pipermail/haskell-prime/2010-July/003229.html related to http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution http://hackage.haskell.org/trac/haskell-prime/ticket/30 but I could not create a wiki page or ticket. (I registered and verified as "maeder") Christian

1 0

Second draft of the Haskell 2010 report available
by Simon Marlow 08 Jul '10

08 Jul '10

The second draft of the Haskell 2010 report is now available in PDF and HTML formats (the PDF looks a lot nicer): http://www.haskell.org/~simonmar/haskell-2010-draft-report-2.pdf http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskell.html relative to the first draft, which was only publicised on the haskell-prime mailing list, I have now updated the libraries too. Rather than update all the library documentation manually, I (perhaps rashly) decided to make a LaTeX backend for Haddock instead, and generate the report automatically from the library source code. Getting this to work turned out to be a lot more effort than I anticipated, but I think the results are quite attractive. Once the new Haddock backend is incorporated upstream, we'll finally have the ability to generate decent typeset API documentation. Furthermore, this should make it much easier to incorporate more libraries in future versions of the Haskell standard, should we decide to do so. Right now, the HTML version of the report is generated from the LaTeX sources, including the libraries. We could use the Haddock HTML output instead, but that would entail some difficulties with cross-references from the language part of the report to the libraries, which is why I've left it this way for now. This is why the libraries part of the report is bereft of hyperlinks in HTML; but at least it is well indexed in the PDF version. Summary of the library changes in Haskell 2010 relative to Haskell 98 and the FFI specification: * All libraries have been updated to their hierarchical names * The following library modules were dropped from the standard, due to being obsolete or superseded. Replacements are not part of the standard yet, but it is expected that they will be replaced in the future: Directory, System, Time, Locale, CPUTime, Random In the case of System, some functions have moved to the new modules System.Environment and System.Exit. * Foreign.Marshal.Error: functions on IOError moved to System.Error (this is where they've been in base for ever). * Data.List: added intercalate, subsequences, permutations, foldl', foldl1', stripPrefix (H2010 Data.List matches the current base version). * Data.Char: various additions of Unicode predicates (e.g. isLetter, isMark, isNumber), the GeneralCategory type and generalCategory. (matches the base version) * Control.Monad: added forM, forM_, (>=>), (<=<), forever, foldM_, replicateM, replicateM_ (matches the base version). * System.IO: added fixIO, hSetFileSize, hTell, hIsTerminalDevice, hSetEcho, hGetEcho, hShow. The base version has various additions: hGetBuf/hPutBuf, binary Handles, encodings, and newline support, but I erred on the side of being conservative here: these APIs need discussion, and in some cases are probably not suitable for the standard in their current state at all. * System.IO.Error: new module, providing functionality that was in Foreign.Marshal.Error in the FFI spec. * System.IO.Exit: new module, functionality moved from H98 System * System.Environment: new module, functionality moved from H98 System We expect to provide exactly these libraries in GHC 6.14, although the exact mechanism has yet to be decided; for discussion see http://www.haskell.org/pipermail/haskell-prime/2010-April/003158.html Comments on the draft report are welcome, before I finalise this and sign off on Haskell 2010. Cheers, Simon

7 16

Re: [Haskell] Second draft of the Haskell 2010 report available
by Simon Marlow 30 Jun '10

30 Jun '10

On 29/06/2010 23:31, Henk-Jan van Tuyl wrote: > On Tue, 29 Jun 2010 17:01:54 +0200, Simon Marlow <marlowsd(a)gmail.com> > wrote: > >> Comments on the draft report are welcome, before I finalise this and >> sign off on Haskell 2010. > > Subsection 12.3, "Language extensions", mentions the FFI as a language > extension, but FFI is now part of the standerd; the same goes for the > "extensions" mentioned at the end of the subsection. Thanks; changed to refer to them as "language features" rather than "extensions". Cheers, Simon

1 0

Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
by Brandon S. Allbery KF8NH 09 Jun '10

09 Jun '10

On Jun 8, 2010, at 15:32 , Job Vranish wrote: > It seems like this would make working with MPTCs much easier. > When programming, I generally want to only specify the minimum > amount of information to make my code logically unambiguous. > If the code contains enough information to infer the proper > instantiation without the use of an FD, then I shouldn't need to add > a FD. > It seems like this would have much more of a "it just works" feel > than the currently alternatives. I can't help but think that the "it just works" mentality leads to duck typing. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery(a)kf8nh.com system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

1 0

Proposal to solve Haskell's MPTC dilemma
by Carlos Camarao 31 May '10

31 May '10

This message, sent a few days ago to haskell-cafe, presents, informally, a proposal to solve Haskell's MPTC (multi-parameter type class) dilemma. If this informal proposal turns out to be acceptable, we (I am a volunteer) can proceed and make a concrete proposal. The discussion in haskell-cafe started well, involving a discussion related to module fragility (changes to type-correctness after a change in imported modules) but it is now quiet. Since there may be members of this list not in haskel-cafe, and because I'd like to hear your opinions and discuss the proposal here, as well as encourage the proposal's implementation, I am sending the message to this list also. The proposal has been published in the SBLP'2009 proceedings and is available at www.dcc.ufmg.br/~camarao/CT/solution-to-mptc-dilemma.pdf The dilemma is well-known (see e.g. hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma) www.haskell.org/ghc/dist/current/docs/html/users_guide/type-class-extension… presents a solution to the termination problem related to the introduction of MPTCs in Haskell. Neither FDs (functional dependencies) nor any other mechanism like ATs (associated types) are needed in our proposal, in order to introduce MPTCs in Haskell; the only change is in the ambiguity rule. This is explained below. The termination problem is essentially ortogonal and can be dealt with, with minor changes, as described in the web page above. Let us review the ambiguity rules used in Haskell-98 and in GHC. Haskell-98 ambiguity rule, adequate for single parameter type classes, is: a type C => T is ambiguous iff there is a type variable that occurs in C (the "context", or constraint set) but not in T (the simple, unconstrained type). For example: forall a.(Show a, Read a)=>String is ambiguous, because "a" occurs in the constraints (Show a,Read a) but not in the simple type (String). In the context of MPTCs, this rule alone is not enough. Consider, for example (Example 1): class F a b where f:: a->b class O a where o:: a and k = f o:: (F a b,O a) => b Type forall a b. (F a b,O a) => b can be considered to be not ambiguos, since overloading resolution can be defined so that instantiation of "b" can "determine" that "a" should also be instantiated (as FD b|->a does), thus resolving the overloading. GHC, since at least version 6.8, makes significant progress towards a definition of ambiguity in the context of MPTCs; GHC 6.10.3 User’s Guide says (section 7.8.1.1): "GHC imposes the following restrictions on the constraints in a type signature. Consider the type: forall tv1..tvn (c1, ...,cn) => type. ... Each universally quantified type variable tvi must be reachable from type. A type variable a is reachable if it appears in the same constraint as either a type variable free in the type, or another reachable type variable." For example, type variable "a" in constraint (O a) in (F a b, O a)=>b above is reachable, because it appears in (F a b) (the same constraint as type variable "b", which occurs in the simple type). Our proposal is: consider unreachability not as indication of ambiguity but as a condition to trigger overloading resolution (in a similar way that FDs trigger overloading resolution): when there is at least one unreachable variable and overloading is found not to be resolved, then we have ambiguity. Overloading is resolved iff there is a unique substitution that can be used to specialize the constraint set to one, available in the current context, such that the specialized constraint does not contain unreachable type variables. (A formal definition, with full details, is in the cited SBLP'09 paper.) Consider, in Example 1, that we have a single instance of F and O, say: instance F Bool Bool where f = not instance O Bool where o = True and consider also that "k" is used as in e.g.: kb = not k According to our proposal, kb is well-typed. Its type is Bool. This occurs because (F a b, O a)=>Bool can be simplified to Bool, since there exists a single substitution that unifies the constraints with instances (F Bool Bool) and (O Bool) available in the current context, namely S = (a|->Bool,b|->Bool). As another example (Example 2), consider: {-# NoMonomorphismRestriction, MultiParameterTypeClasses #-} data Matrix = ... data Vector = ... class Mult a b c where (*):: a ! b ! c instance Mult Matrix Vector Matrix where (*) = ... instance Mult Matrix Vector Vector where (*) = ... m1:: Matrix = ... m2:: Vector = ... m3:: Vector = ... m = (m1 * m2) * m3 GHC gives the following type to m: m :: forall a, b. (Mult Matrix Vector a, Mult a Vector b) => b However, "m" cannot be used effectively in a program compiled with GHC: if we annotate m::Matrix, a type error is reported. This occurs because the type inferred for "m" includes constraints (Mult Matrix Vector a, Mult a Vector Matrix) and, with b|->Matrix, type variable "a" appears only in the constraint set, and this type is considered ambiguous. Similarly, if "m" is annotated with type Vector, the type is also considered ambiguous. There is no means of specializing type variable "a" occurring in the type of "m" to Matrix. And no FD may be used in order to achieve such specialization, because we do not have here a FD: "a" and "b" do not determine "c" in class Mult: for (a,b = Matrix,Vector), we can have "c" equal to either Matrix or Vector. According to our proposal, type m:: forall a. (Mult Matrix Vector a, Mult a Vector Matrix)) => Matrix is not ambiguous, in the context of the class and instance declarations of Example 2 (since "a" can be instantiated to Matrix), whereas type m:: forall a.(Mult Matrix Vector a, Mult a Vector Matrix)) => Vector is ambiguous in this context. What do you think? Cheers, Carlos

3 8

Re: Haskell 2010 draft report
by Ben 06 May '10

06 May '10

a quick question -- i'm assuming that maintaining two versions is out? this is what they do with python 2.7 and 3.1 (and a variety of other systems, like BSD.) it seems like making one version of the system work against two specifications is hard; of course, maintaining two separate systems is also hard. ben

2 1

Haskell 2010 draft report
by Simon Marlow 04 May '10

04 May '10

I've completed most of the edits to the Haskell 98 report for Haskell 2010, modulo the changes to the libraries that we still have to resolve. I cleaned up various other things I discovered along the way, and tidied up the typesetting. I've also made a much nicer HTML rendering of the report using TeX4ht, which means we can ditch the old 1500 lines of hacked up Haskell code which used to do the HTML conversion before. You can see the draft report here, in PDF and online HTML respectively: http://www.haskell.org/~simonmar/haskell-2010-draft-report.pdf http://www.haskell.org/~simonmar/haskell-2010-draft-report/haskell.html In the PDF you'll notice that the bits that changed in Haskell 2010 relative to Haskell 98 are purple (except for the FFI chapter). Unfortunately I haven't yet managed to make this work in the HTML version, but it ought to be possible. I'd appreciate a few more eyes over this, in particular look out for messed up typesetting as there could still be a few bugs lurking. The source repo (darcs) is here: http://darcs.haskell.org/haskell2010-report Cheers, Simon

4 9

Haskell 2010 libraries
by Simon Marlow 04 May '10

04 May '10

Hi Folks, I'm editing the Haskell 2010 report right now, and trying to decide what to do about the libraries. During the Haskell 2010 process the committee agreed that the libraries in the report should be updated, using the current hierarchical names, adding new functionality from the current base package, and dropping some of the H'98 library modules that now have better alternatives. In Haskell 2010 we're also adding the FFI modules. The FFI addendum used non-hierarchical names (CForeign, MarshalAlloc etc.) but these are usually known by their hierarchical names nowadays: e.g. Foreign.C, Foreign.Marshal.Alloc. It would seem strange to add the non-hierarchical names to the Haskell language report. So this is all fine from the point of view of the Haskell report - I can certainly update the report to use the hierarchical module names, but that presents us with one or two problems in the implementation. The obvious thing to do would be to make a haskell2010 package that re-exports the appropriate modules from base, providing a fixed API that people can depend on when they write Haskell 2010 code. However, what happens when someone wants to write some code that uses Haskell 2010 libraries, but also uses something else from base, say Control.Concurrent? The modules from haskell2010 overlap with those from base, so all the imports of Haskell 2010 modules will be ambiguous. The Prelude is a bit of a thorny issue too: currently it is in base, but we would have to move it to haskell2010. Bear in mind these goals: we want to a. support writing code that is Haskell 2010 only: it only uses Haskell 2010 language features and modules. b. not break existing code as far as possible c. whatever we do should extend smoothly when H'2011 makes further changes, and so on. Here are some non-options: 1. Not have a haskell2010 package. We lose (a) above, and we lose the ability to add or change the API for these modules, in base, since they have to conform to the H'2010 spec. If H'2011 makes any changes to these modules, we're really stuck. 2. As described above: you can either use haskell2010, or base, but not both. It would be painful to use haskell2010 in GHCi, none of the base modules would be available. Here are some options: 3. allow packages to shadow each other, so haskell2010 shadows base. This is a tantalising possibility, but I don't have any idea what it would look like, e.g. should the client or the package provider specify shadowing? 4. Provide a haskell2010 package and a base2010 package that re-exports all of base except the modules that overlap with haskell2010. You can either use haskell2010, haskell2010+base2010, or base. This is a bit like (1), but avoids the need for shadowing by using package re-exports, on the other hand confusion could well arise due to the strange base2010 package, and some people would surely try to use haskell2010 + base and run into difficulties. 5. Not have a haskell2010 package, but have the report say that implementations are allowed to add things to the standard libraries. Thoughts? Better ideas? Cheers, Simon

9 15

Re: Haskell 2010 libraries
by Simon Marlow 01 May '10

01 May '10

On 30/04/10 23:52, Felipe Lessa wrote: > On Fri, Apr 30, 2010 at 09:37:39PM +0100, Simon Marlow wrote: >> I like the picture where we have a small base, lots of independent >> packages, and one or more haskell20xx packages that re-exports all >> the standardised stuff from the other packages. This arrangement >> extends smoothly, the only problem is that haskell20xx overlaps with >> the other packages. > > I wonder how much pain will there be when Haskell 2011 comes out. > Some packages will depend on haskell2010, and others on > haskell2011. Will they integrate and compile fine? > > If haskell2010 is a metapackage that says > > Depends: base == X.Y.* > > and haskell2011 is another metapackage that says > > Depends: base == Z.W.* > > then I think we're going to have big problems. Sorry if this is > a resolved issue. :) That won't be a problem, for the same reasons that we can happily mix packages that depend on base-3 with packages that depend on base-4 right now. That is, unless Haskell 2011 decides to make some incompatible changes to datatypes or classes, as Ian pointed out. Cheers, Simon

1 0