- Haskell-Cafe - Haskell.org

HScript
by Eric Allen Wohlstadter 30 Jan '01

30 Jan '01

I have tried e-mailing the authors of HScript with my problems but they seem unresponsive. I was hoping maybe someone out there could help me. When I tried to run the demos I got an error "Could not find Prelude.hs", so I changed the hugsPath variable in regedit to point to hugs/lib. Then I got an error "Could not find Int". So I added hugs/lib/exts. Now I get the error "Addr.hs (line 23): Unknown primitive reference to addrToInt". Eric Wohlstadter

2 1

Re: 'any' and 'all' compared with the rest of the Report
by Jan-Willem Maessen 28 Jan '01

28 Jan '01

Bjorn Lisper <lisper(a)it.kth.se> replies to my reply: > >My current work includes [among other things] ways to eliminate this > >problem---that is, we may do a computation eagerly and defer or > >discard any errors. > > What you basically have to do is to treat purely data-dependent errors (like > division by zero, or indexing an array out of bounds) as values rather than > events. Indeed. We can have a class of deferred exception values similar to IEEE NaNs. [later]: > Beware that some decisions have to be taken regarding how error > values should interact with bottom. (For instance, should we have > error + bottom = error or error + bottom = bottom?) The choice affects which > evaluation strategies will be possible. Actually, as far as I can tell we have absolute freedom in this respect. What happens when you run the following little program? \begin{code} forever x = forever x bottomInt :: Int bottomInt = error "Evaluating bottom is naughty" + forever () main = print bottomInt \end{code} I don't know of anything in the Haskell language spec that forces us to choose whether to signal the error or diverge in this case (though it's clear we must do one or the other). Putting strong constraints on evaluation order would cripple a lot of the worker/wrapper-style optimizations that (eg) GHC users depend on for fast code. We want the freedom to demand strict arguments as early as possible; the consequence is we treat all bottoms equally, even if they exhibit different behavior in practice. This simplification is a price of "clean equational semantics", and one I'm more than willing to pay. -Jan-Willem Maessen jmaessen(a)mit.edu [PS - I've deliberately dodged the issue of program-level exception handling mechanisms and the like.]

3 3

Re: A clarification...
by Jan-Willem Maessen 26 Jan '01

26 Jan '01

qrczak(a)knm.org.pl (Marcin 'Qrczak' Kowalczyk) further clarifies my clarification: > > case ERROR of x -> expr => ERROR glb expr[?/x] > > The subject of errors vs. bottoms is discussed in > http://research.microsoft.com/~simonpj/papers/imprecise-exceptions.ps.gz Indeed. I crawled through my stack of electronic papers, and couldn't find the reference. As I noted in my earlier messages, I was deliberately dodging the issue of *catching* exceptions, as it really requires a thorough treatment. :-) The "?" in the above reduction is their special 0 term. They equate divergence with exceptional convergence within the functional calculus for the reasons I outlined [I reconstructed those reasons from memory and my own experience, so differences are due to my faulty recollection]. Their notion of refinement justifies the reduction I mentioned in my mail: > > case ERROR of x -> expr => ERROR In all, an excellent paper for those who are interested in this topic. -Jan-Willem Maessen

1 0

A clarification...
by Jan-Willem Maessen 26 Jan '01

26 Jan '01

Marko Schuetz <MarkoSchuetz(a)web.de> replies to me as follows: > > He uses this, and an argument based on currying, to show that strict > > functions ought to force their arguments left to right. > > I can't see where I did. I argued that distinguishing between error > and bottom seems to not leave much choice for bottom + error. You're right, sorry. I misread the following from your earlier message: > So I'd say error + bottom \equiv bottom and bottom + error \equiv > bottom. As you noted: > and you want, say, error + bottom \equiv error then + can no longer be > strict in its second argument.... I'd managed to turn this around in my head. Nonetheless, my fundamental argument stands: If we separate "bottom" and "error", we have a few choices operationally, and I'm not fond of them: 1) Make "error" a representable value. This appears closest to what you were describing above: case ERROR of x -> expr => expr [ERROR/x] This is tricky for unboxed types (especially Ints; floats and pointers aren't so hard; note that we need more than one distinguishable error value in practice if we want to tell the user something useful about what went wrong). At this point, by the way, it's not a big leap to flatten the domain as is done with IEEE NaNs, so that monotonicity wrt errors is a language-level phenomenon rather than a semantic one and we can handle exceptions by testing for error values. 2) Weaken the algebraic theory as I discussed in my last message. 3) Reject an operational reading of "case" as forcing evaluation and continuing and have it "do something special" when it encounters error: case ERROR of x -> expr => ERROR glb expr[?/x] >From the programmer's perspective, I'd argue that it's *better* to signal signal-able errors whenever possible, rather than deferring them. If nothing else, a signaled error is easier to diagnose than nontermination! Thus, I'd LIKE: error + bottom === error But I'm willing to acknowledge that I can't get this behavior consistently, except with some sort of fair parallel execution. I'm doing something along the lines of (3), but I abandon execution immediately on seeing error---which is consistent only if error==bottom: case ERROR of x -> expr => ERROR [Indeed, the compiler performs this reduction statically where possible, as it gets rid of a lot of dead code.] I defer the signaling of errors only if the expression in question is being evaluated eagerly; for this there is no "case" construct involved. -Jan-Willem Maessen

