September 2001 - Haskell

Re: Application letters at the Haskell workshop: suggestion
by Mark Carroll 14 Sep '01

14 Sep '01

I may as well send my reply to the list too, then! (-: On Fri, 14 Sep 2001 moran(a)galconn.com wrote: > Mark Carroll wrote: (snip) > > Oh, certainly, but couldn't the compiler do all the rewriting for you, > > though, so existing code would still work and new code would still look > > nice? > > I'm not sure how this would interact with type inference; what's the > difference between a function that I mean to be rewritten and one that I > don't? Perhaps what you're wanting is that every type implicitly has an > exception constructor tacked on. This is in effect what one gets with the > exception extension. Yes, I suppose you're correct, although I'd add that I'd expect that the compiler could often do lots of optimisation so that it only needs to check for the exceptional condition when checking the result of a function from which exceptions can arise, and in that case it can go right up to the handler, so in practice I bet that you could implement this without every single calculation being tainted by such overhead even though there's no semantic difference. > > (Although, the main point of my Succeeded/Exception example is just > > to show that for much exception stuff monads needn't be necessitated.) > > I'm not sure what you mean here. For hand-written exception code, monads make > the code easier to read in most cases. But I don't think you mean that; it > sounds like you mean "exceptions can be expressed already, so there's no need > for new stuff". I don't buy that in general (since otherwise, why not just > use the raw lambda calculus, or Turing machines), or in this specific case, > since the encoding is a lot of work, and needs to be done for almost > everything you might use (including things one usually doesn't have access to, > like the Prelude and library code). But maybe you don't mean that. I sort of do mean that, with the compiler doing the work you mention. There would be "new stuff" in how the "throws/catch" stuff the programmer would write would interact with how the compiler would implement the synchronous exceptions, but it would look reasonable to the programmer and not require them to catch such exceptions from within monads. (snip) > Well, if you can deal with only catching in the IO monad, then what you want > is avilable now, with the extension (GHC only at the moment I think). > Otherwise, you're stuck encoding it. Now, you may well be able to structure > your code better if you employed an exception monad (not the IO monad, just an > ordainary monad), or perhaps a continuation monad. (Aside: it seems as though > you're lumping general monads, usable anywhere without affecting the rest of > the program, together with the IO monad, which is the top-level > put-impure-things-here monad. It's important to see that there's a > difference. I apologise if you do; if you don't, feel free to ask probing > questions.) (-: Really, I just want to be able to use exceptions that behave more or less as I've suggested without having to catch them from within monads. It would indeed be especially irritating to have to catch them all within the IO monad, as I would now if I wasn't doing the ugly manual encoding that I currently have to that I figure could easily be done behind the scenes with some much nicer syntactic sugar on top. I may not understand monads enough, though. I think of them being inextricably linked with actions, probably sequenced ones, and I'm wanting to use exceptions in purely declarative code where actions shouldn't be relevant concept. Perhaps I should be writing this code in a monadic style, though, and thinking in terms of actions. -- Mark

1 0

Re: The future of Haskell discussion
by Marcin 'Qrczak' Kowalczyk 14 Sep '01

14 Sep '01

Fri, 14 Sep 2001 11:51:14 +0100 (BST), D. Tweed <tweed(a)cs.bris.ac.uk> pisze: > As a general question (and forgive my ignorance): are the various ffi's > implemented using something like `dlopen' or are they done by actually > putting suitable stubs into the Haskell generated C-code which then gets > compiled by the C compiler as part of the overall haskell compilation? The latter. > (1) Firstly there's calling code where the interface is basically > C but compiled with C++; at this level there's the issue of name > mangling (accounting for both for argument structure and namespace > effects) and any global stuff in the C++ code (e.g., ensuring global > objects construction/destruction happens at times that are ok). This should be easy. > (2) Then there's being able to invoke the method of an object > without caring about moving `inside object' information back in to > haskell (e.g., calling the colour_segment() member of an object of > the Image class). Here the object is essentially just acting as a > `struct with attatched function pointers'. hsc2hs can be used to do similar things in two ways: - either a Haskell module is preprocessed by a dynamically generated C program which knows object layout by including a header and uses it to fill special syntactic constructs with right constants, - or C function wrappers are created which are compiled by the C compiler. c->hs goes a third way: - a Haskell program reads C headers, computes object layout using its own logic, and fills special syntactic constructs with right constants. hsc2hs can be specialized for some C++ constructs, although convenience of using it is limited by the simplicity of the way it works. It can't for example automatically translate full contents of types between C++ and Haskell (unless its Haskell side implements a C++ parser). It can do whatever a C++ program which includes the headers can do with marked parts of a Haskell source, accompanied with simple decisions taken by its Haskell side which sees raw C text (this now includes extraction of the "declarative" part of a definition which should go to a C header). I will see what can be done with C++-specific constructs, but before that ghc should be changed to be able to compile *.cc files (hsc2hs calls a Haskell compiler to compile C files, because it inserts necessary include path options). c->hs has more power in its hands, at the cost of having to reimplement parts of the logic of a C++ compiler. It can perform some sophisticated structural translation. But it can't be fed with C++ headers at all until it is prepared to understand them - its parser currently understands only C headers. > (3) Then there's being able to actually use objects more fully via > a Haskell type/type-class wrapper of some sort (so that for example > objects of C++-class X_cpp with a member function This is surely beyond the scope of hsc2hs. IMHO it should not be an integral part of the FFI, because there are too many design decisions to take. Instead tools should be ready to make it easy to implement library-specific conventions. > (4) Finally there's being able to propagate C++ exceptions into Haskell, > using either Haskell exceptions or some other representation. (This is > clearly incredibly hard, but I belive some package (forget which) manages > to propagate C++ exceptions into Python exceptions.) There are two approaches: teach the code generator of a Haskell compiler how to cooperate with C++ exceptions, and design tools which make wrapping functions for this case not too inconvenient. Both ways are hard. Unfortunately we need both directions. Currently Haskell exceptions are not properly propagated through C functions. And extern "C" is incompatible with exceptions, so until the code generator can handle it itself, exceptions must be always manually translated to other means. > Indeed, with a potential additional problem: many template functions are > written as inlines in header files, so that if I try and use a template > function I wrote years ago in a .cc file containing a C++ class I defined > yesterday I silently get the correct code compiled into the new .o > file. Actually in ISO C++ there is an 'export' keyword which allows to keep template bodies in .cc files, but... no compiler implements it (and almost none even tries). It's incredibly hard - it doesn't fit the traditional C++ compilation and linking model at all. The main problem is that the instantiated template code should be compiled using a strange mix of the environment from the point of template definition and instantiation. Depending on types involved, a name is looked up in either environment. C++ template is neither a textual substitution nor semantically polymorphic code, but something in-between. It used to be more like textual substitution before; at least old Borland implemented it this way - syntax errors were not recognized before instantiation, only braces were matched to find the end of the function or class. Now parts which don't depend on the template parameters are treated more "semantically", and there must be some hints in the syntax ('typename', 'template') so the template can be fully parsed before instantiation and partially typechecked. > If I try to `glue' together a template function and a new C++ > type (where they haven't been used together otherwise) where does > the new instantiation go; do I have to go around adding explicit > instatantiation requests in the C++ source? The C++ compiler must at least once see the template body instantiated with the right types. It's usually not smart enough to avoid repeated recompilations of the instantiated code, but it should be able to remove this duplicate code during linking. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

