- Haskell-Cafe - Haskell.org

RE: Learning Haskell and FP
by Patrick M Doane 17 Jan '01

17 Jan '01

On Wed, 3 Jan 2001, Simon Peyton-Jones wrote: > I'm sure that's right. Trouble is, we're the last people qualified > to write one! > > Here's a suggestion: would someone like to write such a guide, > from the point of view of a beginner, leaving blanks that we can fill in, > when you come across a task or issue you don't know the answer > to? That is, you provide the skeleton, and we fill in the blanks. I read your paper on taming the Awkward Squad several months ago as my first exposure to Haskell. I think it is an excellent paper and really convinced me that Haskell was worthwhile to learn and use. There are aspects to the paper that are like a tutorial, but I think it would be overwhelming for a programmer not used to reading papers from academia. I think a really good beginner's tutorial on I/O could be started from this paper: - Start immediately with using the 'do expression' and don't worry about the history that led to its development. - Avoid mentioning 'monad' and other mathematical terms until much latter in the game. It is better to see the system in action and then find out it has a nice solid foundation. Many people are also annoyed by an author using new vocabulary even if it is well defined. It's better to get them comfortable with the system first. - Take advantage of the 2d syntax rules to avoid the unneeded braces and semicolons. Syntax with little punctuation seems to go a long way with many programmers. Pointing out the similarities to Python here could be appropriate. - After working through several examples, show that the 'do expression' is short hand for some more basic primitive operators. These can be more appropriate to use in some circumstances. - Conclude with explaining the difference between executing an action and building a value to execute the action. There is no need to point out that this is a requirement of being a lazy language. Instead point out the benefits such a system provides to back up the claim that Haskell truly is "the world's finest imperative programming language." Some points would still be difficult to get through: - Explaining the type system. There is no avoiding this, and users will have to learn it. - Working through the difference between 'unit' and 'void'. Perhaps this can be avoided in a beginning tutorial. A possible confusing example in the paper is that of composing putChar twice while throwing away the result. People used to C or Java might immediately think "but it doesn't have a result to through away!" - Some amount of understanding for Haskell expressions is going to be needed to understand examples. An I/O centric tutorial would want to explain as things go along as needed. I would avoid other parts of the paper for a first attempt at some new tutorial material. Any thoughts? I could take a first stab at this if people think it would be a useful direction. Patrick

6 5

Re: gui building in haskell
by Jan Kort 16 Jan '01

16 Jan '01

Matthew Liberty wrote: > > Greetings, > > I've been looking at http://www.haskell.org/libraries/#guis and trying > to figure out which package is "best" for building a gui. Can anyone > give a comparison of the strengths/weaknesses of these packages (or any > others)? Hi Matt, 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. Of course this will all take a while to come to a beta release. FranTk is currently the only high level interface that is in beta. There is no release for ghc4.08, but it takes only a day or so to get it working. In short: use FranTk now or wait a year and use gtkhs. The reason there are so many GUI libraries on the web page is that nothing ever gets removed. Most of the libraries are no longer supported. I only realized after making the table that it was a bit redundant, but since I spend 10 mins getting the stuff lined up properly (please don't tell me you have a proportional font) you'll have to suffer through it: +------------+--------+-------+-----+------+------+ | GUI lib | Status | Level | W98 | Unix | OS X | +------------+--------+-------+-----+------+------+ | TclHaskell | beta | low | yes | yes | | | Fudgets | alpha*)| high | no | yes | | | gtkhs | alpha | low | | yes | | | iHaskell | | high | | | | | FranTk | beta | high | yes | yes | | +------------+--------+-------+-----+------+------+ | Haggis | dead | high | no | yes | | | Haskell-Tk | dead | | | | | | Pidgets | dead | | | | | | Budgets | dead | | | | | | EmbWin | dead | | | | | | Gadgets | dead | | | | | +------------+--------+-------+-----+------+------+ *) I thought Fudgets was dead, but apparently it has been revived. You might want to check that out too, although it has the words "hackers release" all over it (literaly). Status: alpha/beta I guess "dead" sounds a bit rude. It means that I couldn't find a distribution or it would take too much effort to get it working. Level: low: Raw calls to C library. high: More functional style. W98: Wether it works on Windows 95/98/ME with ghc4.08. Unix: Same for Unix (Solaris in my case). OS X: Same for Macintosh OS X. Hope this helps, Jan

2 1

Re: O'Haskell OOP Polymorphic Functions
by Ashley Yakeley 16 Jan '01

16 Jan '01

At 2001-01-16 14:36, Tom Pledger wrote: >Here's a similar example using type-substitution overlapping: > > instance TheValue Char where ... > instance Monad m => TheValue (m Char) where ... > instance TheValue a => TheValue (Maybe a) where ... > > trouble = theValue (Just 'b') Apparently this is not good Haskell syntax. I tried compiling this in Hugs: class TheValue a where theValue :: a -> Int instance TheValue Char where theValue _ = 0 instance (Monad m) => TheValue (m Char) where theValue _ = 1 -- error here instance (TheValue a) => TheValue (Maybe a) where theValue _ = 2 trouble = theValue (Just 'b') I got a syntax error: (line 3): syntax error in instance head (variable expected) -- Ashley Yakeley, Seattle WA

1 0

Re: O'Haskell OOP Polymorphic Functions
by Ashley Yakeley 16 Jan '01

16 Jan '01