2 1

Re: 'any' and 'all' compared with the rest of the Report
by Jan-Willem Maessen 26 Jan '01

26 Jan '01

Marko Schuetz <MarkoSchuetz(a)web.de> starts an explanation of bottom vs. error with an assumption which I think is dangerous: > Assuming we want > > \forall s : bottom \le s > > including s = error, then we should also have error \not\le > bottom. He uses this, and an argument based on currying, to show that strict functions ought to force their arguments left to right. This seems to me to be another instance of an age-old debate in programming language design/semantics: If we can in practice observe evaluation order, should we therefore specify that evaluation order? This is a debate that's raged for quite a while among users of imperative languages. Some languages (Scheme comes to mind) very clearly state that this behavior is left unspecified. Fortunately, for the Haskell programmer the debate is considerably simpler, as only the behavior of "wrong" programs is affected. I am more than willing to be a little ambiguous about the error behavior of programs, by considering "bottom" and "error" to be one and the same. As I noted in my last message, this allows some optimizations which would otherwise not be allowed. Here's the worker-wrapper optimization at work; I'll use explicit unboxing to make the evaluation clear. forever x = forever x -- throughout. addToForever :: Int -> Int addToForever b = forever () + b main = print (addToForever (error "Bottom is naughty!")) == -- expanding the definition of + addToForever b = case forever () of I# a# -> case b of I# b# -> a# +# b# == -- At this point strictness analysis reveals that addToForever -- is strict in its argument. As a result, we perform the worker- -- wrapper transformation: addToForever b = case b of I# b# -> addToForever_worker b# addToForever_worker b# = let b = I# b# in case forever () of I# a# -> case b of I# b# -> a# +# b# == -- The semantics have changed---b will now be evaluated before -- forever(). I've experimented with versions of Haskell where order of evaluation did matter. It was a giant albatross around our neck---there is simply no way to cleanly optimize programs in such a setting without doing things like termination analysis to justify the nice old transformations. If you rely on precise results from an analysis to enable transformation, you all-too-frequently miss obvious opportunities. For this reason I *very explicitly* chose not to make such distinctions in my work. In general, making too many semantic distinctions weakens the power of algebraic semantics. Two levels---bottom and everything else---seems about the limit of acceptable complexity. If you look at the work on free theorems you quickly discover that even having bottom in the language makes life a good deal more difficult, and really we'd like to have completely flat domains. I'd go as far as saying that it also gives us some prayer of explaining our algebraic semantics to the programmer. A complex algebra becomes too bulky to reason about when things act stragely. Bottom is making things hard enough. -Jan-Willem Maessen PS - Again, we don't try to recover from errors. This is where the comparison with IEEE arithmetic breaks down: NaNs are specifically designed so you can _test_ for them and take action. I'll also point out that infinities are _not_ exceptional values; they're semantically "at the same level" as regular floats---so the following comparison is a bit disingenuous: > If error \equiv bottom and you extend, say, Int with NaNs, how do you > implement arithmetic such that Infinity + Infinity \equiv Infinity and > Infinity/Infinity \equiv Invalid Operation?

2 1

'any' and 'all' compared with the rest of the Report
by Jan-Willem Maessen 25 Jan '01

25 Jan '01

