February 2006 - Haskell-prime

comment on: Make underscore 'caseless' (Ticket 72)
by Johannes Waldmann 03 Feb '06

03 Feb '06

http://hackage.haskell.org/trac/haskell-prime/wiki/Underscore I think it is basically the wrong idea to encode (type and) usage information in the name of an identifier. One should use the type system for that, or, failing that, annotations. Something like data Foo = Foo | @SuppressWarnings("unused") Bar See my proposal for unified and extendible annotations http://www.haskell.org//pipermail/haskell-prime/2006-February/000279.html http://java.sun.com/docs/books/tutorial/java/javaOO/annotations.html Of course compilers/IDEs are free to support whatever naming conventions they want but I think such conventions should not go into the language standard. Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

1 0

Unicode, was Comment Syntax
by Taral 03 Feb '06

03 Feb '06

On 2/2/06, John Meacham <john(a)repetae.net> wrote: > but it currently doesn't recognize any unicode characters as possible > operators. which it should, but I am just not sure how to specify that > yet until some sort of standard develops. Once there are more unicode > compliant compilers out there something will evolve probably. Character attributes are defined in unicode: http://www.unicode.org/Public/UNIDATA/ It's just a matter of mapping. Perhaps this is worth considering amending for Haskell'? The Haskell98 grammar talks about "symbol", "uppercase", "lowercase", while Unicode is a bit more... diverse. -- Taral <taralx(a)gmail.com> "Computer science is no more about computers than astronomy is about telescopes." -- Edsger Dijkstra

1 0

Specifying language extensions
by Patryk Zadarnowski 03 Feb '06

03 Feb '06

One issue that pains me with Haskell 98 is that it does nothing about one of its original stated goals as a programming language. I've always been very fond of pointing out that Haskell has been designed as a language for EXPERIMENTATION with language features, and therefore the mind-boggling number of extensions in GHC is a good thing, not a bad one. This will NOT change with Haskell' - we already know that at least one language feature which is in high demand (functional dependencies) is far from ready for standardization. However, the language, at the current point, does nothing towards helping with keeping track of the language extensions in use by a particular piece of code. To make things worse, many extension require lexical and/or syntactic changes to the language. Some extensions in the past proved to be incompatible, and not all compilers implement all extensions. So, looking at a particular piece of code, how do we know which compiler it can be compiled with, and which command-line flags do we pass to which compiler? The answer is, simply, we don't. Currently, we do this by introducing ugly GHC-specific pragmas, comments in the documentation, and a plethora of similar half-measures. I would like to propose a language feature to address this concern once and for all. I know that a similar proposal has been circulated on the haskell mailing list in the past, but to the best of my knowledge, none of the current tickets addresses this problem. The proposal: Add explicit syntax for documenting language extensions required by a module. The Problem: * Current language does not provide a uniform extension mechanism. * Pragmas (as currently used in GHC) are NOT suitable for this. Specifically, by their design they are COMMENTS, and therefore should have no impact on the language semantics. Unrecognized pragmas should be ignorable without warnings, while, currently, if you omit the GHC options pragma for a module that requires some syntactic extension, you will receive thousands of lexical and syntactic errors completely unrelated to your extension. * I /strongly/ believe that compiler pragmas should ONLY be used for extensions (such as INLINE, various SPECIALIZE, etc.) that have no impact on the program semantics. The Solution: Add an "extension" clause to the language. To avoid introduction of a new keyword, I propose to use the following syntax: module -> [extensions;] "module" modid [exports] "where" body | body extensions -> extension_1 ; ... ; extension_n extension -> "import" "extension" varid [extparam_1 ... extparam_n] extparam -> varid | conid | literal A module using some GHC woo-hah extension would look like: import extension GHC "woo-hah!" module Foo ... Or, if an extension is common enough: import extension fundeps module Foo ... This is a very conservative syntax. It does not support grouping, aliasing and renaming of extensions (as previously circulated on the haskell mailing list) which I personally believe would be very a bad idea. I want to be able to look at a piece of Haskell code and tell immediately which extensions it uses, without being forced to browse through the included modules, etc. Extensions would NOT be exported by a module that uses that extension, but would have to be specified separately by each module that uses the features provided by that extension. For example, one often hides uses of unboxed types, functional dependencies, etc, behind a curtain of abstract data types, and such data type implemented using non-standard features can be happily used within standard-conforming Haskell programs. On the other hand, if an extension is visible in an interface exported by a module, it has to be named explicitly (with "import extension" clauses) by any module importing that interface. Extensions could be parametized, since I can readily imagine extensions that would require such a thing. I would also recommend in the standard that every compiler groups its own extensions under a common name (for example, GHC, HUGS, JHC, NHC, etc.) until they are in sufficiently common use to be standardized independently (such as fundeps), at which stage there should probably be a corresponding addendum to the standard for that extension. Specifying extensions before the "module" keyword ensures that the lexer and parser can find them before parsing of the actual module. I recommend that bare modules without the "module" keyword cannot specify any extensions, and therefore must be written in pure Haskell'. The standard itself should not define any extensions and state that the standard grammar and semantics describes the base language in absence of any "import extension" clauses. Each extension, including FFI, should be described in a separate addendum. Pros: * Addresses a pending language design goal. * Useful for automatic documentation tools such as Haddock, which could even generate a hyperlink from an extension name to the relevant addendum when available. * Simple to implement. * Neat syntax. * Backwards-compatible (introduces no keyword polution.) * Makes all information required to compile a program available directly in the source code, rather than in ad-hoc places such as command- line, Cabal package descriptions, documentation, comments, pragmas and what-not. * Returns all comments (including pragmas) to their original code as semantically-neutral annotations on the source program. Cons: * Some implementation hassles. The compiler must use either a predicated parser and lexer (I believe most do already) or else parse the module until it finds the "module" keyword collecting the extension clauses, and then parse the actual module using an appropriate parser and lexer chosen according to the specified extensions. What do people think? I would like to throw the idea around on the mailing list before entering it into the ticket system. Cheers, Pat.

