- Haskell - Haskell.org

RE: [Haskell] A haddock question
by Simon Marlow 10 Oct '05

10 Oct '05

[please excuse premature send.] On 10 October 2005 12:44, Benjamin Franksen wrote: > I have a module with a public class plus some instances for public > data types. In addition, I use this class inside another module where > I declare local (module private) data types and make them instances of > the class. I had expected that haddock (I am using 0.7) will list in > the documentation only instances of data types that are exported, but > instead all instances are listed. > > Is there a way to persuade haddock to list only instances of data > types that are actually visible to the user? Haddock's support for instances is somewhat braindead - it just reports all the instances it can find for a given class in the entire set of modules it is processing. In particular, Haddock makes no attempt to tell you how to bring these instances into scope: they might not be available from the module that exports the class, or the type(s), involved in the instance. Haskell makes this quite hard: an instance is available if it is provided by the transitive closure of an imported module. We clearly don't want to report all the available instances in every module's documentation, however. We probably don't want to document every module from which an instance is available either. Nevertheless, doing one of these two would be "correct". I'm open to suggestions. Benjamin: your example is probably more simple, Haddock probably just shouldn't be exposing those instances if they refer to non-exported types, I just wanted to point out the more general problem. Cheers, Simon

2 1

ANN: MissingH 0.12.0 (Better binary file support)
by John Goerzen 10 Oct '05

10 Oct '05

MissingH 0.12.0 is now available. Changes from 0.11.5 include: * MissingH.IO.Binary can now work with Strings or [Word8], instead of just strings. This support is implemented with a typeclass, so the module is fully backwards-compatible. * MissingH.IO.Binary can now work with any HVIO object, not just Handles. * New support for binary I/O in MissingH.IO.HVIO and HVFS. * Updated BlockIO and Threads.Child to 2005-02-14 versions from Peter. * MissingH.IO.Binary.hBlockCopy optimized to require no conversion of the buffer. * Fixed docs to work with Haddock 0.7 * New module MissingH.Daemon to support detaching from a controlling terminal * New simplegrep.hs example MissingH homepage: http://quux.org/devel/missingh or gopher://quux.org/1/devel/missingh MissingH source and Debian packages are also available from any Debian mirror, such as: http://http.us.debian.org/debian/pool/main/m/missingh (There is approximately a 48-hour delay before new versions appear there.) Currently in development for MissingH 0.13.0: * Native Haskell support for creating and extracting tar files * E-mail mailbox abstraction and implementation for Maildirs and MBOXes -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715

1 0

RE: [Haskell] SPJ book - big idea behind supercombinator reductionrestriction
by Simon Peyton-Jones 10 Oct '05

10 Oct '05

| Is it crucial just for reasons of efficiency - and in actual fact it's | entirely possible, albeit inefficient, to instantiate one variable at a | time? That's exactly right. Simon

1 0

RE: [Haskell] A haddock question
by Simon Marlow 10 Oct '05

10 Oct '05

On 10 October 2005 12:44, Benjamin Franksen wrote: > I have a module with a public class plus some instances for public > data types. In addition, I use this class inside another module where > I declare local (module private) data types and make them instances of > the class. I had expected that haddock (I am using 0.7) will list in > the documentation only instances of data types that are exported, but > instead all instances are listed. > > Is there a way to persuade haddock to list only instances of data > types that are actually visible to the user? Haddock's support for instances is somewhat braindead - it just reports all the instances it can find for a given class in the entire set of modules it is processing. In particular, Haddock makes no attempt to tell you how to bring these instances into scope: they might not be available from the module that exports the class, or the type(s), involved in the instance. Haskell makes this quite hard: an instance is available if it is provided by the transitive closure of an imported module. We clearly don't want to report all the available instances in every module's documentation, however. This is exposes to the user

1 0

SPJ book - big idea behind supercombinator reduction restriction
by paul boston 08 Oct '05

08 Oct '05

Simon Peyton Jones's book "The Implementation of Functional Programming Languages", chapter 13 (Supercombinators and Lamba-lifting), page 222, describes a "multi-argument" beta-reduction strategy whereby several free variables of a multi-argument abstraction may be instantiated simultaneously. Then, on page 225 the following sentence appears: "A crucial point in the definition of a supercombinator given above is that a supercombinator reduction only takes place when all the arguments are present." I feel that there's some big idea in the pages between these two references, but I can't quite grasp it. I can appreciate that there are good reasons (e.g. efficiency) to instantiate several variables at once, but I don't quite understand why this restriction is "crucial". Is it crucial just for reasons of efficiency - and in actual fact it's entirely possible, albeit inefficient, to instantiate one variable at a time? Or is it, given that the whole point of supercombinators is to allow compilation to fixed code sequences for the G-machine, that there is a good reason to avoid having these fixed code sequences deal with instantiating one free variable at a time (simplicity of design, or some kind of restriction on the way that G-machine operations work)? Or is there a deeper theoretical reason related to the combinators themselves that has nothing to do with the downstream compilation process? _________________________________________________________________ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters

1 0

ANNOUNCE: pam-1.0
by Henning Günther 06 Oct '05

06 Oct '05