(Note, I've kept this on Haskell-cafe) Bjorn Lisper wrote (several messages back): > ... What I in turn would like to add is that specifications like > > any p = or . map p > > are on a higher level of abstraction ... > The first specification is, for instance, directly data parallel > which facilitates an implementation on a parallel machine or in hardware. As was pointed out in later discussion, the specification of "or" uses foldr and is thus not amenable to data parallelism. On which subject Jerzy Karczmarczuk <karczma(a)info.unicaen.fr> later noted: > On the other hand, having an even more generic logarithmic iterator > for associative operations seems to me a decent idea. In my master's thesis, "Eliminating Intermediate Lists in pH using Local Transformations", I proposed doing just that, and called the resulting operator "reduce" in line with Bird's list calculus. I then gave rules for performing deforestation so that sublists could be traversed in parallel. The compiler can choose from many possible definitions of reduce, including: reduce = foldr reduce f z = foldl (flip f) z reduce = divideAndConquer (most of the complexity of the analysis focuses on making this choice intelligently; the rest could be re-stated RULES-style just as the GHC folks have done with foldr/build.) We've been using this stuff for around 6-7 years now. Fundamentally, many associative operators have a "handedness" which we disregard at our peril. For example, defining "or" in terms of foldl as above is very nearly correct until handed an infinite list, but it performs really badly regardless of the input. Thus, we need a richer set of primitives (and a lot more complexity) if we really want to capture "what is most commonly a good idea" as opposed to "what is safe". For example, our deforestation pass handles "concat" as part of its internal representation, since no explicit definition using reduction is satisfactory: concat = foldr (++) [] -- least work, no parallelism concat = reduce (++) [] -- parallelizes well, but could pessimize -- the program For this reason, it's hard to use "reduce" directly in more than a handful of prelude functions. We use reduce a lot, but only after uglification of the prelude definitions to convince the compiler to "guess right" about the appropriate handedness. There is also the problem of error behavior; if we unfold an "or" eagerly to exploit its data parallelism we may uncover errors, even if it's finite: > or [True, error "This should never be evaluated"] True My current work includes [among other things] ways to eliminate this problem---that is, we may do a computation eagerly and defer or discard any errors. -Jan-Willem Maessen My Master's Thesis is at: ftp://csg-ftp.lcs.mit.edu/pub/papers/theses/maessen-sm.ps.gz A shorter version (with some refinements) is found in: ftp://csg-ftp.lcs.mit.edu/pub/papers/csgmemo/memo-370.ps.gz

2 1

Re: 'any' and 'all' compared with the rest of the Report
by Iavor Diatchki 23 Jan '01

23 Jan '01

hello i myself am not an experienced Haskell user, so please correct me if i am wrong. it is difficult in general to reason about the performance of lazy programs, so i don't think one can assume much. in particular i dont think 'any' and 'all' will perform in linear space. here is why i think so: take an example when 'any' is applied to some list (x:xs) and someone is actually interested in the result: any p (x:xs) 1. -> (or . map p) (x:xs) 2. -> or (map p (x:xs)) 3. -> foldr (||) False (map p (x:xs)) [at this stage we need to know what what kind of list is (map p (x:xs)) i.e. empty or a cons thing, so we need to do some evaluation] 4. -> foldr (||) False (p x : map p xs) 5. -> p x || (foldr (||) False (map p xs)) [at this stage we need to know what kind of thing is p x, i.e. True or False, so we need to evaluate p x] 6. -> if p x is True we are done (result True) 7. -> if p x is False the result is (foldr (||) False (map p xs)) and we go back to 3. note that p x has become garbage and so it doesnt really take up any space, so one really needs only enough space to process the list one element at a time. what causes problems is the need to create unnecessary cons cells (i.e. the evaluation after 3.). this is bad because it takes time. of course it only adds a constant so the complexity is the same but in practise programs run slower. this is where i would expect a good compiler to do some optimisation, i.e to remove the need for the intermediate list. i like the idea of programming at a higher level, as i believe it produces "better structured" programs. what i mean is that one manages to capture certain aspects of a program, which would be obscured if one always used explicit recursion. i think higher order functions like maps and folds really go a long way toward structuring functional programs. in a way this is simillar to using loops instead of explicit gotos in procedural programs. anyways these are my deep thought on the matter :) bye iavor On Tue, Jan 23, 2001 at 12:35:19PM -0600, Eric Shade wrote: ... > > Then I get to 'any' and 'all', whose specification requires linear > time and *linear* space when it should run in constant space. (By the > way, I checked and GHC does *not* use the Prelude definitions but > rather the obvious recursive ones, and most of its optimizations based > on "good consumers/producers" use meta-linguistic rewrite rules. So > without knowing the specific optimizations that a compiler provides, I > think it's safe to assume that the Prelude 'any' and 'all' *will* > require linear space.) ... -- +---------------------------------+---------------------------------------+ |Iavor S. Diatchki | email: diatchki(a)cse.ogi.edu | |Dept. of Computer Science | web: http://www.cse.ogi.edu/~diatchki | |Oregon Graduate Institute | tel: 5037481631 | +---------------------------------+---------------------------------------+

3 3

Re: Specifications of 'any', 'all', 'findIndices'
by D. Tweed 23 Jan '01

23 Jan '01

