- Haskell-Cafe - Haskell.org

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

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 07 Jan '01

07 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