- Haskell - Haskell.org

RE: Gtk and Object I/O
by Simon Peyton-Jones 20 Jan '03

20 Jan '03

| going to stop gtk+hs because of this". So it seems we are all | waiting for the critical user mass that makes our own beloved | GUI library (binding) the standard GUI library. For the sake | of Haskell, we can only hope that this will actually happen | one day. A sad side-effects of this is that most of us GUI | developers waste a tremendous amount of time. A paper is just | not worth the effort we put in writing the code. I don't think we are waiting for critical user mass. We're waiting for critical *designer/developer* mass! Before Haskell existed, there were half a dozen not-very-good lazy functional languages, roughly one for each research group. Haskell was born out of the realisation that our efforts were fragmented and duplicated by this language diversity. Perhaps the situation with GUIs today is similar. What is necessary is for those who are enthusiastic about developing GUI technology to get together and hammer out a common design; and then co-ooperate in implementing and supporting it. The hard bit is for everyone to compromise enough to agree a common design. For that to be feasible you either need a fair consensus on the broad outlines, or enough frustration with the costs of diversity that everyone is prepared to make substantial compromises. I sense that the latter condition may hold. I'm not sure about whether there's a consensus on what a GUI library should look like to the programmer, but at least the current diversity means that there are quite a few more-or-less worked-out designs to serve as concrete starting points. Speaking as a potential user of such a library, I would absolutely love to have a Haskell GUI library that was available in some form on each major platform was supported by a bunch of people, so I could have some confidence in its continued existence Its exact capabilities are less important: (a) I'd adapt my program to fit what was available, and (b) I'm sure it would evolve in response to user feedback. I'd accept compromises in functionality to gain portability; it'd be OK to have some platform-specific sexy bits. Worse is better. As Manuel says, this process is already under way: the GUI task force. http://haskell.org/communities/11-2001/html/report.html#sect4.3.1 But not much is happening on gui(a)haskell.org. Well, nothing actually. Most of the 63 people subscribed to the list are (like me) lurkers. But I bet that a small subset are knowledgeable enough and motivated enough to do the job. My main purpose, in writing this over-long message, is to say again what a big service to the community it would be to agree a common design and to implement it. Simon

2 1

Re: Gtk and Object I/O
by Krasimir Angelov 18 Jan '03

18 Jan '03

