September 2001 - Haskell

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

17 Sep '01

2 1

Call for papers: WICS'2002
by Dr. Muhammad Sarfraz 17 Sep '01

17 Sep '01

Apologies if you receive multiple copies CALL FOR PAPERS WICS'2002 The Fourth Workshop on Information & Computer Science March 17-18, 2002 King Fahd University of Petroleum & Minerals, Dhahran, Saudi Arabia Information & Computer Science Department (KFUPM) in collaboration with IEEE Computer Society Saudi Arabia Chapter Theme: Internet Computing Best papers will be published in A Special Issue Of Information Sciences Journal Important Dates September 30, 2001 Papers due (about 15 pages). November 25, 2001 Notification of acceptance. December 23, 2001 Camera-ready papers. March 17 - 18, 2002 Workshop. For detailed information, please visit: http://www.ccse.kfupm.edu.sa/wics/ Contact Address : Chairman, Organizing Committee, WICS'2002 Department of Information & Computer Science KFUPM # 5066 King Fahd University of Petroleum and Minerals Dhahran 31261, Saudi Arabia Tel.: +966-3-860-2175 Fax: +966-3-860-2174 Email: wics(a)ccse.kfupm.edu.sa WWW: www.ccse.kfupm.edu.sa/wics/

1 0

learing haskell
by Peter Abbot 17 Sep '01

17 Sep '01

hello I am learning haskell for a course on programming languages that I am doing and I am having some trouble getting my head around functional programming. The problem that we are trying to solve is given a certain state, list all of the possible states that you could go through. I was thinking of having the ouput being a collection of lists but cant figure out how to append two list together to get something like: [[1,2,5], [1,2,8], [1,2,9], ...] The approach I am taking is that I have defined a type of State which is equal to Integer. I then have a function that takes a State and return a list of States that can be reached from that state. It is coming up with an algorithm to do both a depth first and breadth first search. Any suggestions would be greatly welcome. thanks Pete

1 0

Re: Type Problem
by Marcin 'Qrczak' Kowalczyk 16 Sep '01

16 Sep '01

Sun, 16 Sep 2001 16:28:01 +0800 (GMT-8), Saswat Anand <saswatan(a)comp.nus.edu.sg> pisze: > trickyFun fun = let x = fun (2::Int) -----------(1) > y = fun 'c' -----------(2) > in "tricky" It can't be done this way in standard Haskell. In GHC and Hugs you can use local universal quantifaction by writing explicit type signature: trickyFun :: (forall a. X a => a -> b) -> String GHC needs to be run with -fglasgow-exts, Hugs needs -98. GHC user's guide describes some limitations, e.g. trickyFun must always be directly applied to an argument. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Type Problem
by Saswat Anand 16 Sep '01

16 Sep '01

Hi, I am wondering how can I pass an overloaded function as a parameter to another function. Consider the following example. I want to tell the compiler that the argument `fun' in `trickyFun' definition is always either ord' or chr', and hence it can find the correct overloaded version in both the cases (1) & (2). Thanks, Saswat class X a where ord' :: a -> Int chr' :: a -> Char instance X Int where ord' = id chr' = chr instance X Char where ord' = ord chr' = id trickyFun fun = let x = fun (2::Int) -----------(1) y = fun 'c' -----------(2) in "tricky"

1 0

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