pam-0.1 ------- Haskell bindings for pam. Weeeeeee! This is my first release _ever_. I've created it mainly for learning reasons and just want to share it with the haskell community. See http://haskell.org/pam for more information about it. Feedback is very welcome. :) It's very untested yet, so it'll possibly crash, turn your computer into smoke and talk dirty to you. Just don't blame me, I've only written it.

1 0

RE: [Haskell] strictness of putChar: report incomplete?
by Simon Marlow 06 Oct '05

06 Oct '05

On 05 October 2005 17:05, Lennart Augustsson wrote: > Wolfgang Jeltsch wrote: >> Am Mittwoch, 5. Oktober 2005 16:22 schrieb Simon Marlow: >> >>> [...] >> >> >>> Also, GHC's optimiser currently treats (_|_ :: IO a) and (do _|_; >>> return ()) as interchangeable, which is naughty, and people have >>> occasionally noticed, but the benefits can sometimes be huge. It >>> is this distinction that makes it hard to optimise IO code in a >>> Haskell compiler, though. >> >> >> I think, seq should be a method of a type class. Then we could >> forbid applying seq to a function, we could forbid applying seq to >> an IO expression and we could forbid applying seq to expressions of >> any type with hidden implementation for which we don't want to >> provide bottom tests. > > I agree with you. And that is how it used to be, but then > some people didn't think that was convenient enough so now > we are stuck with a seq that (IMHO) stinks. :) Having a seq that works on anything is occasionally very useful for fixing space leaks, and the type class version was kind of ugly and unwieldy. The type class pops up when you use ! in a data declaration, which looks strange. But I agree that polymorphic seq does have some painful side effects. Cheers, Simon

2 1

RE: [Haskell] Making shared libraries with Haskell
by Simon Marlow 06 Oct '05

06 Oct '05

On 26 September 2005 08:57, Joel Reymont wrote: > Is the procedure of creating shared libraries with Haskell and > loading them from C described somewhere? > > Is this even possible? It currently isn't possible to build a Unix-style .so from Haskell code using GHC, although there is work in this direction (PIC and shared libraries are supported on MacOS X, and other platforms are in progress). It is possible to build a Windows DLL from Haskell code, although currently all the Haskell code has to reside in a single DLL. Again, this is a restriction we intend to lift in the future. It has been working before, but bitrotted due to fragility and lack of developer resources. Cheers, Simon

3 2

Newbie quick questions
by Mike Crowe 05 Oct '05

05 Oct '05

Hi folks, I ran across Haskell at the Great Win32 Computer Language Shootout. A friend approached me with a potential large application to develop. The idea of a language which can reduce time to design and make better code is very intriguing. I was looking at prototyping in Python using wxWindows as the GUI. I see Haskell has wxWindows libraries as well. So, here's some newbie questions I couldn't get from 2-3h on the various web sites: 1) Can I develop a Windows application to sell? Or is Haskell not really geared for that? 2) Say a team wants to develop a larger application, like a CRM system. In "thinking" in functional programming, can a team split up work and implementation and work together? In other words, how easily does Haskell adapt to a team approach? 3) Again, using a CRM tool as an example, what is the advantage to developing an application like this in Haskell vs. any other language? If I really invest the time, can I get this done quicker in Haskell? Sell me on this, please. 3) I'm a very top-down programmer. I like to start at the "big-picture" and work my way down in implementation. Does this adapt to Haskell, or am I missing the point? TIA! Mike

6 7

RE: [Haskell] strictness of putChar: report incomplete?
by Simon Marlow 05 Oct '05

05 Oct '05

On 04 October 2005 14:16, Duncan Coutts wrote: > On Tue, 2005-10-04 at 13:46 +0100, Malcolm Wallace wrote: >> I wrote: >> >>>> ghc: >>>> putChar _|_ -> _|_ >>>> >>>> hugs: >>>> putChar _|_ -> valid IO () >>> >>> I think it comes down to buffering behaviour doesn't it? >> >> Having reviewed the IRC logs, I see I was talking nonsense. >> >> You want to be able to store a closure for (putChar undefined) in a >> data structure, which seems like a perfectly reasonable thing to do. >> Provided the IO action is never actually run (after being retrieved >> from the data structure), the program really ought not to crash. >> >> I see that nhc98 and hbc agree with Hugs on this behaviour, so ghc >> _must_ be wrong. :-) > > Looking at GHC's library code we see that it is indeed forcing the > char early: > > hPutChar :: Handle -> Char -> IO () > hPutChar handle c = > c `seq` do > ... Fixed. However, I have a hunch that there are a *lot* of library functions whose strictness isn't completely specified by the report. Basically anything for which the report doesn't give the full code, except of course primitives which usually must be strict. This is only a hunch - I haven't actually gone looking for any. I suspect we get away with it most of the time because the desired strictness is "obvious" and/or the compilers all agree. Arguably, nothing returning IO should ever be strict, but you only have to use pattern matching in the implementation to violate that rule. Also, GHC's optimiser currently treats (_|_ :: IO a) and (do _|_; return ()) as interchangeable, which is naughty, and people have occasionally noticed, but the benefits can sometimes be huge. It is this distinction that makes it hard to optimise IO code in a Haskell compiler, though. Cheers, Simon

4 4