[Fwd: Application letters at the Haskell workshop: suggestion]
by moran＠galconn.com 14 Sep '01

14 Sep '01

[ Meant for this to go to the mailing list ... ] -- Andy Moran Ph. (503) 526 3472 Galois Connections Inc. Fax. (503) 350 0833 3875 SW Hall Blvd. http://www.galconn.com Beaverton, OR 97005 moran(a)galconn.com

1 0

Re: Application letters at the Haskell workshop: suggestion
by Marcin 'Qrczak' Kowalczyk 14 Sep '01

14 Sep '01

Fri, 14 Sep 2001 12:10:27 +1000, Manuel M. T. Chakravarty <chak(a)cse.unsw.edu.au> pisze: > Maybe it should be clarified that there are exceptions in > H98, but *only* in the IO monad. What the extension is > about are exceptions in pure functions. BTW, Exceptions are useful for something other than Haskell 98 I/O primitives only when combined with Dynamic. Haskell 98 Exceptions are limited like errno in C. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: Application letters at the Haskell workshop: suggestion
by brk＠jenkon.com 14 Sep '01

14 Sep '01

Thanks, that's very valuable information. It's hard to appreciate the relative utility (as you can see :-)) of different experimental features. It's also confusing that things like exceptions, concurrency, and FFI are labeled 'experimental'. They're so (IMHO) crucial that I find myself saying, "Okay, if exceptions are 'experimental', what other really important things might I be missing by not being familiar with all the experimental extensions?" Thanks for clearing that up somewhat. On a tenuously related note, I should mention that so many Haskell examples focus on things which fit easily into a functional mold (factorial, etc.) that I did not actually have the faintest idea how to create a real and useful Haskell program until I saw the code for Simon Marlow's web server. The snippets on Doug Bagley's Computer Language Shootout were also helpful. It's also very difficult to find examples which demonstrate the use of experimental features. I mention this only because your report below of what features you use daily provides a useful point of reference for people wondering what actually goes into a non-trivial Haskell application. Bryn > I consider myself a fairly hardcore Haskell user (I used to be a > language designer and compiler/library developer but now I work on > another language and write my tools in Haskell and perl). Despite > this, I don't think I use any of the features you list (I guess I'm > suggesting that these might not be the most important to you either). > > I do use the IO monad, IORefs (sparingly), constructor classes, lots > of libraries, the foreign function interface (lets you call C and > C++), parser generators (happy) and parser combinators, exception > handling and concurrency (even just the lame non-preemptive version > that Hugs provides). > > Of course, this partly reflects the kinds of programs I write and, to > some extent, my being comfortable with the features and libraries I > know and not having time to really explore what I can do with the > other features. > > -- > Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

6 6

Existential types: HM versus System F
by edrx＠inx.com.br 14 Sep '01

14 Sep '01

Could someone recommend me a paper that discusses the relation between Girard's System F and Hindley-Milner type systems? I've been studying system F lately (and Haskell's semantics is still somewhat mysterious to me), and in System F existential types can be built from the basic operations, while in Haskell it seems that one needs language extensions to be able to use them... Thanks & cheers, Eduardo Ochs http://angg.twu.net/ edrx(a)inx.com.br

1 0

RE: closing file handles
by Simon Marlow 14 Sep '01

14 Sep '01

> Tom Pledger wrote: > > [...] > > go' f > > = do h <- openFile f ReadMode > > text <- hGetContents h > > case text of > > (c:_) -> do hClose h > > return c > > > > This way, the pattern match on `text' happens before the innermost > > `do', which in turn closes the handle before letting the rest of the > > computation continue. > > I think the above code will lead to problems if file input is > done when c is evaluated and not earlier. Fortunately, in GHC this isn't the case. Evaluating the (:) is enough to force the character to be read. But to be on the safe side you could also write it like this: go' f = do h <- openFile f ReadMode text <- hGetContents h let c = head text c `seq` do { hClose h; return c } Cheers, Simon

4 3

JPBernède/Haskell/Question about Sgbd Connexion
by Jean-Pierre Bernède 14 Sep '01

14 Sep '01

Hello, I would like to know how can-I mapping Haskell program with a database (for example Oracle). and How can-I encapsulate the request in a O'Haskell Object ? Thanks for your response. Kind regards Jean-Pierre Bernède (Paris - France).

1 0

RE: The future of Haskell discussion
by Julian Seward (Intl Vendor) 14 Sep '01

14 Sep '01

| wxWindows is quite C++ centric and AFAIK nobody has made a | serious effort at a C++ FFI yet. One of the big advantages | of GTK+ is that it was written with bindings for other | languages in mind. Therefore, it is probably the toolkit | with the most language bindings. The lack of any way to interface to C++ is a problem, IMO. I would love to be able to write Haskell programs using Qt and ultimately the KDE libraries, both of which are C++, but I can't, at the mo. J

1 0

Re: Application letters at the Haskell workshop: suggestion
by Marcin 'Qrczak' Kowalczyk 14 Sep '01

14 Sep '01

Fri, 14 Sep 2001 01:00:06 +0200, Lennart Augustsson <lennart(a)augustsson.net> pisze: > I have been writing substantial Haskell programs and I use *NO* > experimental features. In a 2000-line interpreter I used: - FiniteMap (for environments), - Dynamic & Exception (for exceptions in the language being implemented and compile errors), - MonadReader, MonadError (for convenience, in two places), - MVar (could be IORef; for mutable objects in the language being interpreted), - unsafePerformIO (for three global variables: unique supply, loaded modules, search paths), - Readline (for the interactive toplevel). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1