- Haskell - Haskell.org

A GUI toolkit looking for a friend
by Simon Peyton-Jones 31 Mar '01

31 Mar '01

Gentle Haskellers This message is to invite offers to complete a promising port of the Clean Object I/O library to Haskell. As you know, there are quite a few GUI toolkits for Haskell, but none of them has become a de-facto standard. One confusing aspect is that there are different "levels": (see http://haskell.org/libraries/#guigs) * Low-level veneers on top of existing libraries. HOpenGL, GTK, TclHaskell, the Win32 library, all fall into this category. They are rich, but hard to use because you have to adopt the programming model of the library, which is usually very imperative. * Very high-level systems, such as Fudgets, Haggis, FranTk. These are rather sophisticated and (esp Fudgets, FranTk) attempt to break with the imperative programming model. But I don't think any of them has been acclaimed as The Right Way To Do It. We're still looking! * Strangely, there are very few "in the middle" systems. One might hope for an interface that was somewhat independent of the low-level library, and somewhat more Haskell friendly, than the low-level veneers, but not as ambitious as the high-level systems. On top of that, some libraries deal in graphical user interfaces (buttons, menus..) and some deal in graphics (pictures, lines, shading). I think we should encourage the development of more "in the middle" systems. One example is Koen Claessen's Yahu system, http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/yahu.html However, there is another functional language that has put years of development into a GUI library: Clean. The Clean Object I/O library is well-documented and the Clean team have had a lot of experience in using it. It runs on both Windows and Mac, but not currently on Unix. http://www.cs.kun.nl/~clean/About_Clean/page_modified/page_modified.html Maybe we should build on their experience! Peter Achten, its author, spent a few weeks in Cambridge, porting the Clean library to Haskell. The results are very promising. The main ideas come over fine, translating unique-types to IO monad actions, and the type structure gets a bit simpler. So what we need now is to complete the port. Peter didn't have time to bring over all the widgets, nor did he have time to clean up the Haskell/C interface. (Clean's FFI is not as well-developed as Haskell's, so the interface can be made much nicer.) The other significant piece of work would be to make it work on Unix, perhaps by re-mapping it to GTK or TkHaskell or something. So the main burden of this message is: Would anyone be interested in completing the port? Fame (if not fortune) await you! The prototype that Peter developed in is the hslibs/ CVS repository, and the GHC team would be happy to work with you to support your work. (The more compiler-independent we can make the library, the better.) Peter Achten is willing to play consultant too. The Clean team are happy for the code to be open source -- indeed, all the hslibs/ code is BSD-licensed. It would not be the work of a moment. There are subtle issues involved (especially involving concurrency), and the design is not complete, so it isn't just boring hacking. So it should fun. Anyone interested? Maybe more than one person could work on it together. [And are there any other "in-the-middle" libraries I've overlooked?] Simon

3 2

RE: FixIO/ Tackling Awkward Squad
by Simon Peyton-Jones 31 Mar '01

31 Mar '01

| Dear Haskellers, | After enjoying "Tackling the Awkward Squad" (Simon | Peyton Jones), I wonder what other elements of the | squad can be tackled in a simular way? Right now I am | thinking about FixIO. This little bugger seems to show | up in a lot of code! Can we give it an operational | semantics a la Tackling the awkward squad? I am quite | stumped on this one, so i wont event post my meager | attempts, but rather hope someone brighter then me | will :) We need to add a new Value "FixIO N"... I'd be inclined to do it like this: fixIO m = do { v <- newEmptyMVar ; result <- m (unsafePerformIO (takeMVar v)) ; putMVar v result ; return result } Of course, this just begs the question of what exactly unsafePerformIO might mean, and we can only really answer that when we give an operational semantics to the functional part of the language as well as the imperative part. But perhaps the meaning of fixIO becomes clearer with the above. (Of course an implementation is free to implement it some other way too.) Simon

6 12

Re: question class tree
by Matthias Fischmann 31 Mar '01

31 Mar '01

