RE: [Haskell-cafe] type refinement to a typeclass constrained type
| Interesting thing though, it's the same on 6.4.1. | | Wasn't this brokenness introduced in 6.6, but rather has lingered in | ghc for a while, or since the introduction of GADTs, at all? No it's always been broken. I finally made GADTs and type classes work together in the HEAD a few months ago, using implication constraints for the first time. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ghc warning "Var/Type length mismatch"
| Also, is there a better list for this question? I half-heartedly tried
| haskell.org's list of mailing lists for an appropriate place for GHC
| bugs but didn't find one.
Yes, there is a mailing list specifically for ghc bugs
http://www.haskell.org/ghc/docs/latest/html/users_guide/introduction-GHC.html#mailing-lists-GHC
| When I load my program, GHC spits these messages at me, but doesn't
| fail Any idea what might be causing this or how to figure that out?
|
| Var/Type length mismatch:
| []
| [a{tv aGIf} [tau]]
This is definitely a bug.
The first thing is to compile (all your modules) with -dcore-lint. That often
localises the problem dramatically.
Even if that localises it, I may well need to be able to reproduce it myself,
so if you felt able to shrink your program by deleting stuff, or (next best)
tar up the entire thing so we can build it, that would be great.
thx
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Duplicate instance declaration
On 3/22/07, Twan van Laarhoven <[EMAIL PROTECTED]> wrote: ... An alternative idea would be to use data types instead of classes for the registers and memory locations ... A very nice solution. Thanks very much! Bas van Dijk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type refinement to a typeclass constrained type
Ok, btw, this works :) data Cnd c where In :: (Eq (c a)) => c a -> [c a] -> Cnd c check :: (Eq (c a)) => Cnd c -> Bool check (x `In` items) = x `elem` items That's nice :) 2007/3/23, Simon Peyton-Jones <[EMAIL PROTECTED]>: | Interesting thing though, it's the same on 6.4.1. | | Wasn't this brokenness introduced in 6.6, but rather has lingered in | ghc for a while, or since the introduction of GADTs, at all? No it's always been broken. I finally made GADTs and type classes work together in the HEAD a few months ago, using implication constraints for the first time. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type refinement to a typeclass constrained type
2007/3/23, Daniil Elovkov <[EMAIL PROTECTED]>: Ok, btw, this works :) data Cnd c where In :: (Eq (c a)) => c a -> [c a] -> Cnd c check :: (Eq (c a)) => Cnd c -> Bool Eq constraint isn't even needed here, obviously check (x `In` items) = x `elem` items ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Application of iterate
Ordinarily I would not post to a list when I've got a program running. But I've found learning Haskell so tough (this is my 4th try in the last two years) that I feel I have to bore everyone with my first non-trivial program. It is Newton's method adapted to give the square root of a number. And all in just one line which I think is an amazing demonstration of the power of Haskell. And it took no more than a couple of minutes to write (directly to the screen too as opposed to the usual many paper drafts with C). It works too, correct to 13 decimal points on my GHC system It is :- my_sqrt t = last (take 20 (iterate (\n -> n/2 + t/(2 * n)) t)) It is a bit crude though. 20 iterations is a bit arbitrary. I don't suppose there is a easy way to iterate until the results stop changing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Application of iterate
Hi Longesh But I've found learning Haskell so tough (this is my 4th try in the last two years) that I feel I have to bore everyone with my first non-trivial program. Well done on getting something going! my_sqrt t = last (take 20 (iterate (\n -> n/2 + t/(2 * n)) t)) last (take 20) can be reexpressed as: my_sqrt t = iterate (\n -> n/2 + t/(2 * n)) t !! 19 For information on what !! does (vs last and take), see Hoogle: http://haskell.org/hoogle It is a bit crude though. 20 iterations is a bit arbitrary. I don't suppose there is a easy way to iterate until the results stop changing. close (x:y:xs) | abs (x - y) < 0.1 = y close (x:xs) = close xs I don't know how to add it into the one liner though - although I suspect someone here will :) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Application of iterate
Neil Mitchell wrote: close (x:y:xs) | abs (x - y) < 0.1 = y close (x:xs) = close xs I don't know how to add it into the one liner though - although I suspect someone here will :) head . head . filter (\(x:y:_) -> abs (x-y) < 0.1) ? -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Application of iterate
Hi > I don't know how to add it into the one liner though - although I > suspect someone here will :) head . head . filter (\(x:y:_) -> abs (x-y) < 0.1) Doesn't work, I assume you meant (and typo'd): head . head . filter (\(x:y:_) -> abs (x-y) < 0.1) . tails Which does work fine. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Application of iterate
> It is :- > > my_sqrt t = last (take 20 (iterate (\n -> n/2 + t/(2 * n)) t)) > > It is a bit crude though. 20 iterations is a bit arbitrary. I don't > suppose > there is a easy way to iterate until the results stop changing. Here's something for you to play with: my_sqrt t = fix (\n -> n/2 + t/(2 * n)) t fix :: (Double -> Double) -> Double -> Double fix f x | x == fx = x | otherwise = f (fix f fx) where fx = f x My numerical analysis is a bit on the dodgy side, but you probably don't want to use == to test for convergence. Maybe you can find a nice way to write fix using some prelude functions? Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Rank-2-polymorphism problem
Hi, I'm writing some database code using HSQL and had to stop on a problem with rank-2-polymorphism that I can't solve. The essence of my code is: module Value where import Data.Maybe class SqlBind a where fromSqlValue :: String -> a data Field data Value emptyValue :: Field -> Value emptyValue _ = ... readValue :: Field -> (forall s. SqlBind s => s) -> Value readValue _ = ... That works just fine. But now I want a version of readValue that has a Maybe wrapped around the second parameter and that shall call readValue in the case of a Just and emptyValue in the case of Nothing. But I can't figure out how to write this function as I always get compiler errors. My trials were: -- The type I want to get. readValue' :: Field -> (forall s. SqlBind s => Maybe s) -> Value -- First trial: readValue' fld s = if isJust s then readValue fld (fromJust s) else emptyValue fld -- Second trial: readValue' fld s | isJust s = readValue fld (fromJust s) | otherwise = emptyValue fld -- Third trial: readValue' fld (Just s) = readValue fld s readValue' fld Nothing = emptyValue fld -- Fourth trial: readValue fld s = case s of Just s' -> readValue fld s' Nothing -> emptyValue fld But none of these trials worked. Is there any solution that works with GHC-6.6 for now? Thanks in advance, Martin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc warning "Var/Type length mismatch"
Hello Nicolas, Friday, March 23, 2007, 1:44:00 AM, you wrote: > Glasgow Haskell Compiler, Version 6.7.20070214, for Haskell 98, > compiled by GHC version 6.7.20070214 are you really need to use this beta version? 6.6 is last stable one, if you will go to download it, i recommend you to get latest binary snapshot for your platform -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Last chance to join the Summer of Code!
Haskell.org is currently looking rather short of student proposals for Summer of Code 2007 compared to last year. If you haven't yet thought about submitting an application, why not consider it now? You could be paid $4500 for three months work June-Aug! Apparently, the more proposals we get, the more places are likely to be funded. Also, Google have announced a relaxation of the deadline for student proposals. The new deadline is Mon 26th March at 1700 Pacific Standard Time (Tue 27th, UTC), so you have all weekend to get writing! Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Application of iterate
On Fri, 23 Mar 2007, Neil Mitchell wrote: > Hi Longesh > > > But I've found learning Haskell so tough (this is my 4th try in the last > > two years) that I feel I have to bore everyone with my first non-trivial > > program. > > Well done on getting something going! > > > my_sqrt t = last (take 20 (iterate (\n -> n/2 + t/(2 * n)) t)) http://darcs.haskell.org/htam/src/Numerics/ZeroFinder/Newton.hs with inverse t (\x->(x^2,2*x)) t > > It is a bit crude though. 20 iterations is a bit arbitrary. I don't suppose > > there is a easy way to iterate until the results stop changing. > > close (x:y:xs) | abs (x - y) < 0.1 = y > close (x:xs) = close xs > > I don't know how to add it into the one liner though - although I > suspect someone here will :) http://darcs.haskell.org/htam/src/Numerics/Sequence.hs limitDifference :: (Real a) => a -> [a] -> a limitDifference tol xs = case dropWhile ((> tol) . abs . uncurry (-)) $ zip xs (tail xs) of ((_,x):_) -> x [] -> error "limitDifference: Finite sequence, but no element satisfies abort criterion." ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] AI Strike Force!
The time has come! Calling all Haskell programmers interested in AI! I've established a new home base at http://www.haskell.org/haskellwiki/AI . Functional programming has long been recognized as an excellent paradigm for Artificial Intelligence. It's time to make Haskell an important language in that area! The goal is to provide a toolkit of AI tools in Haskell that can easily be applied to a wide variety of applications: e.g., Neural Networks, genetic algorithms, natural language processing tools, etc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AI Strike Force!
On Fri, 23 Mar 2007, Andrew Wagner wrote: > The time has come! Calling all Haskell programmers interested in AI! > I've established a new home base at > http://www.haskell.org/haskellwiki/AI . Functional programming has > long been recognized as an excellent paradigm for Artificial > Intelligence. It's time to make Haskell an important language in that > area! The goal is to provide a toolkit of AI tools in Haskell that can > easily be applied to a wide variety of applications: e.g., Neural > Networks, genetic algorithms, natural language processing tools, etc. Should there be some reference to http://www.haskell.org/haskellwiki/Libraries_and_tools/Linguistics ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AI Strike Force!
Sure, it's added! On 3/23/07, Henning Thielemann <[EMAIL PROTECTED]> wrote: On Fri, 23 Mar 2007, Andrew Wagner wrote: > The time has come! Calling all Haskell programmers interested in AI! > I've established a new home base at > http://www.haskell.org/haskellwiki/AI . Functional programming has > long been recognized as an excellent paradigm for Artificial > Intelligence. It's time to make Haskell an important language in that > area! The goal is to provide a toolkit of AI tools in Haskell that can > easily be applied to a wide variety of applications: e.g., Neural > Networks, genetic algorithms, natural language processing tools, etc. Should there be some reference to http://www.haskell.org/haskellwiki/Libraries_and_tools/Linguistics ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Application of iterate
Henning Thielemann wrote: > On Fri, 23 Mar 2007, Neil Mitchell wrote: > > >>> my_sqrt t = last (take 20 (iterate (\n -> n/2 + t/(2 * n)) t)) >>> > > http://darcs.haskell.org/htam/src/Numerics/ZeroFinder/Newton.hs > > with > inverse t (\x->(x^2,2*x)) t > > >> >> I don't know how to add it into the one liner though - although I >> suspect someone here will :) >> > > > http://darcs.haskell.org/htam/src/Numerics/Sequence.hs > > limitDifference :: (Real a) => a -> [a] -> a > limitDifference tol xs = >case dropWhile ((> tol) . abs . uncurry (-)) $ zip xs (tail xs) of > ((_,x):_) -> x > [] -> error "limitDifference: Finite sequence, but no element satisfies > abort criterion." > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > as a fellow haskell newbie, i would like to take this opportunity to encourage library authors to submit their material to the haskell hackage. the haskell infrastructure is rather big, complex and "organic". (see e.g. http://darcs.haskell.org/tmp/ for an example) it was only by chance that i ran across the (rather amazing) htam library a week ago or so. i hope you agree that these things should not be left to chance ;-) hoogle, google and hackage tend to be the first places where i look for fresh meat. i suppose this also applies to other haskell freshmen. cheers, v. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Application of iterate
On Fri, 23 Mar 2007, Vincent Kraeutler wrote: > as a fellow haskell newbie, i would like to take this opportunity to > encourage library authors to submit their material to the haskell hackage. > > the haskell infrastructure is rather big, complex and "organic". (see > e.g. http://darcs.haskell.org/tmp/ for an example) it was only by chance > that i ran across the (rather amazing) htam library a week ago or so. i > hope you agree that these things should not be left to chance ;-) > > hoogle, google and hackage tend to be the first places where i look for > fresh meat. i suppose this also applies to other haskell freshmen. I suspect, that a Hackage package let you think that my sandbox is something fixed and well-done, which is certainly not true. Why didn't Google lead you to http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics#Miscellaneous_libraries ? Of course, I would like to get indexed in haskell.org/hoogle - but how to do that? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Application of iterate
Hi ? Of course, I would like to get indexed in haskell.org/hoogle - but how to do that? Wait for Hoogle 4, sadly. Once thats done, by adding your package to hackage you'll be indexed by Hoogle. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rank-2-polymorphism problem
On Fri, Mar 23, 2007 at 02:18:50PM +0100, Martin Huschenbett wrote: > > -- The type I want to get. > readValue' :: Field -> (forall s. SqlBind s => Maybe s) -> Value > > -- First trial: > readValue' fld s = > if isJust s then readValue fld (fromJust s) else emptyValue fld Is there a reason you don't want this?: readValue' :: Field -> Maybe (forall s. SqlBind s => s) -> Value readValue' fld s = if isJust s then readValue fld (fromJust s) else emptyValue fld Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rank-2-polymorphism problem
Ian Lynagh schrieb: readValue' :: Field -> Maybe (forall s. SqlBind s => s) -> Value readValue' fld s = if isJust s then readValue fld (fromJust s) else emptyValue fld Thank you very much, that's exactly what I wanted. After reading in the GHC users guide about rank 2 polymorphism I thought that this is not possible. Chapter "7.4.8. Arbitrary-rank polymorphism" says: There is one place you cannot put a forall: you cannot instantiate a type variable with a forall-type. So you cannot make a forall-type the argument of a type constructor. So these types are illegal: x1 :: [forall a. a->a] x2 :: (forall a. a->a, Int) x3 :: Maybe (forall a. a->a) Maybe the users guide is not precise enough at this point. Regards, Martin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Rank-2-polymorphism problem
Hello, What Ian suggested is a very GHC 6.6 specific solution that uses much more that simply rank-2 types. Here is another solution that uses just rank-2 types (and, by the way, all type signatures are optional, as in ordinary Haskell): module Value where class SqlBind a where fromSqlValue :: String -> a data Field data Value emptyValue :: Field -> Value emptyValue _ = undefined data Binder = Binder (forall s. SqlBind s => s) readValue :: Field -> Binder -> Value readValue _ (Binder _) = undefined readOptValue :: Field -> Maybe Binder -> Value readOptValue f x = maybe (emptyValue f) (readValue f) x Hope this helps -Iavor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AI Strike Force!
Hi Andrew and all the involved, The idea is great. It will allow programming with a rewording feeling of depth to the exercise right from the start. However tackling some of the topics you mentioned, like GA, one first needs to develop new solid programming techniques that would circumvent Haskell's inbuilt reluctance to update variables distractively. I would myself wish to read a well documented study of using ST monad or finite maps to achieve this end. Perhaps then, your page should openly encourage the need to develop such "brute force" methods. Cheers, -Andrzej ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Application of iterate
On Fri, Mar 23, 2007 at 01:04:47PM +0200, Logesh Pillay wrote: > my_sqrt t = last (take 20 (iterate (\n -> n/2 + t/(2 * n)) t)) > > It is a bit crude though. 20 iterations is a bit arbitrary. I don't suppose > there is a easy way to iterate until the results stop changing. > perhaps > sqrt t = head [ n | (n,True) <- iterate (\n -> let n' = n/2 + t/(2 * n) in > (n',n' == n)) t ] John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AI Strike Force!
Hi Andrew and all the involved, The idea is great. It will allow programming with a rewording feeling of depth to the exercise right from the start. However tackling some of the topics you mentioned, like GA, one first needs to develop new solid programming techniques that would circumvent Haskell's inbuilt reluctance to update variables distractively. I would myself wish to read a well documented study of using ST monad or finite maps to achieve this end. Perhaps then, your page should openly encourage the need to develop such "brute force" methods. Cheers, -Andrzej ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rank-2-polymorphism problem
Hi again, the solutions/proposals of Ian and Iavor seem to be exactly what I need at a first glance. But looking at them more in detail reveals some other problems. I also have got a function > getFieldValueMB :: SqlBind s => Statement -> String -> Maybe s To get Ians approach working I would need a function of type > getFieldValueMB' :: Statement -> String -> Maybe (forall s. SqlBind s => s) and for Iavor approach I would need a function of type: > getFieldValueMB' :: Statament -> String -> Maybe Binder which are almost the same. The remaining problem is: How can I construct either of these functions? My thoughts were that for any class C the types > Maybe (forall a. C a => a) (I will call it T1 for short) and > (forall a. C a => Maybe a) (I will call it T2 for short) are isomorphic. Defining the isomorphism from T1 to T2 is quite simple: iso1 :: Maybe (forall a. C a => a) -> (forall a. C a => Maybe a) iso1 (Just s) = Just s iso1 Nothing = Nothing But I don't catch how to define the isomorphism of the other direction (from T2 to T1). I would guess that defining this isomorphism would also solve my problem concerning the SQL stuff. So, is there anybody who knows how to define this isomorphism in a way that GHC-6.6 can compile it? Thanks for you help in advance, Martin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can we do better than duplicate APIs? [was: Data.CompactString 0.3]
[sorry for the somewhat longer rant, you may want to skip to the more technical questions at the end of the post] Twan van Laarhoven wrote: > I would like to announce version 0.3 of my Data.CompactString library. > Data.CompactString is a wrapper around Data.ByteString that represents a > Unicode string. This new version supports different encodings, as can be > seen from the data type: > > [...] > > Homepage: http://twan.home.fmf.nl/compact-string/ > Haddock: http://twan.home.fmf.nl/compact-string/doc/html/ > Source:darcs get http://twan.home.fmf.nl/repos/compact-string After taking a look at the Haddock docs, I was impressed by the amount of repetition in the APIs. Not ony does Data.CompactString duplicate the whole Data.ByteString interface (~100 functions, adding some more for encoding and decoding), the whole interface is again repeated another four times, once for each supported encoding. Now, this is /not/ meant as a criticism of the compact-string package in particular. To the contrary, duplicating a fat interface for almost identical functionality is apparently state-of-the-art in Haskell library design, viz. the celebrated Data.Bytesting, whose API is similarly repetitive (see Data.List, Data.ByteString.Lazy, etc...), as well as Map/IntMap/SetIntSet etc. I greatly appreciate the effort that went into these libraries, and admire the elegance of the implementation as well as the stunning results wrt. efficiency gains etc.. However I fear that duplicating interfaces in this way will prove to be problematic in the long run. The problems I (for-)see are for maintenance and usability, both of which are of course two sides of the same coin. For the library implementer, maintenance will become more difficult, as ever more of such 'almost equal' interfaces must be maintained and kept in sync. One could use code generation or macro expansion to alleviate this, but IMO the necessity to use extra-language pre-processors points to a weakness in the language; it be much less complicated and more satisfying to use a language feature that avoids the repetition instead of generating code to facilitate it. On the other side of teh coin, usability suffers as one has to lookup the (almost) same function in more and more different (but 'almost equal') module interfaces, depending on whether the string in question is Char vs. Byte, strict vs. lazy, packed vs. unpacked, encoded in X or Y or Z..., especially since there is no guarantee that the function is /really/ spelled the same everywhere and also really does what the user expects.(*) I am certain that most, if not all, people involved with these new libraries are well aware of these infelicities. Of course, type classes come to mind as a possible solution. However, something seems to prevent developers from using them to capture e.g. a common String or ListLike interface. Whatever this 'something' is, I think it should be discussed and addressed, before the number of 'almost equal' APIs becomes unmanageable for users and maintainers. Here are some raw ideas: One reason why I think type classes have not (yet) been used to reduce the amount of API repetition is that Haskell doesn't (directly) support abstraction over type constraints nor over the number of type parameters (polykinded types?). Often such 'almost equal' module APIs differ in exactly these aspects, i.e. one has an additional type parameter, while yet another one needs slightly different or additional constraints on certain types. Oleg K. has shown that some if these limitations can be overcome w/o changing or adding features to the language, however these tricks are not easy to learn and apply. Another problem is the engineering question of how much to put into the class proper: there is a tension between keeping the class as simple as possible (few methods, many parametric functions) for maximum usability vs. making it large (many methods, less parametric functions) for maximum efficiency via specialized implementations. It is often hard to decide this question up front, i.e. before enough instances are available. (This has been stated as a cause for defering the decision for a common interface to list-like values or strings). Since the type of a function doesn't reveal whether it is a normal function with a class constraint or a real class method, I imagine a language feature that (somehow) enables me to specialize such a function for a particular instance even if it is not a proper class member. Or maybe we have come to the point where Haskell's lack of a 'real' module system, like e.g. in SML, actually starts to hurt? Can associated types come to the rescue? Cheers Ben -- (*) I know that strictly speaking a class doesn't guarantee any semantic conformance either, but at least there is a common place to document the expected laws that all implementations should obey. With duplicated module APIs there is no such single place. ___ Haske
[Haskell-cafe] Re: Bouncing ball in Gtk2Hs
On Fri, 2007-03-23 at 20:24 +0300, Thach Si Lam wrote: > I'm trying to write Bouncing Ball demo in Gtk2hs. But i coudn't find > timer class (like in wxhaskell demo) in Gtk2hs. There is timeoutAdd: http://haskell.org/gtk2hs/docs/gtk2hs-docs-0.9.10/System-Glib-MainLoop.html#v%3AtimeoutAdd used like so: timeoutAdd action 1000 where action is an action with type IO Bool and the number is the time to wait in milliseconds, (ie 1000 is 1 second). If the action returns True then it will get called again at the next timeout, otherwise it will not be called again. > How to deal with it ? In fact i have 2 processes: p1 for computing > some variables and p2 for changing (applying those variables) in > canvas. How to let them communicate together and update to canvas ? > Please, help me. Thank you very much. I'm forwarding this to the Haskell Cafe mailing list where someone might be able to give you a pointer. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why the Prelude must die
This is a ranty request for comments, and the more replies the better. 1. Namespace pollution The Prelude uses many simple and obvious names. Most programs don't use the whole Prelude, so names that aren't needed take up namespace with no benefit. 2. Monomorphism The Prelude defines many data types (e.g Lists), and operations on these types. Because the Prelude is imported automatically, programmers are encouraged to write their programs in terms of non-overloaded operators. These programs then fail to generalize. This is a highly non-academic concern. Many widely used libraries, such as Parsec, operate only on lists and not the newer and more efficient sequence types, such as bytestrings. 3. Supports obsolete programming styles The Prelude uses, and by means of type classes encourages, obsolete and naive programming styles. By providing short functions such as nub automatically while forcing imports to use sets, the Prelude insidiously motivates programmers to treat lists as if they were sets, maps, etc. This makes Haskell programs even slower than the inherent highlevelness of laziness requires; real programs use nub and pay dearly. More damagingly, the Prelude encourages programmers to use backtracking parsers. Moore's law can save you from nub, but it will never clarify "Prelude.read: no parse". 4. Stagnation Because every program uses the Prelude, every program depends on the Prelude. Nobody will willingly propose to alter it. (This is of course Bad; I hope Haskell' will take the fleeting opportunity to break to loop) 5. Inflexibility Because of Haskell's early binding, the Prelude always uses the implementation of modules that exists where the Prelude was compiled. You cannot replace modules with better ones. 6. Dependency Because every module imports the Prelude every module that the Prelude depends on, mutually depends with the Prelude. This creates huge dependency groups and general nightmares for library maintainers. 7. Monolithicity Every module the Prelude uses MUST be in base. Even if packages could be mutually recursive, it would be very difficult to upgrade any of the Prelude's codependents. 8. Monolithic itself Because the Prelude handles virtually everything, it is very large and cannot be upgraded or replaced piecemeal. Old and new prelude parts cannot coexist. 9. One-size-fits-all-ism Because the Prelude must satisfy everyone, it cannot be powerful, because doing so would harm error messages. Many desirable features of Haskell, such as overloaded map, have been abandoned because the Prelude needed to provide crutches for newbies. 10. Portability Because the Prelude must be available everywhere, it is forced to use only least-common-denominator features in its interface. Monad and Functor use constructor classes, even though MPTC/FD is usefully far more flexible. The Class_system_extension_proposal, while IMO extremely well designed and capable of alleviating most of our class hierarchy woes, cannot be adopted. 11. Committeeism Because the Prelude has such a wide audience, a strong committee effect exists on any change to it. This is the worst kind of committeeism, and impedes real progress while polluting the Prelude with little-used features such as fail in Monad (as opposed to MonadZero) and until. 12. There is no escape Any technical defect in Map could be fixed by someone writing a better Map; this has happened, and the result has been accepted. Defects in the PackedString library have been fixed, with the creation and adoption of ByteString. Defects in System.Time have been fixed, by the creation and adoption of Data.Time. Ditto for Binary and Arrays and Network and Regex. But this will never happen for the Prelude. A replacement Prelude cannot be adopted because it is so easy to take the implicit import of the default one. Nobody will go out of their way to 'import Prelude() ; import FixedPrelude'. Psychology trumps engineering. 13. There can be no escape The Prelude was designed by extremely smart people and was considered close to perfect at the time. It is almost universally hated now. Even if all the issues I describe could be fixed (which I consider unlikely), the Prelude will almost certainly be hated just as universally five years hence. 14. My future Given all these issues, I consider the only reasonable option is to discard the Prelude entirely. There will be no magic modules. Everything will be an ordinary library. HOFs like (.) are available from Control.Function. List ops come from Data.List. Any general abstractions can be added in abstract Sequence, Monad, etc. modules. Haskell will regain the kind of organic evolution whose lack currently causes Haskell to lose its lead over Python et al by the day. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why the Prelude must die
stefanor: > This is a ranty request for comments, and the more replies the better. Use -fno-implicit-prelude and roll your own Prelude. Stick it on hackage and everyone can use it. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why the Prelude must die
Given all these issues, I consider the only reasonable option is to discard the Prelude entirely. There will be no magic modules. Everything will be an ordinary library. HOFs like (.) are available from Control.Function. List ops come from Data.List. Any general abstractions can be added in abstract Sequence, Monad, etc. modules. Haskell will regain the kind of organic evolution whose lack currently causes Haskell to lose its lead over Python et al by the day. I basically agree with a lot of the things you say. The only thing is: it's so convenient to have the Prelude. I can just start writing my haskell programs and don't have to worry about all kinds of imports. And you'll end up being repetitive: you'll import (.) and stuff like that in _every_ file. Yeah, this will definitely be more modular, but if we go for it, it's going to be so much more (tedious) work to create a new program. -chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
