- Haskell - Haskell.org

Re: Application letters at the Haskell workshop: suggestion
by Duncan Coutts 15 Sep '01

15 Sep '01

> On Fri, 14 Sep 2001, Mark Carroll wrote: (snip) > > simplistic (but adequate for my immediate needs, which are currently > > being served with lots of ifs and Maybes!). > > Oh - and I should add, lots of two-tuple return values which are > basically of the form (Maybe a, error details). ): > > -- Mark Sounds like you need.... the Error Monad! I've been writing a little compiler in Haskell and found that a variety of error monads have been very helpful for structuring code that needs to be able to return errors. I've been using a few variants: single error, multiple error and multiple error/warning types. I'm also particularly pleased with one that has an extra combinator which allows seperate 'branches' of an expression to combine all the errors (if there are any). That allows multiple *independant* errors to be returned to the user rather than just the first one. I'm sure it been done before, buit it looks like this: BinOp op <$&> CheckExpr e1 <&> CheckExpr e2 and have overall type :: MaybeErrors Expr (where, BinOp op e e2 :: Expr) This would check each sub expression and return the overall expression (wrapped in the monad), unless either branch 'raises' an error. Also, if both branches raise an error, both errors are returned. It's suprising how little an algorithm needs to be changed when using monads like this. If found that I can start with a non-monadic version that just uses 'error' and then convert it to a monadic version quite easily. Duncan

1 0

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

15 Sep '01

Fri, 14 Sep 2001 02:09:21 -0700, Julian Seward (Intl Vendor) <v-julsew(a)microsoft.com> pisze: > 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. I think it should be easy to add support for C++, except exceptions. There are two approaches: call C++ functions directly (it requires implementing name mangling by the Haskell compiler; there are several name mangling schemes and gcc changed its scheme in version 3.0) or write C wrappers (this is inconvenient but is doable now without compiler support). An annoyance is that templates can't be called directly but each instance must be imported separately. On Linux it works when main() of a mixed C/C++ program is written in C. AFAIK it doesn't work everywhere. Nevertheless an example I've now made worked. hsc2hs and ghc need to be extended to make it work smoothly. hsc2hs produces a file with extension .c and ghc compiles these files by passing -x c options to the C compiler, so even if a C++ compiler is substituted, it is compiled as C. There should be a switch in hsc2hs to let it produce C++ and ghc should recognize .cc extension, or in some other way ghc should be informed that the .c file is really C++. Option -pgmlg++ causes ghc to link using g++; option -lstdc++ instead also works. And hsc2hs should be taught about extern "C". -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

4 3

The future of Haskell discussion
by S.J.Thompson＠ukc.ac.uk 15 Sep '01

15 Sep '01

There was a discussion at the Haskell workshop on the future of the language. It would be great to have some sort of minutes from this for those who were unable to attend. I gather that a standard GUI was mentioned; I'd particularly like to hear about what, if anything, was resolved about that. Thanks Simon

12 22

Re: The future of Haskell discussion
by Bill Halchin 15 Sep '01

15 Sep '01

3 3

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

14 Sep '01

Fri, 14 Sep 2001 18:04:24 +0300, Eray Ozkural <erayo(a)cs.bilkent.edu.tr> pisze: > I understand that you ought to deal with name mangling at some stage, > but how would the interfaces ultimately look like? It depends how sophisticated tools we create. The easy step is to wrap everything in functions. They would be C functions for the moment. For example a plain method would be wrapped in a C function with 'this' as one of arguments. With C++ support in the Haskell compiler it can be more convenient for overloaded functions and even non-virtual methods. Unfortunately for calling a virtual method or getting a field out of a struct/class it's not enough to supply what the programmer sees (function name and types involved) to generate the code; the object layout matters. Currently ghc doesn't deal with C/C++ object layout at all, and I imagine it would be very hard for it to do this (how to interpret a C++ header?). OTOH tools like hsc2hs and c->hs can support this; they already can handle C struct fields. I think calling a virtual method requires creating a function wrapper, but tools should cope with this in future. > If you can do non-template C++, then it wouldn't be difficult to > call template code. Just do an explicit instantiation of the template > code in an auto-generated .cxx file. What's the problem there? Usually it should not be a problem, because arbitrary Haskell objects can be represented only as something like StablePtr in C++, so templates working on Haskell objects don't need many instantiations. But a sophisticated cooperation between Haskell and C++ should probably create custom C++ classes for wrapping different kinds of Haskell objects, and then clients of a Haskell interface to a C++ library must instantiate templates themselves. -- __("< 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 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