Cris Okasaki [http://www.cs.columbia.edu/~cdo] has written tons of papers on functional data structures, I guess you can steal code from there. There was also a file containing all the examples from his book `Purely Functional Data Structures' (Cambridge University Press, 1998, and everybody sais it's a must although I haven't seen it yet). Unfortunately, I could not find it any more. Matthias Maldonado Castiblanco Camilo Ernesto <2003250(a)mail.escuelaing.edu.co> writes: > I need a class tree for haskell. where can i find it? > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- Matthias Fischmann | Research Engineer | +358 (9) 8565 7474 fis(a)ssh.fi | SSH Communication Security Corp | +358 (40) 752 5291

1 0

Parameterising Class Constraints in Existential Types
by Ashley Yakeley 30 Mar '01

30 Mar '01

Is this valid (extended) Haskell? -- class MyClass a b where foo :: a -> b -> Int data Special = forall b. (MyClass Int b)=> MkSpecial b data General a = forall b. (MyClass a b)=> MkGeneral b -- Hugs complains about the 'General' line but has no problem with the 'Special' line... -- Ashley Yakeley, Seattle WA

2 1

Re: constants and functions without arguments
by Andreas Leitner 30 Mar '01

30 Mar '01

Tom Pledger wrote: > > Andreas Leitner writes: > : > | Given a lazy pure functional language do we need to differntiate > | (in syntax) between constants and functions without agruments? And > | if we don't need to, does Haskell make a difference? > > Haskell always treats a declaration of the form > > foo = ... > > as a pattern binding, not as a function binding. Sections 4.4.3 and > 4.5 of the Haskell 98 report give more details. > > So, in that sense, every function in Haskell takes an argument. > There's nothing to prevent you from adding a dummy parameter to turn a > constant (i.e. a simple pattern binding) into a function. The only > reason I've heard for doing so, is to work around the monomorphism > restriction. Exactly thats' the reason for my question: Overcome ther monomorphism. I come from an Eiffel background and there we have the uniform access principle, which is a very important thing in that world. It means that you access an attribute just like a function with no parameters. This is actually a form of information hiding as you can change the underlying implementation (an attribute to a function and vice versa). The classic examlple for this is class POINT, which has an interface like that: -- POINT -- group 1 x: DOUBLE y: DOUBLE -- group 2 rho: DOUBLE abs: DOUBLE -- Now, you can choose to either implement group 1 as attributes, or group 2 and calculate the other one. With the uniform access principle, which says that accessing attributes and functions with no arguments happen in the same syntactic way, you can change the implementaion without notice. No user of this class needs to know. I am to new to FP to say whether this is equaly important in FP-languages, since the semantics are different (constants vs. attributes and immutable values vs. objects), but for now I am just currious wether it is possible theoretically. I mean couldn't one say that there are no constants, just functions with no arguments or the Void/Unit argument that return an expression. Since we have lazy evaluation, there won't be a problem at runtime, but would the type system allow such a thing? tia, Andreas

2 1

beginners silly question
by Luc taecsh 30 Mar '01

30 Mar '01

<intro> Ive just decided to start with haskell (after a decade of OO, and a few month of erlang (already impressive)) despite i love linux, id like to stay with wintel, to be able to use it at the office, and try to slot it in my daily job, slowly. (doing some modeling, should be useful) </intro> 1)are there a full package of haskell over there ? 2)ive installed hugs, SOE libs, haxml, frantk, tcl/tk, g/hood, hdoc, and jcreator what am i missing ? any incompatiblities +98 -98, and so on ? 3)if i get some good stuff done, id like to compile them , as small utilitaries. (best way to turn H in my daily job) my first try at ghc was not that fun (deppendencies on gcc, libs, and so on) as a alternative, ive tried under linux (m7.2),where ghc is installed by default, but even here , were i was expecting fluentness, its not cristal clear, hangs, missing bits i dont understand. no samples/ demo ? or is it a packaging issue ? <whining> 4) generally, are there any project to have some ready to use all-included package ? i understans some effort are under way on the great lib side, but are there anything avaialble now (its still farther than for me) for info, in the eiffel world, some guy (elj) once tried to put all the stuff together in a click and install package, and it really helped the gnu eiffel stuff starting in win world, (where things are not so simple , when unix is assumed with gnu stuffs...) (if some think answering DIY, just think its what effectivelly happen^s everytime, everywhere in the world someone goes beyong haskell.org front page... but all u haskell people are too smart for me to mention that.. ;-) </whining>

1 0

constants and functions without arguments
by Andreas Leitner 30 Mar '01

30 Mar '01

Hi, I hope this is the right forum to post my question to. Given a lazy pure functional language do we need to differntiate (in syntax) between constants and functions without agruments? And if we don't need to, does Haskell make a difference? In a language with eager evaluation (let's take SML) we must differentiat. Given we have a function that takes one argument of type int, is different than a function that takes unit->int. Because of that in SML, whenever I have a function (say "h") that takes an int, and I want to apply a function (without arguments), let's call it g) on it I need to add "()" at the end. h g() but for any constant i of type int I write: h i Now, this leads to my question: In a lazy language do I need to write those "()", or could the compiler tell the difference and always do the correct thing? many thanks in advance, Andreas

3 2

RE: communication between thread
by Simon Marlow 30 Mar '01

30 Mar '01

> I am using the library oncurrent of GHC. I'd like to know how two > different threads can communicate each other. > To solve the problem I thought in something like a global variable. If > there any method to avoid the use of that kind of variables > in haskell. You can use the various concurrent data structures in the Concurrent library. See: http://www.haskell.org/ghc/docs/latest/set/sec-concurrency-abstractions. html The simplest form of communication is through an MVar, which is a thread-safe mutable variable. Cheers, Simon

1 0

communication between thread
by Juan Ignacio García García 30 Mar '01

30 Mar '01

Hello, I am using the library oncurrent of GHC. I'd like to know how two different threads can communicate each other. To solve the problem I thought in something like a global variable. If there any method to avoid the use of that kind of variables in haskell. Thanks in advance J. I. García

1 0

RE: Parameterising Class Constraints in Existential Types
by Simon Peyton-Jones 30 Mar '01

30 Mar '01

It seems reasonable to me, and GHC is happy. Here's a working example: Simon class MyClass a b where foo :: a -> b -> Int data Special = forall b. (MyClass Int b)=> MkSpecial b data General a = forall b. (MyClass a b)=> MkGeneral b instance MyClass Int Bool where foo x False = -x foo x True = x xs :: [General Int] xs = [MkGeneral True, MkGeneral False] main = print [foo (3::Int) x | MkGeneral x <- xs] | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 29 March 2001 10:47 | To: Haskell List | Subject: Parameterising Class Constraints in Existential Types | | | Is this valid (extended) Haskell? | | -- | class MyClass a b where | foo :: a -> b -> Int | | data Special = forall b. (MyClass Int b)=> MkSpecial b | data General a = forall b. (MyClass a b)=> MkGeneral b | -- | | Hugs complains about the 'General' line but has no problem with the | 'Special' line... | | -- | Ashley Yakeley, Seattle WA | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell |

1 0