--- Axel Simon <A.Simon(a)ukc.ac.uk> wrote: > Hi Krasimir, > > In the last two years I have implemented a binding > of Gtk Version 2 to > Haskell. I read the first paper about Object I/O of > Peter Achten and Simon > PJ which was published in IFL'00. I wondered if I > could supply a layer > like that of Object I/O to my library to get away > from the raw monadic > feeling whenever possible. I don't know how far you > got to use Gtk but I > assume there are mayor obstacles in creating a > native interface to Windows > and Gtk at the same time. Since I managed to get my > binding running on > Windows recently (no MSI installer yet), I thought > it could be worthwhile > considering Gtk as a single backend to Object I/O. > > Could you give me some hints as if that is > useful/possible? Also > references to the most relevant papers would be good > to get me started. > > Thank you in advance, > Axel. > Dear Axel, The Object I/O development is currently frozen. The native Win32 backend works but maybe still have bugs. I still support the library but only for bugfixes. I tried develop GTK backend for Object I/O but I found many difficulties. The main trouble is that the original Clean library are developed only for Windows. I think that Object I/O must be rewriten from scratch to make it more portable. For that reason I started my new project HToolkit (http://sourceforge.net/projects/htoolkit) The project maintain both GTK and native Win32 API. The library are separated in two levels. The low level is written in C and has two versions: for Win32 and for GTK. I think that the low level part are mostly completed (about 80-90% of GUI related Win32 and GTK API). The last week Daan Leijen started development of Port library. This is very thin Haskell layer over the low level C part. The idea is to make it reusable in other high level GUI libraries. After its completion I will retarget HToolkit to use Port. I hope that for the feature the Port will be ported to Mac platform. I think that for the time being developers which want to use Haskell for development of large scale projects are a trouble. There are nine known GUI libraries: * Gtk+HS * iHaskell * Gtk2HS * HTk * TclHaskell * Fudgets * FranTk * Object I/O * Yahu None of them are capable for large scale development for some reason. The HTk, TclHaskell, FranTk and Yahu are based on Tcl/Tk. The Tcl/Tk backend are portable but slow. The Gtk+HS, iHaskell, Gtk2HS are based on GTK. The backend is powerful and portable (GTK >= 2.0) but I prefer to use just native libraries on different platforms. The Object I/O is Win32 specific. I think that there are need of one portable and efficient library. It needs to have advantages of existing library but must have single uniform interface. I post this message to haskell(a)haskell.org because I think that development of nice libraries requires agreement of the entire Haskell Community on basic design lines. I looking for peoples which are interested in the development of "standard" GUI library. Best regards, Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

4 4

Limitations of "maximum"
by Kim-Ee Yeoh 17 Jan '03

17 Jan '03

A newbie question: In Hugs, why does "maximum $ replicate n 0" require space linear in n whereas "sum $ replicate n 0" appears to have no such limit (in the sense that we don't get "ERROR - Garbage collection fails to reclaim sufficient space")? The standard prelude defines both as basically foldl's -- maximum is actually foldl1 max, so I'm a little confused here. GHCi appears to require linear space for sum as well. I guess the real question to ask is: is there a constant space version of maximum, perhaps using strictness annotations? Regards, Kim-Ee

1 0

avoiding cost of (++)
by Hal Daume III 17 Jan '03

17 Jan '03

I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like: > mapWithout :: ([a] -> b) -> [a] -> [b] > mapWithout f = mapWith' [] > where mapWith' pre [] = [] > mapWith' pre (x:xs) = f (pre ++ xs) : mapWith' (x:pre) xs Unfortunately, this is very slow, due to the overhead of (++). Any way I could speed this up would be great. Note that order doesn't matter to 'f', but I do need that the order in which the elements of the list are processed be the same as in map. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

9 9

Re: avoiding cost of (++)
by johnvg＠cs.kun.nl 17 Jan '03

17 Jan '03

Hal Daume III wrote: >I have a function which behaves like map, except instead of applying the >given function to, say, the element at position 5, it applies it to the >entire list *without* the element at position 5. An implementation looks >like: > >> mapWithout :: ([a] -> b) -> [a] -> [b] >> mapWithout f = mapWith' [] >> where mapWith' pre [] = [] >> mapWith' pre (x:xs) = f (pre ++ xs) : mapWith' (x:pre) xs > >Unfortunately, this is very slow, due to the overhead of (++). > >Any way I could speed this up would be great. Note that order doesn't >matter to 'f', but I do need that the order in which the elements of the >list are processed be the same as in map. The following version is probably faster: mapWithout f [] = [] mapWithout f l = map_without l [] [] where map_without [e] t t2 = f t:t2 map_without [e1,e2] t t2 = f (e2:t):f (e1:t):t2 map_without l t t2 = map_without l1 (l2++t) (map_without l2 (l1++t) t2) where (l1,l2) = splitAt (length l `div` 2) l Regards, John van Groningen

1 0

Re: avoiding cost of (++)
by Zdenek Dvorak 16 Jan '03

16 Jan '03

Hello, >I have a function which behaves like map, except instead of applying the >given function to, say, the element at position 5, it applies it to the >entire list *without* the element at position 5. An implementation looks >like: > > > mapWithout :: ([a] -> b) -> [a] -> [b] > > mapWithout f = mapWith' [] > > where mapWith' pre [] = [] > > mapWith' pre (x:xs) = f (pre ++ xs) : mapWith' (x:pre) xs > >Unfortunately, this is very slow, due to the overhead of (++). > >Any way I could speed this up would be great. Note that order doesn't >matter to 'f', but I do need that the order in which the elements of the >list are processed be the same as in map. two remarks: 1) as long as f works on single list, there is no way how to make things faster (IMHO) 2) this solution is up to constant factor optimal due to laziness (at most one step of ++ will be evaluated for each element f needs) Zdenek Dvorak _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

EuroPar 2003, Topic 10 (CfP)
by Ch. A. Herrmann 16 Jan '03

16 Jan '03

Apologies if you receive multiple copies of this message. ----------------------------------------------------------------------- ****************************************************** *** *** *** SECOND CALL FOR PAPERS *** *** Submission Deadline: February 9, 2003 *** *** *** *** EURO-PAR 2003 Topic 10 *** *** Parallel Programming: Models, Methods and *** *** Programming Languages *** *** *** *** Klagenfurt, Austria *** *** August 26-29, 2003 *** *** *** *** http://europar-itec.uni-klu.ac.at/ *** *** *** ****************************************************** Description This topic provides a forum for the presentation of the latest research results and practical experience in the development of parallel programs. Advances in algorithmic and programming models, design methods, languages, and interfaces are needed to produce correct, portable parallel software with predictable performance on different parallel and distributed architectures. The topic emphasises results that improve the process of developing high-performance programs, including high-integrity programs that are scalable with both problem size and complexity. Of particular interest are novel techniques by which parallel software can be assembled from reusable parallel components without compromising efficiency. Related to this is the need for parallel software to adapt, both to available resources and to the problem being solved. Where appropriate, contributions should demonstrate quantitative performance results in support of their claims, and address applications not adequately handled by well-established approaches. Focus * Languages, libraries and interfaces for different parallel programming models (e.g. data-parallelism, task-parallelism, functional, object-oriented, logic, component-based etc.). * Implementation and optimisation techniques for innovative parallel languages and programming models (e.g. threads, dataflow, tiling, skeletons, declarative languages, and generalised data-parallel approaches, etc.). * Performance models and their integration into the design of efficient parallel algorithms and programs (e.g. BSP, LogP, CGM, N-half and their alternatives, cost calculi and static performance prediction, profile-driven approaches). * Parallel programming paradigms and tools, their comparison and integration (e.g. data-parallel vs. task-parallel, coordination programming, performance analysis and debugging). * Methodological aspects of developing, optimizing and validating parallel programs (formalisms, semantics, specification, design, transformations, verification, etc.). * Software engineering for parallel and distributed systems (design patterns, portability, robustness, standardization, etc.). * Systematic approaches and programming models to support effective program development in grid environments. * Domain-specific parallel libraries and languages (e.g. for simulation, irregular and unstructured meshes, computational geometry, etc.). ----------------------------------------------------------------------- KEY DATES November 8, 2002 First call for papers February 9, 2003 Final date for submissions May 1, 2003 Notification of acceptance July 15, 2003 Early registration deadline ----------------------------------------------------------------------- PC COMMITTEE Global Chair Prof. José C. Cunha New University of Lisbon, Portugal Email: jcc(a)di.fct.unl.pt Vice Chairs Dr. Marco Danelutto University of Pisa, Italy Email: marcod(a)di.unipi.it Prof. Peter H. Welch University of Kent, United Kingdom Email: P.H.Welch(a)ukc.ac.uk Local Chair Dr. Christoph Herrmann Universität Passau, Germany Email: herrmann(a)fmi.uni-passau.de ----------------------------------------------------------------------- SUBMISSION DETAILS Authors are requested to submit their papers by using our submission site http://europar-itec.uni-klu.ac.at/submission.html (please indicate TOPIC 10). The site will open not later than at the beginning of January 2003. All accepted papers will be available at the conference in the proceedings published by Springer-Verlag in the LNCS series. ----------------------------------------------------------------------- MISSION STATEMENT EURO-PAR Euro-Par is the annual series of international conferences dedicated to the promotion and advancement of all aspects of parallel and distributed computing. Euro-Par 2003 will represent 19 topics in the categories of hardware, software, algorithms and applications. The conference normally attracts more than 300 participants coming from universities, research centres and industry. ---------------------------------------------------------------------- We are looking forward to receiving your paper submissions. Best regards -- Dr. Christoph Herrmann Teaching and Research Assistant University of Passau, Germany http://www.fmi.uni-passau.de/~herrmann

1 0

dynamic types
by Richard Uhtenwoldt 15 Jan '03

15 Jan '03

Just want to make sure I understand. There does not exist a Haskell implementation-specific extension which provides the sort of dynamic type that would allow one to discriminate at run time between built-in types; right? eg, main=do object<-readLn case object of --or some such syntax ()->putStrLn "void type detected" (a::Integer)->putStrLn "Integer type detected" For those readers whose prelude is rusty, I quote from the prelude: readLn :: Read a => IO a readLn = do l <- getLine r <- readIO l return r And even if the object being discriminated "lacks polymorphicity", eg, this next, that does not change the answer to my question; right? main=do command<-readLn let object=case command of "Integer"->(5::Integer) "Void"->() case object of ()->putStrLn "void type detected" (a::Integer)->putStrLn "Integer type detected"

7 9

[OT] Haskell-related internships
by Hal Daume III 14 Jan '03

14 Jan '03

Hi all, There is a rather small section on the Haskell web page dedicated to Haskell in industry, but my guess is that it's both somewhat outdated and somewhat incomplete. I'm hoping to be able to scavenge a bit more information off this list. Basically, I'm looking into the possibility of finding a Haskell (or, perhaps, FP-en-large) related internship for this coming summer (for a graduate student whose field is not PLs, but who is quite familiar with the territory). If anyone is thinking of offering anything of that sort, and you could let me know, that would be great. Whether the position is in industry or academia doesn't particularly matter to me. Sorry for the general post; please reply to me directly if you know of anything. Thanks! - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

Re: Field labels must be globally unique?
by cwitty＠newtonlabs.com 14 Jan '03

14 Jan '03

"Marc Ziegert" <coeus(a)gmx.de> writes: > --------------------It would be nice to be able to overload class-functions like classes: > > instance (+), (-) -> Vector where > (+) v1 v2 = ... > (-) v1 v2 = ... > > --------------------instead of overloading parts of a class... (because of runtime-errors!) This seems related to "System CT" (http://www.dcc.ufmg.br/~camarao/CT/) In System CT, everything is (potentially) overloaded, and you don't have explicit type classes. Carl Witty cwitty(a)newtonlabs.com

1 0