January 2001 - Haskell-Cafe

Re: Type Pattern-Matching for Existential Types
by Ashley Yakeley 31 Jan '01

31 Jan '01

At 2001-01-30 22:16, Lennart Augustsson wrote: >It has large and horrible implications. To do dynamic type tests you need >to carry around the types at runtime. This is not something that Haskell >does (at least you don't have to). Hmm. In this: -- data Any = forall a. Any a a1 = Any 3 a2 = Any 'p' -- ...are you saying that a1 and a2 do not have to carry types at runtime? -- Ashley Yakeley, Seattle WA

3 2

Re: Type Pattern-Matching for Existential Types
by C.Reinke 31 Jan '01

31 Jan '01

> > > data Any = forall a. Any a > > > > > > get :: Any -> Maybe Char > > > get (Any (c::Char)) = Just c -- bad > > > get _ = Nothing .. > It can also be questioned from a software engineering standpoint. Much > of the purpose with existential types is to provide information hiding; > that is, the user of an existentially quantified type is not supposed to > know its concrete representation. The merits of an information hiding > dicipline is probably no news to anybody on this list. This discussion reminds me of an old paper by MacQueen: David MacQueen. Using dependent types to express modular structure. In Proc. 13th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 277--286, January 1986. He discusses some of the disadvantages of using plain existential quantification for modular programming purposes and proposes an alternative based on dependent sums, represented as pairing the witness type with the expression in which it is used, instead of existentials, where there is no witness for the existentially quantified type. See CiteSeer for some of the follow-on work that references MacQueen's paper: http://citeseer.nj.nec.com/context/32982/0 Some of that work tried to find a balance between having no witness types and carrying witness types around at runtime. In this context, Claudio Russo's work might be of interest, as he proposes to avoid the problems of existentials without going into (value-)dependent types: http://www.dcs.ed.ac.uk/home/cvr/ Claus

1 0

Type Pattern-Matching for Existential Types
by Ashley Yakeley 31 Jan '01

31 Jan '01

At 2001-01-30 19:52, Fergus Henderson wrote: >On 30-Jan-2001, Ashley Yakeley <ashley(a)semantic.org> wrote: >> At 2001-01-30 02:37, Fergus Henderson wrote: >> >> >class BaseClass s where >> > downcast_to_derived :: s -> Maybe Derived >> >> Exactly what I was trying to avoid, since now every base class needs to >> know about every derived class. This isn't really a practical way to >> build an extensible type hierarchy. > >Right. > >I don't know of any way to do that in Hugs/ghc without the problem that >you mention. Really it needs language support, I think. >(I have no idea if you can do it in O'Haskell.) It can't be done in O'Haskell either... Given that we have existential types, it would be nice to have a pattern-matching mechanism to get at the inside value. Something like... -- data Any = forall a. Any a get :: Any -> Maybe Char get (Any (c::Char)) = Just c -- bad get _ = Nothing -- ...but as it stands, this is not legal Haskell, according to Hugs: ERROR "test.hs" (line 4): Type error in application *** Expression : Any c *** Term : c *** Type : Char *** Does not match : _0 *** Because : cannot instantiate Skolem constant This, of course, is because the '::' syntax is for static typing. It can't be used as a dynamic pattern-test. Question: how big of a change would it be to add this kind of pattern matching? Is this a small issue, or does it have large and horrible implications? -- Ashley Yakeley, Seattle WA

4 4

Re: Type Pattern-Matching for Existential Types
by Ashley Yakeley 31 Jan '01

31 Jan '01

At 2001-01-30 23:11, Johan Nordlander wrote: >However, this whole idea gets forfeited if it's possible to look behind >the abstraction barrier by pattern-matching on the representation. Isn't this information-hiding more appropriately achieved by hiding the constructor? -- data IntOrChar = MkInt Int | MkChar Char data Any = forall a. MkAny a -- Surely simply hiding MkInt, MkChar and MkAny prevents peeking? -- Ashley Yakeley, Seattle WA

2 1

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

31 Jan '01

At 2001-01-30 02:37, Fergus Henderson wrote: >class BaseClass s where > downcast_to_derived :: s -> Maybe Derived Exactly what I was trying to avoid, since now every base class needs to know about every derived class. This isn't really a practical way to build an extensible type hierarchy. -- Ashley Yakeley, Seattle WA

2 1

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

31 Jan '01

At 2001-01-17 17:03, Lennart Augustsson wrote: >You seem to want dynamic type tests. This is another feature, and >sometimes a useful one. But it requires carrying around types at >runtime. Yes. I tried to do that myself by adding a field, but it seems it can't be done. >You might want to look at existential types; it is a similar feature. I seem to run into a similar problem: -- class BaseClass s data Base = forall a. BaseClass a => Base a class (BaseClass s) => DerivedClass s data Derived = forall a. DerivedClass a => Derived a upcast :: Derived -> Base upcast (Derived d) = Base d downcast :: Base -> Maybe Derived -- How do I define downcast? -- Ashley Yakeley, Seattle WA

3 3

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

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

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

16 Jan '01

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

2 1