On Tue, 23 Jan 2001, Mark Tullsen wrote: > Johannes Waldmann wrote: > > ... > > I'd rather write clear code, than worry about efficiency too early. > > Who said this, "premature optimization is the root of all evil". > > I've always attributed this to Donald Knuth: > > Premature optimization is the root of all evil in programming. In his paper on the errors of TeX (no proper ref but it's reprinted in his book on Literate Programming) he calls it Hoare's dictum (i.e. Tony Hoare) although the context suggests that this isn't an `official name'. Dunno if Hoare heard it from someone else though... ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers email: tweed(a)cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.

1 0

RE: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
by Simon Marlow 19 Jan '01

19 Jan '01

> Indeed. Or do you want to tell me that you are going to > break one of my favourite programs? > > [ code deleted ] > # 111 "Foo.hs" Actually the cpp-style pragma is only recognised if the '#' is in the leftmost column and is followed by optional spaces and a digit. It's quite hard to write one of these in a legal Haskell program, but not impossible. Simon

3 2

Re: A simple problem
by Tom Pledger 19 Jan '01

19 Jan '01

Ashley Yakeley writes: > At 2001-01-18 15:38, I wrote: > > >3 is not always an Integer. It's of type "(Num a) => a". > > Of course, it would be nice if 3 were an Integer, and Integer were a > subtype of Real. I haven't come across a language that does this, where > for instance 3.0 can be cast to Integer (because it is one) but 3.1 > cannot be. A cast in that direction - becoming more specific - would be nicely typed as: Real -> Maybe Integer or with the help of the fail and return methods: Monad m => Real -> m Integer

1 0

Re: A simple problem
by Ashley Yakeley 19 Jan '01

19 Jan '01

At 2001-01-18 15:57, William Lee Irwin III wrote: >class C a where > fun :: a -> Integer > >instance Integral a => C a where > fun = toInteger . succ Gives "syntax error in instance head (constructor expected)" at the 'instance' line in Hugs. Is there a option I need to turn on or something? -- Ashley Yakeley, Seattle WA

2 1

Re: A simple problem
by William Lee Irwin III 19 Jan '01

19 Jan '01

Moving over to haskell-cafe... At 2001-01-18 05:16, Saswat Anand wrote: >> fun 3 --gives error in Hugs >> fun (3::Integer) -- OK >> >> I am a building an embedded language, so don't want user to cast. Is >> there a solution? On Thu, Jan 18, 2001 at 03:38:10PM -0800, Ashley Yakeley wrote: > 3 is not always an Integer. It's of type "(Num a) => a". > I couldn't find a way to say that every Num is a C. I didn't try to say every Num is C, but I found a way to make his example work: class C a where fun :: a -> Integer instance Integral a => C a where fun = toInteger . succ One has no trouble whatsoever with evaluating fun 3 with this instance defined instead of the original. I'm not sure as to the details, as I'm fuzzy on the typing derivations making heavy use of qualified types. Is this the monomorphism restriction biting us again? Cheers, Bill -- <nrut> how does one decide if something is undecidable? <Galois> carefully --

1 0

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

18 Jan '01

At 2001-01-17 16:07, Johan Nordlander wrote: >Ashley Yakeley wrote: >> >> OK, I've figured it out. In this O'Haskell statement, >> >> > struct Derived < Base = >> > value :: Int >> >> ...Derived is not, in fact, a subtype of Base. Derived and Base are >> disjoint types, but an implicit map of type "Derived -> Base" has been >> defined. >> >> -- >> Ashley Yakeley, Seattle WA > >Well, they are actually subtypes, as far as no implicit mapping needs to be >defined. But since Derived and Base also are two distinct type constructors, >the overloading system treats them as completely unrelated types (which is >fine, in general). All O'Haskell treats them as completely unrelated types. In fact, this O'Haskell... > struct Base = > b1 :: Int > b2 :: Char > > struct Derived < Base = > d1 :: Int ...is a kind of syntactic sugar for this Haskell... > data Base = Base (Int,Char) > dotb1 (Base (x,_)) = x > dotb2 (Base (_,x)) = x > > data Derived = Derived (Int,Char,Int) > dotd1 (Derived (_,_,x)) = x > > implicitMap (Derived (b1,b2,d1)) = Base (b1,b2) This seems to be stretching the concept of 'subtype'. Sorry if I sound so bitter and disappointed. I was hoping for a Haskell extended with real dynamic subtyping... -- Ashley Yakeley, Seattle WA

2 1

Boolean Primes Map (continued)
by Shlomi Fish 18 Jan '01

18 Jan '01

Well, after some thought, I decided to try re-writing the boolean primes map program only using a list instead of an array. I came up with this program: primes :: Int -> [Int] primes how_much = (iterate 2 initial_map) where initial_map :: [Bool] initial_map = (map (\x -> True) [ 0 .. how_much]) iterate :: Int -> [Bool] -> [Int] iterate p (a:as) | p > mybound = process_map p (a:as) | a = p:(iterate (p+1) (mymark (p+1) step (2*p) as)) | (not a) = (iterate (p+1) as) where step :: Int step = if p == 2 then p else 2*p mymark :: Int -> Int -> Int -> [Bool] -> [Bool] mymark cur_pos step next_pos [] = [] mymark cur_pos step next_pos (a:as) = if (cur_pos == next_pos) then False:(mymark (cur_pos+1) step (cur_pos+step) as) else a:(mymark (cur_pos+1) step next_pos as) mybound :: Int mybound = ceiling(sqrt(fromIntegral(how_much))) process_map :: Int -> [Bool] -> [Int] process_map cur_pos [] = [] process_map cur_pos (a:as) | a = cur_pos:(process_map (cur_pos+1) as) | (not a) = (process_map (cur_pos+1) as) I don't know too much about Haskell yet, so it is possible this program can be further optimized using some Haskell built-ins. Now, this program can scale to 100,000 and beyond, as opposed to the array version which only got until 30,000 or 40,000. It's a pity Haskell doesn't handle arrays very well, but I guess every language has its faults. Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif(a)vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: shlomif(a)techie.com The prefix "God Said" has the extraordinary logical property of converting any statement that follows it into a true one.

2 1

Re: O'Haskell OOP Polymorphic Functions
by Johan Nordlander 18 Jan '01

18 Jan '01

Ashley Yakeley wrote: > > OK, I've figured it out. In this O'Haskell statement, > > > struct Derived < Base = > > value :: Int > > ...Derived is not, in fact, a subtype of Base. Derived and Base are > disjoint types, but an implicit map of type "Derived -> Base" has been > defined. > > -- > Ashley Yakeley, Seattle WA Well, they are actually subtypes, as far as no implicit mapping needs to be defined. But since Derived and Base also are two distinct type constructors, the overloading system treats them as completely unrelated types (which is fine, in general). To this the upcoming O'Hugs release adds the capability of using an instance defined for a (unique, smallest) supertype of the inferred type, in case an instance for the inferred type is missing. This all makes a system that is very similar to the overlapping instances extension that Tom mentioned. -- Johan

1 0

RE: GHCi, Hugs (was: Mixture ...)
by Simon Peyton-Jones 18 Jan '01

18 Jan '01

| It'd be good if left-behind tools were using a BSD(-like) licence, in | the event that anybody - commercial or otherwise - who wanted to pick | them up again, were free to do so. GHC does indeed have a BSD-like license. Simon

2 1

RE: Will Haskell be commercialized in the future?
by Doug Ransom 18 Jan '01

18 Jan '01

> -----Original Message----- > From: Benjamin L. Russell [mailto:russell@brainlink.com] > Sent: Sunday, November 26, 2000 11:50 PM > To: Doug Ransom; haskell-cafe(a)haskell.org > Subject: Re: Will Haskell be commercialized in the future? > > > On Fri, 24 Nov 2000 09:15:52 -0800 > Doug Ransom <Doug_Ransom(a)pml.com> wrote: > > > > [stuff deleted] > > > > A lot of the things Haskell excells at (IMO) inferior > > tools are being used > > in place. For example, microsoft has build good XSLT > > translators and two > > new compilers (C#, VB7) in the last couple years. > > Unfortunately, C#, not > > Haskell, will probably be "the" language for the next > > decade. [stuff deleted] > > Just out of curiosity: what makes you so sure about C#? C# > has some potential big problems, too: in particular, the > ability to declare a portion of the code "unsafe," which can > encourage unsafe programming among entrenched C/C++ programmers. Well, first of all, most C++ programmers really hate C++ and will be happy to stay in safe mode and move to C#. There were cheers at the Microsoft Profesional Developers Conference when MS announced garbage collection for the COM replacement and the safety available with C# and managed C++ code. C# is a huge improvement over C++. Why would a C++ programmer want to go into unsafe mode? I guess when they are writing interfaces to device drives, operating system calls, and legacy interfaces. > > I myself am in no big hurry to master C#. I'd rather use a > set of domain-specific languages with interlinked code, > rather than a single language that purports to be as > general-purpose as C# does. Well, I would prefer to master Haskell and use that as my general purpose language. Fat chance since the object models available in the microsoft common language runtime are designed for impertive programming. > > Benjamin L. Russell > russell(a)brainlink.com > "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho >

3 2

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

17 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

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

09 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

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

Re: Learning Haskell and FP
by Fritz K Ruehr 05 Jan '01

05 Jan '01

Benjamin Russell (russell(a)brainlink.com) wrote: > Personally, I would really prefer "A Gentle Elementary > Introduction to Haskell: Elements of the Haskell School of > Expression with Practical Examples," but some would no doubt > choose "Haskell in a Nutshell: How to Write Practical Programs > in Haskell." An O'Reilly "nutshell" book is an even better suggestion than my "Design Patterns in Haskell" of a few days back, at least from the perspective of marketing and promotion. But it raises the issue of an appropriate animal mascot for the cover; I can only come up with the Uakari, an exotic-looking rainforest monkey, which sounds similar to "Curry". (look here for a picture:) <http://www.animalsoftherainforest.com/uakari.htm> One possibly relevant point: the site notes that the Uakari is "mainly arboreal (tree-dwelling)". On the other hand, this means that it is probably threatened by deforestation, whereas this phenomenon can be of great help in Haskell :) . -- Fritz Ruehr fruehr(a)willamette.edu

3 2

Re: Learning Haskell and FP
by Michael Zawrotny 05 Jan '01

05 Jan '01

"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. 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. > (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

2 1

Re: Learning Haskell and FP
by Benjamin L. Russell 04 Jan '01

04 Jan '01

On Wed, 03 Jan 2001 11:26:53 -0500 Michael Zawrotny <zawrotny(a)gecko.sb.fsu.edu> wrote: > > [snip] > > The reason that I found GITH difficult wasn't that the > concept > of programming with functions/functional style was new to > me. What got me was that the concepts and notations were > much > more "mathematical" than "programmatic". In my > explorations > of various languages, my experience with introductions to > scheme/CL has mostly been that they tend to show how to > do > things that are familiar to imperative programmers, plus > all > of the things that you can do with functions as first > class > values. With intros to SML, OCaml and Haskell, there is > a > much greater emphasis on types, type systems, and > provable > program correctness. > > [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?" (Perhaps another way of phrasing the issue is as the "declarative" vs. "procedural" distinction, since the issue seems to be that of "what is" (types) vs. "how to" (imperative expression; i.e., procedures).) 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. If I may give my own case as an example, I studied both C and Scheme (in addition to auditing a course in Haskell) in college, and favored Scheme over C precisely because of my Scheme course's emphasis on provable program correctness. This is largely a matter of background and taste: my course background was relatively focused on the design and analysis of algorithms, with provable program correctness being a related topic. Perhaps, ideally, two separate tutorials (or perhaps a single tutorial with two 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 that any introduction favoring either one would risk alienating the other. Personally, I would really prefer "A Gentle Elementary Introduction to Haskell: Elements of the Haskell School of Expression with Practical Examples," but some would no doubt choose "Haskell in a Nutshell: How to Write Practical Programs in Haskell." --Ben -- Benjamin L. Russell russell(a)brainlink.com benjamin.russell.es.94(a)aya.yale.edu "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho

1 0

Problems compiling HDirect 0.17
by Eric Allen Wohlstadter 04 Jan '01

04 Jan '01

When I try to compile hdirect on cygwin on my NT I get a lot of complaints from ghc about bad tokens. Particularly the use of "\" to continue a line. For some reason it doesn't see it as the line continuation character. Also, it compiled ok on a different machine but it complains about a missing link to CYGWIN1.DLL when I try to do anything. Any help would be appreciated. Eric Wohlstadter

2 1

Re: Learning Haskell and FP
by senganb＠ia.nsc.com 29 Dec '00

29 Dec '00

> * The Design Patterns Haskell Companion > by [someone(s) reading this list?] I agree except I would also like to see more on Haskell space-leaks and how to find them. Lazyness is great for structuring programs and garbage collection helps rapid prototyping immensely. However it makes it difficult to find the cause of that 128Mb heap overflow once you have 2000 lines of code. Yes the profiler gives you an idea of which function is using a lot of heap, but not exactly where. E.g. I rewrote my monads ultra stritly and the heap consumption fell by half, even though I'm not convinced being so strict isn't just masking some other problem: > (MN c1) >>= fc2 = MN $ \s0 -> case c1 s0 of { (r1,io1,s1) -> > case fc2 r1 of { ( MN c2 ) -> > case c2 s1 of { (r2,io2,s2) -> > (r2,io1 >> io2,s2) }}} Such a "community written book" might be good for http://www.lightandmatter.com/cgi-bin/asbrowsesubject.cgi?class=Q Sengan

1 0

Haskell question
by Scott 29 Dec '00

29 Dec '00

Hello! I am reading Discrete Mathematics Using a computer by Hall and O'Donnell and in the introduction to hugs section, they give this example: [[x,y] | x<-[1..50],y<-[1..50],z<-[1..50],x**2+y**2==z**2] now I type it in and expect it to return a number of results, but it doesn't, it shows: [[8.0,15.0,17.0],[14.0,48.0,50.0],[15.0,8.0,17.0],[15.0,20.0,25.0],[20.0,15.0,25.0],[21.0,28.0,35.0],[27.0,36.0,45.0],[28.0,21.0,35.0],[30.0,40.0,50.0],[36.0,27.0,45.0],[40.0,30.0,50.0],[48.0,14.0,50.0]] My question is where is [3.0,4.0,5.0],[5.0,12.0,13.0]? I have looked everywhere I could think of to see what I am doing wrong, but I have no idea. Maybe a rounding error somewhere? Thank you, Scott Anderson

3 2

Re: Haskell question
by Mike Gunter 29 Dec '00

29 Dec '00

This is fairly subtle. The fact that the numbers are printed with a decimal point hints that they are floating point numbers. Floating-point arithmetic's inexactness makes equality tests less valuable than for, e.g., Integer arithmetic. If you change the "**"s to "^"s you'll get [3,4], etc. (or [3,4,5] if you change "[x,y]" to "[x,y,z]"). mike gunter E.g.: Main> [[x,y,z] | x<-[1..50],y<-[1..50],z<-[1..50],x^2+y^2==z^2] [[3,4,5],[4,3,5],[5,12,13],[6,8,10],[7,24,25], ... ] > Hello! > I am reading Discrete Mathematics Using a computer by Hall and O'Donnell > and in the introduction to hugs section, they give this example: > [[x,y] | x<-[1..50],y<-[1..50],z<-[1..50],x**2+y**2==z**2] > now I type it in and expect it to return a number of results, but it > doesn't, it shows: > [[8.0,15.0,17.0],[14.0,48.0,50.0],[15.0,8.0,17.0],[15.0,20.0,25.0],[20.0,15.0,25.0],[21.0,28.0,35.0],[27.0,36.0,45.0],[28.0,21.0,35.0],[30.0,40.0,50.0],[36.0,27.0,45.0],[40.0,30.0,50.0],[48.0,14.0,50.0]] > My question is where is [3.0,4.0,5.0],[5.0,12.0,13.0]? > I have looked everywhere I could think of to see what I am doing wrong, but > I have no idea. Maybe a rounding error somewhere? > Thank you, > Scott Anderson

1 0

RE: Haskell question
by Conal Elliott 29 Dec '00

29 Dec '00

It's probably due to rounding. If you use "^" instead of "**", defaulting to integers, you'll get the triples you expected. - Conal -----Original Message----- From: Scott [mailto:adric@wipcradio.cc] Sent: Thursday, December 28, 2000 3:05 PM To: Haskell-Cafe(a)haskell.org Subject: Haskell question Hello! I am reading Discrete Mathematics Using a computer by Hall and O'Donnell and in the introduction to hugs section, they give this example: [[x,y] | x<-[1..50],y<-[1..50],z<-[1..50],x**2+y**2==z**2] now I type it in and expect it to return a number of results, but it doesn't, it shows: [[8.0,15.0,17.0],[14.0,48.0,50.0],[15.0,8.0,17.0],[15.0,20.0,25.0],[20.0,15. 0,25.0],[21.0,28.0,35.0],[27.0,36.0,45.0],[28.0,21.0,35.0],[30.0,40.0,50.0], [36.0,27.0,45.0],[40.0,30.0,50.0],[48.0,14.0,50.0]] My question is where is [3.0,4.0,5.0],[5.0,12.0,13.0]? I have looked everywhere I could think of to see what I am doing wrong, but I have no idea. Maybe a rounding error somewhere? Thank you, Scott Anderson _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Boolean Primes Map (continued)
by Shlomi Fish 22 Dec '00

22 Dec '00

Well, after some thought, I decided to try re-writing the boolean primes map program only using a list instead of an array. I came up with this program: primes :: Int -> [Int] primes how_much = (iterate 2 initial_map) where initial_map :: [Bool] initial_map = (map (\x -> True) [ 0 .. how_much]) iterate :: Int -> [Bool] -> [Int] iterate p (a:as) | p > mybound = process_map p (a:as) | a = p:(iterate (p+1) (mymark (p+1) step (2*p) as)) | (not a) = (iterate (p+1) as) where step :: Int step = if p == 2 then p else 2*p mymark :: Int -> Int -> Int -> [Bool] -> [Bool] mymark cur_pos step next_pos [] = [] mymark cur_pos step next_pos (a:as) = if (cur_pos == next_pos) then False:(mymark (cur_pos+1) step (cur_pos+step) as) else a:(mymark (cur_pos+1) step next_pos as) mybound :: Int mybound = ceiling(sqrt(fromIntegral(how_much))) process_map :: Int -> [Bool] -> [Int] process_map cur_pos [] = [] process_map cur_pos (a:as) | a = cur_pos:(process_map (cur_pos+1) as) | (not a) = (process_map (cur_pos+1) as) I don't know too much about Haskell yet, so it is possible this program can be further optimized using some Haskell built-ins. Now, this program can scale to 100,000 and beyond, as opposed to the array version which only got until 30,000 or 40,000. It's a pity Haskell doesn't handle arrays very well, but I guess every language has its faults. Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif(a)vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: shlomif(a)techie.com The prefix "God Said" has the extraordinary logical property of converting any statement that follows it into a true one.

1 0

finding primes
by S.D.Mechveliani 21 Dec '00

21 Dec '00

Hello, On generating prime numbers, people wrote ... | import Array | primes n = [ i | i <- [2 ..n], not (primesMap ! i)] where | primesMap = accumArray (||) False (2,n) multList | [..] I think that it is good for functional programming to avoid arrays, as possible. Shlomi Fish <shlomif(a)vipe.technion.ac.il> writes > [..] > primes :: Int -> [Int] > > primes how_much = sieve [2..how_much] where > sieve (p:x) = > p : (if p <= mybound > then sieve (remove (p*p) x) > else x) where > remove what (a:as) | what > how_much = (a:as) > | a < what = a:(remove what as) > | a == what = (remove (what+step) as) > | a > what = a:(remove (what+step) as) > remove what [] = [] > step = (if (p == 2) then p else (2*p)) > sieve [] = [] > mybound = ceiling(sqrt(fromIntegral how_much)) > > I optimized it quite a bit, but the concept remained the same. > > Anyway, this code can scale very well to 100000 and beyond. But it's not > exactly the same algorithm. > [..] C.Runciman <Colin.Runciman(a)cs.york.ac.uk> gives a paper reference about this. Aslo may I ask what do you mean by "can scale to 100000", the value of a prime or its position No in the list? Anyway, here are my attempts: ----------------------------------- 1. primes1 = s [(2::Int)..] :: [Int] where s (p:ns) = p: (s (filter (notm p) ns)) notm p n = (mod n p) /= 0 main = putStr $ shows (primes1!!9000) "\n" After compiling by GHC-4.08 -O2 it yields 93187 in 115 sec on Intel-586, 160 MHz. ----------------------------------- 2. The DoCon program written in Haskell (again, no arrays) gives about 10 sec (for Integer values). Also it finds, for example, first 5 primes after 10^9 as follows: take 5 $ filter isPrime [(10^9 ::Integer) ..] --> [1000000007,1000000009,1000000021,1000000033,1000000087] This takes 0.05 sec. But DoCon uses a particular isPrime test method: Pomerance C., Selfridge J.L., Wagstaff S.S.: The pseudoprimes to 25*10^9. Math.Comput., 1980, v.36, No.151, pp.1003-1026. After 25*10^9 it becomes again, expensive. ------------------ Sergey Mechveliani mechvel(a)botik.ru

2 1

finding primes
by S.D.Mechveliani 21 Dec '00

21 Dec '00

Hello, I wrote recently on generating prime numbers > [..] > The DoCon program written in Haskell (again, no arrays) gives > [..] > take 5 $ filter isPrime [(10^9 ::Integer) ..] > --> > [1000000007,1000000009,1000000021,1000000033,1000000087] > > This takes 0.05 sec. > [..] But it is better to refer to the BAL library for Haskell (basAlgPropos) http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/ It is easier to use. ------------------ Sergey Mechveliani mechvel(a)botik.ru

1 0

Preprocessor File Extension Conventions
by Ashley Yakeley 12 Dec '00

12 Dec '00

At 2000-12-11 03:26, Marcin 'Qrczak' Kowalczyk wrote: >When multiple preprocessors are being applied, it's not obvious what >extensions to use. I tried to allow such stacking in my hsc2hs >preprocessor by letting it accept any name ending in "c" and creating the >output file with this "c" removed, thus turning foo.hsc into foo.hs and >foo.lhsc into foo.lhs. > >Perhaps it would be better to mark a source to be preprocessed by >appending a whole new extension with its own dot instead of modifying the >old extension, like autoconf turning config.h.in into config.h. I prefer the other way around. For instance, compiling 'foo.c' gives object file 'foo.c.o'. A parser might start as a bison file 'parser.y', converted to 'parser.y.h' and 'parser.y.c', and compiled to object file 'parser.y.c.o'. The advantage is that you can look at the filename and see how the file was made (or how it should be made by a make tool). Also, 'foo.a' (assembly) and 'foo.c' won't collide. So 'foo.hsc' could go to 'foo.hsc.hs', and 'foo.lhsc' could go to 'foo.lhsc.hs'. >Preprocessors in general may produce more files. For example hsc2hs >sometimes produces .c and .h files as well. This requires a naming >convention too. ... 'foo.hsc.c', 'foo.hsc.h'. -- Ashley Yakeley, Seattle WA

1 0

RE: GHCi (was Re: Mixture of Integer and Float arithmetic without "fromIntegral "?)
by Simon Marlow 11 Dec '00

11 Dec '00

> On Fri, Dec 08, 2000 at 12:37:59AM -0800, Simon Peyton-Jones wrote: > > (GHCi is the revised Plan.) > > > > Incidentally, GHCi is just about working. It acts as a compiler > > with a built-in 'make' too. This is good, not because it > figures out > > dependencies, which is easy, but because it remembers the > results of one > > compilation for the next. This about doubles the speed of > compilation > > for large systems. Mixed interpreted/compiled code is on the way. > > Will it be easy to add support for preprocessors? > > Classic Hugs has a flag -F for specifying a preprocessor for > all source > files, and I've hacked an option to redefine the set of source file > suffixes. Then the preprocessor can be written to do different things > depending on the suffix. Is this sort of thing compatible with GHCi? In principle, yes. But there are several stages to GHC's compilation cycle; where exactly the user-specified preprocessing stage would fit in is something we'd need to discuss. Cheers, Simon

2 1

RE: Mixture of Integer and Float arithmetic without "fromIntegral "?
by Simon Peyton-Jones 11 Dec '00

11 Dec '00

| > OK, OK, I've just added -fno-monomorphism-restriction to GHC. | | Great! Will there also be a similar option for Stg Hugs? Yes. But it'll be GHCi, the interactive version of GHC, rather than STG Hugs. (GHCi is the revised Plan.) Incidentally, GHCi is just about working. It acts as a compiler with a built-in 'make' too. This is good, not because it figures out dependencies, which is easy, but because it remembers the results of one compilation for the next. This about doubles the speed of compilation for large systems. Mixed interpreted/compiled code is on the way. Simon

4 3

Re: GHCi, Hugs (was: Mixture ...)
by Ketil Malde 11 Dec '00

11 Dec '00

Koen Claessen <koen(a)cs.chalmers.se> writes: [Dead/dying compilers/interpreter] > I know of nobody who is starting to implement a Haskell > compiler from scratch. What do people think: is this > a worrying situation? Only if the remaining tools are insufficient, IMHO. It is questionable whether the Haskell community is large enough to support the development and maintenance of three compilers and two interpreters. Popular languages like Python and Perl have far fewer implementations, and even C and C++ only really have GCC in the free software world. It's good to have multiple tools, but at least for me, I can't seem to get around to try out tools for the sake of doing it, so I'm stuck on GHC, since it was the first I ran across, and it does an adequate (actually great, but adequate is sufficient) job of it. It'd be good if left-behind tools were using a BSD(-like) licence, in the event that anybody - commercial or otherwise - who wanted to pick them up again, were free to do so. -kzm -- I'm I haven't seen further, it is by standing in the footprints of giants

1 0

RE: Rank-2 polymorphism & type inference
by Simon Peyton-Jones 09 Dec '00

09 Dec '00

| < p y = (let f :: c -> Bool; f x = op (y >> return x) in f, y ++ []) | < q y = (y ++ [], let f :: c -> Bool; f x = op (y >> return x) in f) | < | System CT accepts both. No type signature is required. | | The types inferred for p and q are, resp.: | | Forall a,b. [a] -> (b -> Bool, [a]) and | Forall a,b. [a] -> ([a], b -> Bool) That's not the type we wanted, though. We wanted Forall a. [a] -> (Forall b. b->Bool, [a]) and similarly the other one. That's the reason for the type signature on f, which is short for (forall c. c->Bool). If you leave out the type signature then all Haskell compilers are happy. (Of course, this isn't a very useful example, but it's the smallest one that shows up the problem.) Simon

3 3