January 2001 - Haskell-Cafe

Re: gui building in haskell
by Ashley Yakeley 16 Jan '01

16 Jan '01

At 2001-01-15 11:24, Jan Kort wrote: >When Manuel's Haskell GTK+ binding (gtkhs) is finished it will >be really cool. > >On top of gtkhs there are/will be many other libraries and tools: >- iHaskell: a high level GUI library that avoids the eventloop > mess. >- GtkGLArea: 3D graphics in your GTK+ application using Sven's HOpenGL. >- GUI painter: All you need is a backend for Glade. I'm currently > working on this. Or at least I was half a year ago, other (even > more interesting) things claimed most of my spare time. Would some kind Haskell-to-Java bridge be a cost-effective way of providing a multi-platform GUI library, as well as network, SQL, RMI etc., etc.? It doesn't necessarily imply compiling to the JVM. Java could simply see the compiled Haskell code through the JNI. -- Ashley Yakeley, Seattle WA

3 2

Re: Are fundeps the right model at all?
by qrczak＠knm.org.pl 15 Jan '01

15 Jan '01

Thanks for the reply! Mon, 15 Jan 2001 02:01:18 -0800, Mark P Jones <mpj(a)cse.ogi.edu> pisze: > 1) "A weaker notion of ambiguity" (title of Section 5.8.3 in my dissertation, > which is where I think the following idea originated): We can modify the > definition of ambiguity for certain kinds of class constraint by considering > (for example) only certain subsets of parameters. In this setting, a type > P => t is ambiguous if and only if there is a variable in AV(P) that is not > in t. The AV function returns the set of potentially ambiguous variables in > the predicates P. It is defined so that AV(Eq t) = TV(t), but also can > accommodate things like AV(Has_field r a) = TV(r). A semantic justification > for the definition of AV(...) is needed in cases where only some parameters > are used; this is straightforward in the case of Has_field-like classes. > Note that, in this setting, the only thing that changes is the definition > of an ambiguous type. This is exactly what I have in mind. Perhaps extended a bit, to allow multiple values of AV(P). During constraint solving unambiguous choices for the value of AV(P) must unify to a common answer, but ambiguous choices are not considered (or something like that). I don't see a concrete practical example for this extension yet, so it may be an unneeded complication, but I can imagine two parallel sets of types with a class expressing a bijection between them: a type from either side is enough to determine the other. This is what fundeps can do, basic (1) cannot, but extended (1) can - with a different treatment of polymorphic types than fundeps, i.e. allowing some functions which are not necessarily bijections. > - When a user writes an instance declaration: > > instance P => C t1 ... tn where ... > > you treat it, in the notation of (2) above, as if they'd written: > > instance P => C t1 ... tn > improves C t11 ... t1n, ..., C tm1 ... tmn where ... > > Here, m is the number of keys, and: tij = ti, if parameter i is in key j > = ai, otherwise > where a1, ..., an are distinct new variables. Sorry, I don't understand (2) well enough to see if this is the case. Perhaps it is. > - Keys will not give you the full functionality of functional dependencies, > and that missing functionality is important in some cases. And vice versa. Plain fundeps can't allow both Has_parens r a => r as an unambiguous type and Has_parens TokenParser (Parser a -> Parser a) as an instance. > PS. If we're going to continue this discussion any further, let's > take it over into the haskell-cafe ... OK. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
by Sebastian Schulz 10 Jan '01

10 Jan '01

"Benjamin L. Russell" wrote: > > On Tue, 9 Jan 2001 09:00:27 +0100 (MET) > Johannes Waldmann <joe(a)isun.informatik.uni-leipzig.de> wrote: > > > > This could be driven to the extreme: not only hide the > > word "monad", > > but also "functional". The title would be "Imperative > > programming in Haskell" > > (as S. Peyton Jones says in Tackling the Awkward Squad: > > "Haskell is the world's finest imperative programming > > language"). > > Couldn't this choice potentially backfire, though? For example, many people choose Java over C because they prefer OO to straight imperative programming, which they see at The Old Way. > > If I went to a bookstore and saw one book entitled, "Imperative Programming in Haskell," and another entitled, "OO Programming in Java," I wouldn't buy the Haskell book, especially if had already had a bad experience with imperative programming in C. > > How about, "The Post-OO Age: Haskell: Back to the Future in Imperative Programming"? I didn`t follow this discussion very closely, but: Hey! What`s so evil in the word "functional"??! Haskell was the first language I learned (to love;-) and for me it's more difficult to think imperative (e.g. when I have to do some homework in Java). In that bookstore, I would buy a book "Functional Programming in Java" :) . But serious, I don`t think that it is good to hide the fact that Haskell is a functional Language. Nobody will realize how comfortable and elegant the functional way is, when he is still thinking: "Wow, how complicate to program imperative with this functional syntax". regards Sebastian

1 0