2 2

RE: separate class and type namespace
by Simon Marlow 02 Feb '06

02 Feb '06

On 31 January 2006 03:42, John Meacham wrote: > What do people think about seperating the class and type namespaces? > one can always tell the difference syntactically which is meant, the > only > thing keeping them in the same space in jhc is an artificial check to > ensure you don't create some of the same name. > > the only issue is in export/import lists if you wanted to allow > import/export of the type independently of the class. however the > proposed explicit namespace change to the import/export syntax would > solve this too and it is unlikely to actually be a problem in > practice. I've always liked the idea of saying 'class C' or 'type T' in import/export lists. It could be made backwards compatible: we allow types and classes to be named the same, but in this case the export list has to use the new syntax to disambiguate. The idea would be to transition to the new syntax eventually. There's a choice about whether a newtype should be exported with 'newtype T' or 'data T', or either. Cheers, Simon

8 7

Library Reform
by Ashley Yakeley 02 Feb '06

02 Feb '06

If Haskell Prime is going to have certain type extensions rolled in, can we make changes to the standard libraries that take advantage of these? -- Ashley Yakeley

2 1

RE: Test performance impact (was: The dreaded M-R)
by Simon Marlow 02 Feb '06

02 Feb '06

On 02 February 2006 09:52, John Hughes wrote: > Summary: 2 programs failed to compile due to type errors (anna, gg). > One program did 19% more allocation, a few other programs increased > allocation very slightly (<2%). > > pic +0.28% +19.27% 0.02 > > > > Thanks, that was interesting. A follow-up question: pic has a space > bug. How long will it take you to find and fix it? I just tried this, and it took me just a few minutes. Compiling both versions with profiling, for the original: total time = 0.00 secs (0 ticks @ 20 ms) total alloc = 11,200,656 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc chargeDensity ChargeDensity 0.0 2.5 accumCharge ChargeDensity 0.0 13.5 relax Potential 0.0 31.4 correct Potential 0.0 5.0 genRand Utils 0.0 1.0 fineMesh Utils 0.0 2.4 applyOpToMesh Utils 0.0 12.7 =: Utils 0.0 2.3 pushParticle PushParticle 0.0 16.1 timeStep Pic 0.0 11.0 and with the monomorphism restriction turned off: total time = 0.02 secs (1 ticks @ 20 ms) total alloc = 12,893,544 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc pushParticle PushParticle 100.0 20.8 chargeDensity ChargeDensity 0.0 2.2 accumCharge ChargeDensity 0.0 18.0 relax Potential 0.0 27.3 correct Potential 0.0 4.4 fineMesh Utils 0.0 2.1 applyOpToMesh Utils 0.0 11.1 =: Utils 0.0 2.0 timeStep Pic 0.0 9.5 So, ignoring the %time column (the program didn't run long enough for the profiler to get enough time samples), we can see the following functions increased their allocation as a % of the total: pushParticle, accumCharge Looking at the code for accumCharge: accumCharge :: [Position] -> [MeshAssoc] accumCharge [] = [] accumCharge ((x,y):xys) = [((i ,j ) , charge * (1-dx) * (1-dy))] ++ [((i',j ) , charge * dx * (1-dy))] ++ [((i ,j') , charge * (1-dx) * dy)] ++ [((i',j') , charge * dx * dy)] ++ accumCharge xys where i = truncate x i' = (i+1) `rem` nCell j = truncate y j' = (j+1) `rem` nCell dx = x - fromIntegral i dy = y - fromIntegral j Now, because I know what I'm looking for, I can pretty quickly spot the problem. I had to look at the definition of MeshAssoc to figure out that the result type of this function forces i to have type Int, yet it is used elsewhere as the argument to fromIntegral, where if i is overloaded will be defaulted to Integer. When I give type signatures to i and j (:: Int), the allocation reduces. The pushParticle function has an identical pattern. Fixing these two functions brought the performance back to the original. But I've also changed the semantics - the author might have *wanted* i at type Integer in the definition of dx to avoid overflow, and the monomorphism restriction had prevented it. I suppose you could ask how you'd find the problem if you didn't know what to look for. So I added some more annotations: i = {-# SCC "i" #-} truncate x i' = {-# SCC "i'" #-} (i+1) `rem` nCell j = {-# SCC "j" #-} truncate y j' = {-# SCC "j'" #-} (j+1) `rem` nCell dx = {-# SCC "dx" #-} x - fromIntegral i dy = {-# SCC "dy" #-} y - fromIntegral j and the profiling output shows: i ChargeDensity 100.0 6.8 j ChargeDensity 0.0 6.8 chargeDensity ChargeDensity 0.0 2.2 accumCharge ChargeDensity 0.0 3.9 relax Potential 0.0 27.2 ... So this pretty clearly identifies the problem area (although the figures don't quite add up, I suspect the insertion of the annotations has affected optimisation in some way). Still, you could argue that it doesn't actually tell you the cause of the problem: namely that i&j are being evaluated twice as often as you might expect by looking at the code. This is what the compiler warning would do, and I completely agree that not having this property evident by looking at the source code is a serious shortcoming. > And how come speed > improved slightly in many cases--that seems counter- intuitive. The runtimes are unreliable, due to the short runnning time of most of these benchmarks. We have a "slow" mode for the benchmark suite that runs each program with larger test data, but I didn't use it this time - mostly we find that measuring allocations is useful as a first approximation, and it's certainly more reliable. (rest of email snipped, most of which I agree with). Cheers, Simon

2 1

RE: Haskell-prime Digest, Vol 2, Issue 6
by Simon Peyton-Jones 02 Feb '06

02 Feb '06

| We didn't dare include MPTCs in Haskell 98 because the number one goal | on that occasion was to be conservative! But if we had taken that view when | Haskell was first designed, classes would never have seen the light of | day at all. I think now is the time to bite this bullet. I'm all for biting, but I'm not sure that the timescale is compatible with finishing by mid 2006. I think the right way to bite is to use associated types and they are simply too untried for Haskell'. Now, someone can try to define a conservative version of FDs, as has been suggested; perhaps it could even be kind-of-isomorphic to associated types. Perhaps something *very* conservative would be enough for most applications. (It would hurt to standardise FDs if we think we're going to discard them subsequently, but if the spec was somewhat crisp maybe it would not hurt too much.) I'd be happy to help review such a specification, but I don't want to write it. And I think it must be at least somewhat formal. (Karl-Fillip Faxen's paper on the static semantics of Haskell would be a good starting point, and the paper that I mentioned earlier.) Simon

1 0

Re: Haskell-prime Digest, Vol 2, Issue 6
by John Hughes 02 Feb '06

02 Feb '06

>From: Henrik Nilsson <nhn(a)Cs.Nott.AC.UK> >Subject: Re: MPTCs and functional dependencies > > >Simon PJ wrote: > > > Multi-parameter type classes, yes. Functional dependencies, no. > >My experience is that even with very simple applications of MPTCs, >I often end up needing functional dependencies to make things work. > >Thus, if my hunch is right, and other people have a similar experience, >my fear would be that omitting FDs or something similar would result >in a Haskell' standard that ends up being out of date even before it is >finalised, in that a large number of real world applications and >libraries would fail to be standard compliant and could not easily >be adapted to be. > > > I second that. For example, my survey showed that the monadic combinators in Control.Monad.* are quite heavily used. These libraries define three two-parameter classes (MonadError, MonadReader, and MonadWriter). ALL of them use functional dependencies. I remember trying to program this kind of library before the days of FDs--the result was worthless, because of all the ambiguities I got whenever I tried to use it. Adding MPTCs without *some* form of FDs (and I'm including the associated types stuff there) would guarantee a broken language from the start. I agree this needs work--in my view, some of the most important work to be done in defining Haskell'. We need something simple enough to standardize, which is at the same time powerful enough to handle the applications we already have. We didn't dare include MPTCs in Haskell 98 because the number one goal on that occasion was to be conservative! But if we had taken that view when Haskell was first designed, classes would never have seen the light of day at all. I think now is the time to bite this bullet. John

1 0

Wanted: local data, class, instance declarations
by Johannes Waldmann 02 Feb '06

02 Feb '06

in today's Haskell, all data and instance declarations are global, which sometimes leads to violations of the information hiding principle. E. g. if there is a function sort :: Ord a => [a] -> [a], and I want to sort a list of items w.r.t. a specified ordering, then I would want to write let instance Ord Item where ... xs :: [ Item ] ; xs = ... in sort xs but I don't want to make the instance Ord Item global because I might need a different instance in another place, or there already is a global instance but I don't want it. So, the local instance should override an outer or global one. Shouldn't be too difficult, the compiler just has to insert the proper dictionary (the "most local" one that's visible at the call site). With current all-global instances, a sort function of the given type is not very flexible, leading to supplementary functions (sortBy), see "Generalized functions" e. g. in http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html#22 This is exactly a work-around for not being able to make local dictionaries, right? Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

4 5

CHRs, was Re: MPTCs and functional dependencies
by Jim Apple 02 Feb '06

02 Feb '06

> ... read the JFP journal submission that Martin Sulzmann and Peter > Stuckey and I have been working on. > http://research.microsoft.com/%7Esimonpj/papers/fd-chr Has this list discussed using CHRs instead of fundeps? Jim

1 0