March 2006 - Haskell-prime

RE: important news: refocusing discussion
by Simon Marlow 24 Mar '06

24 Mar '06

On 24 March 2006 09:55, Ross Paterson wrote: > Do you envisage Haskell' implementations that do not support > concurrency? Clearly there will be some, the question is what status do they have. It boils down to a choice between: (1) Haskell' does not include concurrency. Concurrent programs are not Haskell'. (2) Haskell' includes concurrency. Concurrent programs are Haskell', but there are some compilers that do not implement all of Haskell'. (3) There are two variants of Haskell', Haskell' and Haskell'+Concurrency. Compilers and programs choose which variant of the language they implement/are implemented in. (4) The same as (3), but the two variants are Haskell' and Haskell'-Concurrency (where -Concurrency is a negative addendum, an addendum that subtracts from the standard). I suspect that almost everyone agrees that (1) is not an option. In practical terms, there isn't much to choose between the others: from a programmer's point of view, if they want to use concurrency they still have to choose an implementation that supports it. So I believe the issue is mainly one of perspective. Until I wrote this email I hadn't thought of (4) and my preference was for (2), but now I quite like the idea of (4). We would include concurrency in Haskell', but provide a separate addendum that specifies how imlementations that don't provide concurrency should behave. One advantage of (4) over (3) is that we can unambiguously claim that Haskell' has concurrencey. This also lets us accommodate John Meacham's earlier point, that it should be possible to write concurrency-safe libraries in a portable way, and that means providing parts of Control.Concurrent even in the absence of concurrency. For example, MVars would be provided with an implementation in terms of IORefs. Cheers, Simon

3 2

Re: Strict tuples
by Wolfgang Jeltsch 23 Mar '06

23 Mar '06

Am Dienstag, 21. März 2006 11:28 schrieb Bulat Ziganshin: > [...] > as i said, shebang patterns allow only to specify that IMPLEMENTATION > of some function is strict. this helps only when this function are > called directly. they can't help when function is passed as parameter > or enclosed in data structure or a part of class. the same about > datatypes - i can't declare what some algorithm works only with > strict lists. i try to find extensions what will allow to specify > strictness in every case where now we forced to use lazy computations > > the concrete syntax what i propose may be wrong Well, it's probably nice sometimes to have types which guarantee the strictness of certain components. For example, it might be good to have a list type where the strictness of the elements is guaranteed. But I'm sure that it's wrong to try to achieve this by annotating type arguments like in [!a]. I think, this approach is wrong, not just the syntax. Best wishes, Wolfgang

2 2

seq as a class method
by Wolfgang Jeltsch 23 Mar '06

23 Mar '06

Hello, it seems that there is not yet a ticket about putting seq into a type class (again). In my opinion, having seq available for every type is a serious flaw. One problem is that the law f = \x -> f x doesn't hold anymore since the equation is false for f = _|_. There was also a discussion on one of the mailing lists some time ago which revealed that the Monad instance for IO doesn't satisfy the monad laws because of the availability of seq for IO, I think. In addition, the automatic definition of seq for every type can make implementation details visible which were thought of as completely hidden. For example, it might make a difference whether one uses data or newtype for a one-alternative-one-field datatype, even if the data constructor is hidden. I therefore propose to declare a class like this: class Seq a where seq :: a -> b -> b (Perhaps the class name should be chosen better.) Generation of standard instances should be supported via deriving clauses or Template Haskell. For an algebraic datatype declared via data T a1 ... an = C1 t11 ... t1m1 | ... | Ck tk1 ... tkmk the implementation of seq should be something like this: seq (C1 _ ... _) = id seq _ = id What do others think? Best wishes, Wolfgang

1 0

RE: Strict tuples
by Simon Marlow 23 Mar '06

23 Mar '06