RE: Hugs
by Mark P Jones 10 Jan '01

10 Jan '01

| I've currently installed Hugs on my PC, could you tell me how | I can configure Hugs to use an editor. The editor I have got | installed on my computer is winedt. This question is answered in the Hugs manual, Section 4 (or pages 11-13 in the pdf version). Please note also that questions that are about using Hugs should be sent to the hugs-users mailing list, and not to the Haskell list. All the best, Mark

1 0

Re: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
by Johan Nordlander 08 Jan '01

08 Jan '01

Tom Pledger wrote: > > Marcin 'Qrczak' Kowalczyk writes: > [...] > > My new record scheme proposal does not provide such lightweight > > extensibility, but fields can be added and deleted in a controlled > > way if the right types and instances are made. > > Johan Nordlander must be on holiday or something, so I'll deputise for > him. :-) No holiday in sight, I'm afraid :-) I just managed to resist the temptation of throwing in another ad for O'Haskell. But since my name was brought up... > O'Haskell also has add-a-field subtyping. Here's the coloured point > example (from http://www.cs.chalmers.se/~nordland/ohaskell/survey.html) > > struct Point = > x,y :: Float > > struct CPoint < Point = > color :: Color > > Regards, > Tom Notice though that O'Haskell lacks the ability delete fields, which I think is what Marcin also proposes. I've avoided such a feature in O'Haskell since it would make the principal type of an expression sensitive to future type declarations. For example, assuming we have f p = p.x , its principal type would be Point -> Float if only the type definitions above are in scope, but OneDimPoint -> Float in another scope where some type OneDimPoint is defined to be Point with field y deleted. -- Johan

1 0

Haskell Language Design Questions
by Tom Pledger 08 Jan '01

08 Jan '01

Doug Ransom writes: [...] > 2. It seems to me that the Maybe monad is a poor substitute for > exception handling because the functions that raise errors may not > necessarily support it. It sometimes helps to write such functions for monads in general, rather than for Maybe in particular. Here's an example adapted from the standard List module: findIndex :: (a -> Bool) -> [a] -> Maybe Int findIndex p xs = case findIndices p xs of (i:_) -> Just i [] -> Nothing It generalises to this: findIndex :: Monad m => (a -> Bool) -> [a] -> m Int findIndex p xs = case findIndices p xs of (i:_) -> return i [] -> fail "findIndex: no match" The price of the generalisation is that you may need to add some type signatures to resolve any new overloading at the top level of the module. Regards, Tom

1 0

RE: Extending the do-notation
by Simon Peyton-Jones 08 Jan '01

08 Jan '01

| Another question concerning the do-notation: I noticed | that most parts of ghc do not use it. Is it because | the code was written before the notation was available, | because the do-notation is too weak to express these | parts, or for another fundamental reason ? The former: mostly written before do-notation existed. We're gradually migrating! Simon

1 0

Re: Extending the do-notation
by Sebastien Carlier 08 Jan '01

08 Jan '01

> > I'm constantly amazed by the number of tricks one has > > to know before he can write concise code using the > > do-notation (among other things, I used to write > > "x <- return $ m" instead of "let x = m"). > [snip] > Why do you WANT to write concise code using the do-notation? > Has someone revived the Obfuscated Haskell Contest, or > do you find touch-typing difficult? Which of the following is easier to read (and please forgive the short variable names) ? > x <- return $ m or > let x = m > x <- m > let (a, b) = unzip x > ... -- (and this code uses an extra variable) or > (a, b) <- unzip `liftM` m Concise does not mean obfuscated. Unnecessarily inflating your code will not make it more readable. Or am I wrong ?

1 0

more HDirect confusion
by Eric Allen Wohlstadter 06 Jan '01

06 Jan '01

Things that are popping up when I try to use HDirect: 1. I don't have a "com" directory under "ghc/lib/imports". So, I made one and copied the files from "hdirect-0.17/lib" into it. I don't know if that's right. 2. I don't have a "misc" package anywhere. The makefiles complain about "-syslib misc". 3. I don't have a file called "HScom_imp.a". ld complains about "-lHScom_imp.a". I thought I installed everything correctly. I did "make boot", and then "make", and then "make lib". Thanks, Eric

1 0

RE: Learning Haskell and FP
by Doug Ransom 05 Jan '01

05 Jan '01

