February 2011 - Haskell-prime

Announce: ~Haskell 2011
by Malcolm Wallace 14 Apr '11

14 Apr '11

The Haskell Language committee has had a quiet year. Following the announcement of Haskell 2010 in Nov 2009 [1], and the publication of the 2010 Report in July 2010 [2], we found a distinct lack of complete new proposals to decide upon. As a result, the committee has made the following decisions: (a) we wish to accept the NoDatatypeContexts proposal http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts (b) this delta will be applied to the 2010 Report to form a new baseline; (c) we will _not_ issue a new language standard called 2011; (d) we intend to issue a new language standard in 2012; (e) the committee will continue for another year without new nominations. However, let me make it clear that the apparent lull in committee activity does not mean there are no active proposals being made. On the contrary, proposals for language features (and removals) are made by the community at large (that's you) - the committee's main role is not to make proposals, but to decide which to accept. And there have in fact been a large number of proposals, but very few have made it all the way to the stage of producing a "language report delta" that could be accepted (or modified) by the committee. So, I wish to declare "open season" on proposals for the 2012 standard. If there is a language feature you care about, please do take an hour or two to review the details on our wiki [3], search for older discussions on the mailing lists, and draft the Report changes you think would be necessary. I'm looking forward to a more active and exciting collection of potential language changes for 2012, but it will only happen if you get involved. Regards, Malcolm (Haskell 2011 committee chair) [1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html [2] http://www.haskell.org/pipermail/haskell/2010-July/022189.html [3] http://hackage.haskell.org/trac/haskell-prime/

4 5

Thoughts on unsafeLocalState
by Dan Knapp 19 Feb '11

19 Feb '11

Hi, First off, this is my first time posting to this list. I hope my post is appropriate! I noticed in going through the API docs that we now have unsafeLocalState in Foreign.Marshal, which currently is defined as equivalent to unsafePerformIO, but with a note that it "is likely to be replaced". I did look through the archives of this list, but found no discussion of it. The description of it in the API docs is simply: Sometimes an external entity is a pure function, except that it passes arguments and/or results via pointers. The function unsafeLocalState permits the packaging of such entities as pure functions. The only IO operations allowed in the IO action passed to unsafeLocalState are (a) local allocation (alloca, allocaBytes and derived operations such as withArray and withCString), and (b) pointer operations (Foreign.Storable and Foreign.Ptr) on the pointers to local storage, and (c) foreign functions whose only observable effect is to read and/or write the locally allocated memory. Passing an IO operation that does not obey these rules results in undefined behaviour. It is expected that this operation will be replaced in a future revision of Haskell I found a more complete explanation at the bottom of: http://hackage.haskell.org/trac/haskell-prime/wiki/ForeignFunctionInterface (Scroll to "Considerations for the future".) The notion seems to be that we would create a new monad that only allows specific actions to be taken. This is great as far as it goes. I very much support the idea, and would switch my code to use it if it were developed. However, I think the restrictions as given in the text I quoted above are too tight. Ideally we want something that would be suitable for libraries such as ByteString, which I believe wraps the allocation of data on the foreign heap in pure functions. This would not be allowed by unsafeLocalState in the form given, because the only pointer operations allowed by clause (b) are those on memory that is allocated in temporary fashion as by clause (a). I'm not sure quite how to word this, but I think perhaps broadening clause (a) to also allow allocation of ForeignPtrs, effectively changing the restriction from "anything you allocate must be freed by the time you return" to "anything you allocate must be known to the garbage collector". I have a practical use for this; I am working on a binding to libffi, pursuant to developing a better ObjC/Cocoa binding. To use libffi, it is necessary to build complicated structs. So I have the definition type ComplicatedStruct = ForeignPtr (), and a function, currently wrapped in unsafePerformIO, which constructs a new complicated struct given a description of what it should contain. This is, in my understanding, a "safe" usage of unsafePerformIO, but really it would be nice to use something safer. So I don't know that I have an action item, I just wanted to make sure that if and when future development on this happens, it takes this concern into account. Um, thanks for reading? -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

1 0

specify call-by-need
by Scott Turner 18 Feb '11

18 Feb '11

In practice, Haskell a call-by-need language. Still, software developers are not on firm ground when they run into trouble with evaluation order, because the language definition leaves this open. Is this an underspecification that should be fixed? 1. Haskell programmers learn the pitfalls of sharing as soon as they cut their teeth on 'fib', 2. Virtually all significant-sized Haskell programs rely on lazy evaluation and have never been tested with another evaluation strategy, 3. Questions come up on Haskell-Café, infrequently but regularly, regarding whether a compiler optimization has altered sharing of values within a program, causing it to fail, 4. The rationale for the monomorphism restriction assumes lazy evaluation, 5. It is the effect on asymptotic behavior that matters, 6. Portable Haskell code should not have to allow for the variety of non-strict evaluation strategies, as the Haskell Report currently implies. I suggest specifying call-by-need evaluation, allowing for the places where type classes prevent this. If necessary, make it clear that local optimizations not affecting asymptotic behavior are permitted. This would not eliminate struggles with evaluation order. The intent would be to clarify expectations. -- Scott Turner

3 3

Reform of the Monad, and Disruptive Change
by John Smith 04 Feb '11

04 Feb '11

There has been a fair amount of discussion, both on this list and libraries, regarding the Monad class hierarchy. The many on the libraries list expressed support for the patch at http://hackage.haskell.org/trac/ghc/ticket/4834, conditional on it being part of the next Haskell report. However, Haskell' prefers patches to have been implemented before proposing here. What is the best way out of this deadlock?

7 7

Re: Reform of the Monad, and Disruptive Change
by Howard B. Golden 04 Feb '11

04 Feb '11

John Smith <voldermort(a)hotmail.com> asked: > What is the best way out of this deadlock? My suggestions: * If possible, make the change optional. As an example, create a second (third, etc.) Prelude with the new features without abandoning the current Prelude. Let the user choose the Prelude he/she wants via a pragma or compiler option. Then developers can vote with their feet (fingers?). If the new Prelude is buggy, it will be easy to try something else. You might call this "intellectual free enterprise." * Do everything possible to create adapters to make upgrading existing code to the new Prelude. Thus, if a new Prelude is adopted widely, existing code will be easy to incorporate with minimal source changes. * Avoid disruptive changes by letting the user decide. Once there is a clear consensus based on significant usage, then the new Prelude can be blessed by some committee (if desired). However, don't abandon the previous Prelude as an option, ever. Textbooks might teach only the newer Prelude, but old code would still work. * Recognize that the Haskell user base at this time shouldn't be constrained by mandated changes, but should be encouraged to experiment and evolve the libraries. Cheers, Howard

1 0

Local definitions in the class instances
by Boris Lykah 02 Feb '11

02 Feb '11

I think it would be convenient to allow adding variables and functions, which are not members of the class, to a class instance so that they are visible only in the instance scope. It will help if the same functions are used by several class functions. Example: When implementing Num class for my datatype, I found that I routinely do unwrapping in each operator definition. I extracted it into functions, but as they are used only in instance definition, I want to put them there and restrict them to that scope. It would be neater than leaving them in the global scope or copypasting into each operator. > newtype Wrapped = Wrapped Integer deriving (Show, Eq) > instance Num Wrapped where > (+) = lift2 (+) > (-) = lift2 (-) > (*) = lift2 (*) > abs = lift abs > signum = lift signum > fromInteger = Wrapped > lift2 f (Wrapped a) (Wrapped b) = Wrapped (f a b) > lift f (Wrapped a) = Wrapped (f a) The extension implementation should be very simple. -- Regards, Boris

8 9