On 23 March 2006 02:24, Ben Rudiak-Gould wrote: > Bulat Ziganshin wrote: >> Taral wrote: >>> I don't see that more optimization follows from the availability >>> of information regarding the strictness of a function result's >>> subcomponents. >> >> ghc uses unboxed tuples just for such sort of optimizations. instead >> of returning possibly-unevaluated pair with possibly-unevaluated >> elements it just return, say, two doubles in registers - a huge win > > Mmm, not quite. Unboxed tuples are boxed tuples restricted such that > they never have to be stored on the heap, but this has no effect on > semantics at all. A function returning (# Double,Double #) may still > return two thunks. Yes, this is why the unboxed 1-tuple makes sense :-) indexArray# :: Array# a -> Int# -> (# a #) Cheers, Simon

1 0

Ticket #15: add a binary IO interface
by Bulat Ziganshin 23 Mar '06

23 Mar '06

Hello , about this - i'm almost sure that current widely used libraries (NewBinary) is not as good as my own one (http://freearc.narod.ru/Streams.tar.gz) is not ever used and even still not documented, so it is not easy to make right choice :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 1

Strict tuples
by Manuel M T Chakravarty 23 Mar '06

23 Mar '06

Loosely related to Ticket #76 (Bang Patterns) is the question of whether we want the language to include strict tuples. It is related to bang patterns, because its sole motivation is to simplify enforcing strictness for some computations. Its about empowering the programmer to choose between laziness and strictness where they deem that necessary without forcing them to completely re-arrange sub-expressions (as seq does). So what are strict tupples? If a lazy pair is defined in pseudo code as data (a, b) = (a, b) a strict pair would be defined as data (!a, b!) = ( !a, !b ) Ie, a strict tuple is enclosed by bang parenthesis (! ... !). The use of the ! on the rhs are just the already standard strict data type fields. Why strict tuples, but not strict lists and strict Maybe and so on? Tuples are the Haskell choice of returning more than one result from a function. So, if I write add x y = x + y the caller gets an evaluated result. However, if I write addmul x y = (x + y, x * y) the caller gets a pair of two unevaluated results. Even with bang patterns, I still have to write addmul x y = let !s = x + y; !p = x * y in (s, p) to have both results evaluated. With strict tuples addmul x y = (!x + y, x * y!) suffices. Of course, the caller could invoke addmul using a bang patterns, as in let ( !s, !p ) = addmul x y in ... but that's quite different to statically knowing (from the type) that the two results of addmul will already be evaluated. The latter leaves room for more optimisations. Syntax issues ~~~~~~~~~~~~~ * In Haskell (,) is the pair constructor. What should be use for strict tuples? (!,!) ? * With strict tuples (! and !) would become some sort of reserved/special symbol. That interferes with bang patterns, as (!x, y!) would be tokenized as (! x , y !). We could use ( ... !) for strict tuples to avoid that conflict, or just requires that the user write ( !x, !y ) when they want a bang pattern. (Just like you cannot write `Just.x' to mean `Just . x' as the former will always be read as a qualified name and not the application of function composition. Bang patterns enable the programmer (among other things) to define functions with strict arguments. Strict tuples enable to define strict results. Manuel PS: IIRC Clean supports strict tuples.

6 12

RE: Strict tuples
by Simon Marlow 23 Mar '06

23 Mar '06

On 19 March 2006 02:35, Manuel M T Chakravarty wrote: > Loosely related to Ticket #76 (Bang Patterns) is the question of > whether we want the language to include strict tuples. It is related > to bang patterns, because its sole motivation is to simplify enforcing > strictness for some computations. Its about empowering the programmer > to choose between laziness and strictness where they deem that > necessary without forcing them to completely re-arrange > sub-expressions (as seq does). > > So what are strict tupples? If a lazy pair is defined in pseudo code > as > > data (a, b) = (a, b) > > a strict pair would be defined as > > data (!a, b!) = ( !a, !b ) > > Ie, a strict tuple is enclosed by bang parenthesis (! ... !). The use > of the ! on the rhs are just the already standard strict data type > fields. > > Why strict tuples, but not strict lists and strict Maybe and so on? > Tuples are the Haskell choice of returning more than one result from a > function. So, if I write > > add x y = x + y > > the caller gets an evaluated result. However, if I write > > addmul x y = (x + y, x * y) > > the caller gets a pair of two unevaluated results. Even with bang > patterns, I still have to write > > addmul x y = let !s = x + y; !p = x * y in (s, p) > > to have both results evaluated. With strict tuples > > addmul x y = (!x + y, x * y!) > > suffices. > > Of course, the caller could invoke addmul using a bang patterns, as in > > let ( !s, !p ) = addmul x y > in ... > > but that's quite different to statically knowing (from the type) that > the two results of addmul will already be evaluated. The latter > leaves room for more optimisations. > > Syntax issues > ~~~~~~~~~~~~~ > * In Haskell (,) is the pair constructor. What should be use for > strict tuples? (!,!) ? > * With strict tuples (! and !) would become some sort of > reserved/special symbol. That interferes with bang patterns, as > (!x, y!) would be tokenized as (! x , y !). We could use ( ... !) > for strict tuples to avoid that conflict, or just requires that the > user write ( !x, !y ) when they want a bang pattern. (Just like you > cannot write `Just.x' to mean `Just . x' as the former will always > be read as a qualified name and not the application of function > composition. Not to mention overlap with sections: (!i). Even with just bang patterns, we have some interesting parsing problems due to the overlap with infix '!'. eg., now arr ! x = indexArray arr x will probably parse as arr (!x) = indexArray arr x which means that in order to define (!) you have to use the prefix form: (!) arr x = ... GHC's implementation of bang pattern parsing has some ugliness to deal with this. In the report, we will have to be very careful to make sure the syntax doesn't have any ambiguities in this area, which will probably mean adding special cases to the grammar. My suggestion is to avoid these problems by removing infix '!' from the syntax: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/ArrayIndex ing I realise this is a code-breaking change, but I consider the special cases introduced to the syntax by bang patterns to be rather warty. Also, since I think many of us envisage Haskell moving towards having more strictness annotations in the future, it makes sense to consistently use the '!' operator to mean "strict". Cheers, Simon

4 5

MonadPlus Reform
by Ashley Yakeley 22 Mar '06

22 Mar '06

Does this come under the "standard libraries" topic? I would like to see the MonadPlus class disambiguated: class Monad m => MonadZero m where mzero :: m a class MonadZero m => MonadPlus m where mplus :: m a -> m a -> m a class MonadZero m => MonadOr m where morelse :: m a -> m a -> m a <http://haskell.org/haskellwiki/MonadPlus_reform_proposal> -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/

2 1

RE: Strict tuples
by John Hughes 22 Mar '06

22 Mar '06

<>From: "Simon Marlow" <simonmar(a)microsoft.com> <>After some thought, I find myself with a similar view to John. Strict <>tuples are starting to feel like real language bloat, one tiny addition <>too much. <> <>Remember, every addition we make to the core syntax is multiplied by all <>the parsers for Haskell and tools that have to grok Haskell, and make <>the bar ever-so-slightly higher to producing such tools. There's a <>reason that syntax ends in "tax" :-) <> <> Not to mention all the brains that have to learn it. It seems to me the gain is small, considering how easy it is to do already. <>By all means have strict tuples in a library somewhere. They don't need <>to have special syntax. <> <> Agreed. John

1 0

Time Library
by Ashley Yakeley 22 Mar '06

22 Mar '06

I propose the following for Haskell': 1. Adding my Data.Fixed module to the base package. <http://semantic.org/TimeLib/doc/html/Data-Fixed.html> <http://darcs.haskell.org/packages/time/fixed/Data/Fixed.hs> 2. Adding my package "time" to the standard libraries. <http://semantic.org/TimeLib/doc/html/> <http://darcs.haskell.org/packages/time/> 3. Deprecating System.Time. http://haskell.org/ghc/dist/current/docs/libraries/base/System-Time.html I'm not sure what form deprecating takes. If this is OK, I'll create a ticket for it, and also make these changes in darcs and get it working with default-packages. More info: <http://semantic.org/TimeLib/> -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/

2 5