At 2001-01-16 14:04, Tom Pledger wrote: >The subtyping (struct Derived < Base ...) makes the two instances >overlap, with 'instance TheValue Derived' being strictly more specific >than 'instance TheValue Base'. If the system preferred the less >specific one, the more specific one would never be used. > >This is quite similar to the way overlapping instances are handled >when they occur via substitutions for type variables (e.g. 'instance C >[Char]' is strictly more specific than 'instance C [a]') in >implementations which support than language extension. Subtyping-overlapping is quite different from type-substitution overlapping. Consider: struct B struct D1 < Base = a1 :: Int struct D2 < Base = a2 :: Int class TheValue a where theValue :: a -> Int instance TheValue B where theValue _ = 0 instance TheValue D1 where theValue _ = 1 instance TheValue D2 where theValue _ = 2 struct M < D1,D2 m = struct a1 = 0 a2 = 0 f = theValue m What's the value of f? -- Ashley Yakeley, Seattle WA

2 1

Re: O'Haskell OOP Polymorphic Functions
by Tom Pledger 16 Jan '01

16 Jan '01

Ashley Yakeley writes: > At 2001-01-16 13:18, Magnus Carlsson wrote: > > >f1 = Just 3 > >f2 = f3 = f4 = Nothing > > So I've declared b = d, but 'theValue b' and 'theValue d' are different > because theValue is looking at the static type of its argument? > > What's to stop 'instance TheValue Base' applying in 'theValue d'? The subtyping (struct Derived < Base ...) makes the two instances overlap, with 'instance TheValue Derived' being strictly more specific than 'instance TheValue Base'. If the system preferred the less specific one, the more specific one would never be used. This is quite similar to the way overlapping instances are handled when they occur via substitutions for type variables (e.g. 'instance C [Char]' is strictly more specific than 'instance C [a]') in implementations which support than language extension. Regards, Tom

1 0

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

16 Jan '01

At 2001-01-16 02:48, Jan Kort wrote: >Ashley Yakeley wrote: >> 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. > >That sounds unlikely to me, how do you overide methods through JNI ? You create a stub Java class with methods declared 'native'. Anything you can do in Java, you can do in the JNI. -- Ashley Yakeley, Seattle WA

1 0

Re: Too Strict?
by C.Reinke 16 Jan '01

16 Jan '01

Dominic, > What I can't see at the moment is how to keep what I was doing modular. I had > a module Anonymize, the implementation of which I wanted to change without > the user of it having to change their code. The initial implementation was a > state monad which generated a new string every time it needed one but if it > was a string it had already anonymized then it looked it up in the state. I > initially used a list but with 100,000+ strings it took a long time. The next > implementation used FiniteMap which improved things considerably. I only had > to make three changes in Anonymize and none in Main. Using MD5 is quicker > still but isn't so good from the program maintenance point of view. my first stab at the modularity issue was the version _2 in my last message. Looking back at the Anonymizable class and instances in your full program, type Anon a = IO a class Anonymizable a where anonymize :: a -> Anon a -- MyString avoids overlapping instances of Strings -- with the [Char] data MyString = MyString String deriving Show instance Anonymizable MyString where anonymize (MyString x) = do s <- digest x return ((MyString . showHex') s) instance Anonymizable a => Anonymizable [a] where anonymize xs = mapM anonymize xs the problem is in the Anonymizable instance for [a]: the mapM in anonymize constructs an IO script, consisting of some IO operation for each list element, all chained together into a monolithic whole. As IO a is an abstract type, this is a bit too restrictive to be modular: if I ever want any of the anonymized Strings, I can only get a script that anonymizes them all - before executing that script, I don't have any anonymized Strings, and after executing the script, all of them have been processed. This forestalls any attempt to interleave the anonymization with some further per-element processing. Instead, I would prefer to have a list of IO actions, not yet chained together (after all, in Haskell, they are just data items), but that doesn't fit the current return type of anonymize. One approach would be to change the type of Anon a to [IO a], or to ignore the [a] instance and use the MyString instance only, but the longer I look at the code, the less I'm convinced that the overloading is needed at all. Unless there are other instances of Anonymizable, why not simply have a function anonymize :: String -> Anon String ? That would still allow you to hide the implementation decisions you mentioned (even in a separate module), provided that any extra state you need can be kept in the IO monad. One would have to write mapM anonymize explicitly where you had simply anonymize, but it would then become possible to do something else with the list of IO actions before executing them (in this case, to interleave the printing with the anonymization). First, here is the interesting fragment with the un-overloaded anonymize: readAndWriteAttrVals = do h <- openFile fileout WriteMode s <- readFile filename a <- mapM anonymize (lines s) hPutStr h (unlines a) It is now possible to import anonymize from elsewhere and do the interleaving in the code that uses anonymize: readAndWriteAttrVals = do h <- openFile fileout WriteMode s <- readFile filename let action line = do { a <- anonymize l ; hPutStr h a } mapM_ action (lines s) Would that work for your problem? Alternatively, if some of your implementation options require initialization or cleanup, your Anonymize module could offer a function to process all lines, with a hook for per-line processing: processLinesWith perLineAction ls = do { initialize ; as <- mapM action ls ; cleanup ; return as } where action l = do { a <- anonymize l ; perLineAction a } Then the code in the client module could simply be: readAndWriteAttrVals = do h <- openFile fileout WriteMode s <- readFile filename processLinesWith (hPutStr h) (lines s) return () Closing the loop, one could now redefine the original, overloaded anonymize to take a perLineAction, with the obvious instances for MyString and [a], but I really don't see why every function should have to be called anonymize?-) Claus PS The simplified code of the new variant, for observation: module Main(main) where import Observe import IO(openFile, hPutStr, IOMode(ReadMode,WriteMode,AppendMode)) filename = "ldif1.txt" fileout = "ldif.out" readAndWriteAttrVals = do h <- openFile fileout WriteMode s <- readFile filename let { anonymize s = return (':':s) ; action l = do { a <- anonymize l ; hPutStr h a } } mapM_ (observe "action" action) (lines s) main = runO readAndWriteAttrVals

1 0

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