> -----Original Message----- > From: Michael Zawrotny [mailto:zawrotny@gecko.sb.fsu.edu] > Sent: Friday, January 05, 2001 8:01 AM > To: haskell-cafe(a)haskell.org > Subject: Re: Learning Haskell and FP > > > "Benjamin L. Russell" <russell(a)brainlink.com> wrote > > Michael Zawrotny <zawrotny(a)gecko.sb.fsu.edu> wrote: > [snip] > > > > > > The thing that I would most like to see would entitled "A > > > Practical Guide to Haskell" or something of that nature. > > > > > > [snip] > > > > > > One is tempted to come to the conclusion that Haskell is > > > not > > > suited for "normal" programmers writing "normal" > > > programs. > > > > How would you define a "'normal' programmer writing > 'normal' programs?" What > > exactly is a "'normal' program?" > > That was sloppy on my part. My message was getting long, so I used > "normal" as a short cut. I should know better after seeing all of > the flamewars about whether or not FP is suitable for "real" work. > > What I meant by "normal programmer" was (surprise) someone > like myself. > I.e. someone who doesn't have much, if any background in > formal logic, > higher mathematics, proofs of various and sundry things, etc. I agree here. Todays software engineers take the tools at their disposal to make systems as best they can at the lowest price they can. The FP documentation is not ready -- it is still in the world of academics. The tools are also not there. The problem is not that working programmers can not understand necessary theory to apply techniques. We certainly do not have the time to go through all sorts of academic papers. We do have the time to take home a text book and read it over a few weekends. What we need is to be spoon fed the important knowledge (i.e. in a single textbook). The various Design Pattern catalogs do this for OO. FP is a little more complicated, but I think there is much potential to get more work done in the same time if we could learn to apply it. > > By "normal program" I meant things like short utility programs that > I might otherwise write in shell, python, perl, etc. or data > extraction > and analysis programs that I might write in in python, perl, C or C++ > depending on the type of analysis. For the sake of diversity, a normal program to me inludes everything from XML processing (which I do a fair bit), database manipulation, delivery of historical and current (i.e. "real time" or immediate values) to users, and this one is real key: scalable programs for 3 tiered architectures. The last one is real interesting. For those familliar with COM+ or MTS (or the Java equivelent), the middle or business tier typically contains objects which behave as functions -- when a client calls a middle tier object, the state of that middle tier object is cruft once the call completes. I think what is called "business logic" in the "real world" of delivering systems would be an excellent place to us FP. > > > (Perhaps another way of phrasing the issue is as the > "declarative" vs. "proce > > dural" distinction, since the issue seems to be that of > "what is" (types) vs. > > "how to" (imperative expression; i.e., procedures).) > > Although there is some of that, for me at least, the types aren't a > big deal. The main thing for me is figuring out how to actually get > something done. Most of the things I've read have had tons of really > neat things that you can do with functional abstractions, but it's all > ... abstract. I would love to see something that is more > about getting > things done in a how-to sense, including IO. Much of the > material I've > seen tends to either relegate IO and related topics into a > small section > near the end (almost as if it were somehow tainted by not being able > to be modelled as a mathematical function), or it goes into it talking > about monads and combinators and things that make no sense to me. > > > While I agree that "A Practical Guide to Haskell" would > indeed be a suitable > > alternative for programmers from the procedural school of > expression, I would > > caution that such an introduction would probably not be > suitable for all. > > This is very true. I think that there is plenty of material > that would > be helpful for an SMLer to learn Haskell, but not much for someone who > was was only familiar with with C or who was only comfortable with FP > to the extent of understanding lambdas, closures and > functions as values, > but none of the more esoteric areas of FP. I'm advocating something > along the lines of the "Practical Guide" I mentioned or the "Nutshell" > book below. > > > Perhaps, ideally, two separate tutorials (or perhaps a > single tutorial with t > > wo sections based on different viewpoints?) may be needed? > The difficulty is > > that the conceptual distance between the declarative and > procedural schools > > of thought seems too great to be bridged by a single > viewpoint. It seems tha > > t any introduction favoring either one would risk > alienating the other. > > I agree that any single tutorial would be able to target both > audiences. > > > Personally, I would really prefer "A Gentle Elementary > Introduction to Haskel > > l: Elements of the Haskell School of Expression with > Practical Examples," bu > > t some would no doubt choose "Haskell in a Nutshell: How > to Write Practical > > Programs in Haskell." > > I'm definitely the "Nutshell" type. If it were published, I'd buy > it in a heartbeat. That's why it would be good to have both, everyone > would have one that suited their needs. > > I'd like to say a couple things in closing, just so that people don't > get the wrong idea. I like Haskell. Even if I never really write any > programs in it, trying to learn it has given me a different way of > thinking about programming as well as exposing me to some new ideas > and generally broadening my horizons. My only problem is that I just > can't seem to get things done with it. Please note that I am not > saying here, nor did I say previously that it isn't possible to do > things in Haskell. Obviously there are a number of people who can. > I am simply saying that I am having trouble doing it. I would also > like to mention that I really appreciate the helpful and informative > tone on the list, especially on a topic that, even though not intended > that way, could be considered critical of Haskell. > > > Mike > > -- > Michael Zawrotny > 411 Molecular Biophysics Building > Florida State University | email: zawrotny(a)sb.fsu.edu > Tallahassee, FL 32306-4380 | phone: (850) 644-0069 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0