- Haskell - Haskell.org

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

26 Sep '01

Mike - I hope you don't mind passing this to the list - but it's a great, simple explanation of a big problem with my approach. On 14 Sep 2001, Mike Gunter wrote: > The problem is not a loss of referential transparency but the > requirement that evaluation order must be specified. E.g. > what should > > raise "left" + raise "right" > > return? (snip) Ah! Yes, I see what you mean - this explains what Andy Moran was thinking, probably. (-: Moreover, if we have a pseudo-Haskell code snippet like, try f (a 1) (b 2) catch error-1 -> 1 error-2 -> 2 where a _ = raise error-1 b _ = raise error-2 ... then is the return value of this 1 or 2? AFAICS a simple way to get out of this is to only have one exception type that carries no information instead of different ones so we can't distinguish one exception from another, but that's obviously not great. One other thing you could do, which might mean a bit more evaluating than you otherwise would have done, is to evaluate enough to find out what the different possible "first exception"s are, gather them all up, and the handler that operates is the first applicable one if you list the higher-level 'catch' statements before the lower ones (so there's a total order on the handlers for exceptions arising from any particular expression within an evaluation). So, in this case, we detect that error-1 and error-2 were both thrown, but we return '1' because the error-1 handler was listed before the error-2 handler, just as we do with pattern matching IYSWIM. So, maybe we do have a way to resolve this that doesn't reveal evaluation order, with the penalty that we have to evaluate enough to discover which possible exceptions get thrown so that we really do use the 'first' applicable handler. I'm also subscribe to haskell-cafe if people think this discussion should migrate to there. -- Mark

2 1

RE: GUI Library Task Force
by Ashley Yakeley 26 Sep '01

26 Sep '01

At 2001-09-25 01:53, Manuel M. T. Chakravarty wrote: >* I am not a big fan of introducing an extra monad (`GUI' in > this case). It can easily become a pain in programs that > do a lot of "normal" IO as you have to lift all IO > functions to GUI. Heh. I had to do this for JVM-Bridge because all the JNI functions need the JavaVM. A bit like this: data JVM a = MkJVM (JavaVM -> IO a) instance Monad JVM where etc. ...actually there's more to the 'context' than that, but you get the idea. Of course there's a 'callIO' function to make lifting as painless as possible. On the other hand with the full Java API hopefully there's less necessity to use "normal" IO at all anymore so perhaps it will be less of an issue. -- Ashley Yakeley, Seattle WA

1 0

IEEE Conf.on Software Maintenance, Italy,Florence, ICSM2001
by icsm2001 26 Sep '01

26 Sep '01

Dear Colleague I would like to invite you to attend the IEEE International Conference on Software Maintenance, 2001, and associated workshops: IEEE SCAM, IEEE WESS, IEEE WSE, TABOO. FLORENCE, ITALY, 6-10 November 2001 http://www.dsi.unifi.it/icsm2001 ICSM is the major international conference in the field of software and systems maintenance, evolution, and management. Theme: Systems and Software Evolution in the era of the Internet kEYWORDS: software evolution, embedded suystems, program analysis, reengineering, managment, maintenance, lyfe cycle, Internet and distributed systems, Multimedia systems, User interface evolution, Commercial off-the-shelf (COTS), Program comprehension, Formal methods, Empirical studies, Testing and regression testing, Measurement of software, METRICS,etc. Please forward the following to anybody you think may be interested. The discount for the advanced registration fee will be active for few days. Apologies for multiple receptions. If you would like to be removed from our list please send an email to icsm2001(a)dsi.unifi.it with REMOVE in the subject. Paolo Nesi (ICSM2001 General Chair)

1 0

Satisfiability and ambiguity
by Carlos Camar�o 25 Sep '01

25 Sep '01

Folks, I have recently been referred to a paper by Duggan and Ophel, about "Type-checking Multi-parameter type classes" [1]. I think it will be useful to consider the following. ---------------------------------------------------------------------- 1. "Domain-driven unifying overload resolution" (DDUOR, so-called in definition 4.1 in [1]) should not fail to terminate; i.e. satisfiability is not undecidable (see system CT [2]). DDUOR should consider the *set* of constraints (in C, in def. 4.1), instead of one after another, for finding unifying substitions (\theta'' in def. 4.1). For the example (page 17 of [1]): class F a b where f:: a -> b -> Int instance F Int Float where f x y = 0 instance F a b => F [a] [b] where f [x] [y] = f x y g x y = (f [x] y) + (f y [x]) the definition of g will be detected as erroneous (not well-typed) if the *set* of constraints is considered for finding the unifying substitution, instead of one constraint after another. In this way, DDUOR terminates. I think full details will not be needed, but this can be (easily) understood by reading/following the definition of sats in system CT. -------------------------------------------------------------------- 2. The usefulness of multi-parameter type classes has been hindered by the restrictiveness of the rule for detecting ambiguity. Instead of tv(P) \subseteq tv(t), where P is the set of constraints and t is the simple type, the rule for nonambiguity should be P = P |* tv (t,G) where |* denotes "constraint projection" and G the typing context. For the definition of |* see [3]; the idea is to include constraints that have type variables in t and G and constraints that have type variables previously included. In the example: For: P = F a b and t = a We have that: P => t is not ambiguous Since: P |* {a} = P This rule would allow multi-parameter type classes to be used in (well-known) compelling examples, without giving rise to ambiguities. Carlos [1] Type-checking multi-parameter type classes, Dominic Duggan and John Ophel, to appear in JFP. [2] Type Inference for Overloading, Carlos Camarão and Lucília Figueiredo, Technical report UFMG, available at http://www.dcc.ufmg.br/~camarao/jfp-ct.ps.gz. [3] Overloading and Coherence, Carlos Camarão and Lucília Figueiredo, Technical report UFMG, available at http://www.dcc.ufmg.br/~camarao/overloading-and-coherence.ps.gz .

1 0

Final CALL: WICS'2002
by Dr. Muhammad Sarfraz 25 Sep '01

25 Sep '01

Apologies if you receive multiple copies FINAL 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

ANNOUNCE: Happy version 1.11
by Simon Marlow 25 Sep '01

25 Sep '01

ANNOUNCING Happy 1.11 - The LALR(1) Parser Generator for Haskell ----------------------------------------------------------------- I'm pleased to announce version 1.11 of Happy, the parser generator system for Haskell. This is a minor update from version 1.10, with - a bugfix for using Happy with GHC on 64-bit platforms - a minor change to the way that precedence parsing is handled: tokens no longer have a default precedence. Happy is available in source form, which can be compiled with GHC version 4.xx (4.08+ recommended), and binaries for certain platforms are also provided. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to simonmar(a)microsoft.com.

1 0

ANNOUNCE: Hat and nhc98 version 1.08
by Malcolm Wallace 25 Sep '01

25 Sep '01

Hat + nhc98 version 1.08 ======================== We are pleased to announce a new release of Hat and the nhc98 compiler. This is a stable release, containing many bugfixes in both the compiler and the Hat tracing and debugging tools. If you have not yet tried out the Hat tracing system, this is a good opportunity to give it a workout. New features of note in release 1.08 are: * There are "tunnels" between hat-observe, hat-detect, and hat-trail, enabling the user to jump directly from one view to another at exactly the point of interest. * You can now have multiple copies of hat-trail running simultaneously. * The nhc98 compiler implements the recent revisions of the Haskell'98 Report. nhc98 is a full compiler for Haskell'98, with extensive support for space profiling, time profiling, and tracing your programs. The system is available as source code, which can be built with the Gnu C compiler on any 32-bit platform, or with any already-installed Haskell compiler. Binary packages are also currently available for ix86-Linux and sparc-solaris2. http://www.cs.york.ac.uk/fp/nhc98/ Further information about Hat is available at http://www.cs.york.ac.uk/fp/hat/ Happy tracing, The ART team in York (Malcolm Wallace, Olaf Chitil, Thorsten Brehm, Colin Runciman)

1 0

Re: RFC: GUI Library Task Force
by Ashley Yakeley 25 Sep '01

25 Sep '01

At 2001-09-24 05:44, Manuel M. T. Chakravarty wrote: > *** The GUI Library Task Force Strategy Proposal *** It's worth pointing out that I'm covering much of the same ground with my bridge to the Java VM. http://sourceforge.net/projects/jvm-bridge/ Of course there are differences: >* Development of a GUI library API for Haskell that is > portable across Haskell systems and operating/windowing > systems Same. >* The library focuses on graphical *user interfaces* (ie, > buttons, menus, scrollbars, selection lists, etc) as > opposed to drawing and animation routines. Java has APIs for both, I believe. >* Verification of the design by at least one implementation > of a library that exports the GUI API This has already been done for the Java APIs. >* Minimal use of features that are not included in Haskell > 98 (in fact, we currently believe that we can keep the API > completely free of any non-H98 features; however, > application programs that use the API will need some > non-H98 functionality) I admit I am using some non-H98 features... in fact right now I'm working solely with GHC. >* While we do not require support of concurrency by Haskell > systems implementing the API, the use and behaviour of the > API must be well-defined on systems that do support > concurrency I will be using Java's threading. This means the Haskell system needs to support concurrency. >* Core library: > - Due to the complexity of modern GUIs, we cannot hope to > cover a fully-fledged GUI library in reasonable time and > with reasonably effort; thus, we concentrate on a core > library (what exactly constitutes the core remains to be > defined) Inasmuch as the AWT/JFC/Swing counts as 'fully-fledged', I will have it. >* Openness for tools support; for example, it should be > possible to support graphical interface builders (such > tools are not part of the API, but we need to ensure that > we do not seriously complicate the construction of such > tools) Same. >Non-goals >~~~~~~~~~ >* We will not design a fully-fledged GUI library from > scratch: Hopefully, I will be simply picking up a fully-fledged GUI library. >* We will not design a "purely functional GUI": Same. >The Plan >~~~~~~~~ >* Handling of state altered by both the application and by > GUI widgets: I'm not sure what the issue is here. >* Start from the API of GTK+ as a base line: > - This is an API that has a proven track record of being > suitable for small, medium, and large-scale applications Same for Java. I think. > - The API does not overly rely on object-oriented language > features This is the biggest sticking point for Java. The JVM-Bridge will allow you to create and load Java classes at run-time, even then, this may turn out to be complicated for the user. > - A large body of free documentation exists for the API, > which can be adapted to our purpose Same for Java. http://web2.java.sun.com/docs/books/tutorial/ > - A working Haskell binding exists that can be extended to > provide a first implementation of the Haskell GUI API I don't have anything usable yet. The JVM-Bridge will have to be code-complete before it is usable. > - GTK+ itself is already reasonably platform independent Same or better for Java. >* Ensure platform independence: Same. >* Haskell-ise the API: > - C-ish functionality will be cut out > - Full use will be made of Haskell's type system and, in > particular, type classes Same. >* Convenience libraries >- The API will include a set of convenience libraries on top > of the basic API (eg, by providing layout combinators) A straightforward addition, but not part of my core effort. -- Ashley Yakeley, Seattle WA

3 2

Joy language. Reply
by S.D.Mechveliani 25 Sep '01

25 Sep '01

S. Alexander Jacobson <alex(a)shop.com> writes > I just found out about a functional programming language called > Joy (see http://www.latrobe.edu.au/philosophy/phimvt/joy.html) > > Joy differs from Haskell in that it has no variables. Instead, all > functions are postfix, taking a stack as their argument and returning a > stack as a result. > [..] > tree-rewriting rules go away), faster development, easier optimization > (search and replace lists of functions) and even simple meta-programming. > Here is a quick example program to give a flavor for how it works. > > [1 2 3 4] [dup *] map == [1 2 3 4] [square] map > > is the same as Haskell's > > map (\x->x*x) [1,2,3,4] == map square [1,2,3,4] > [..] They say FP language and internal language of Miranda (S, K combinators) also avoid variables. What is the difference to Joy? I thought it may be a good strategy for a compiler to get free of variables, but it is hard for a programmer to write programs avoiding variables. Is Joy programming a joy? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: RFC: GUI Library Task Force
by cwitty＠newtonlabs.com 24 Sep '01

24 Sep '01

"Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > + More sophisticated approaches (that often require > language extensions or are still experimental) can be > implemented on top of this basic API - eg, FranTk, > Yahu, Fruit, iHaskell, etc. I keep seeing references to Fruit (as a "functional" Haskell GUI) but I can't find any real information about it. Is there a web page for it? Carl Witty

3 2