- Haskell-Cafe - Haskell.org

Fwd: [Haskell-cafe] Haskell as a religion
by Alberto G. Corona 19 Dec '08

19 Dec '08

But many features need other features. For example, the option to use referential transparency will be common in future languages for multicore programming purposes. This creates the problem of separating side-effect-free code from side-effect code. For this purpose, a strong type system at compile time is needed, which indeed need automatic type inference or, else, the user will be too busy with the details. The type inference open the door for experimenting with complex data types. class types is a logical step after that. Monads are the best option for many problems once the programmer have all te above. higuer order functions are being taken seriously in other languages. this goes to the need of currying and lists. optional lazyness and tail recursion is the most elegant option for expressing lists managing code. Will all the above, explicit loops will be avoided by the programmer, this will end up in mode declarative programming style. I think that once the average programmer start to use one or two of these features, he will feel a bit frustrated if its language don´t have all the others, specially if he know haskell. Probably, he will use haskell for fun. This is the best way for the takeover of the industry, because this has been so historically. 2008/12/18 John Goerzen <jgoerzen(a)complete.org> Andrew Coppin wrote: > > Don Stewart wrote: > >> I think of Haskell more as a revolutionary movement > > > > LOL! Longest revolution EVER, eh? I mean, how long ago was its dogma > > first codified? ;-) > > Lisp has been around for how long now? Measured in decades. We don't > even have our version of a Symbolics machine yet! > > > Basically, Haskell will never be popular, but its coolest ideas will be > > stolen by everybody else and passed off as their own. :-( > > Well, in a sense, if that happens, we would have won, right? We'd have > created a situation where "paradigm shift" would mean more than just a > buzzword on some CEO's presentation slide ;-) > > In another sense, isn't this what Haskell was explicitly created to do? > (Combine ideas from a bunch of similar languages into one standard one) > > Some ideas in Haskell are easy to integrate into other languages: see > list comprehensions in Python. I don't see Perl picking up pervasive > laziness anytime soon, nor Python compile-time type inference. > > -- John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

6 5

Automatic instance constraints derivation: how?
by Dimitry Golubovsky 19 Dec '08

19 Dec '08

Hi, I am trying to understand, why do I need to place constraints with class instance declaration while all the information seems to be already available to the compiler. I have placed the code in question here: http://codepad.org/Akew0p2t so anybody can play with it. The code tries to model evaluation of GRIN-style thunks using Haskell type classes instead of tag-based pattern matching, as in the GRIN papers. That is, a thunk is represented as a datatype like data Ffun a b c = Ffun a b c, and there is some "eval" function which being applied to such data results in the call fun a b c. Such "eval" function is a method of class Eval: class Eval a b | a -> b where eval :: (Monad m) => a -> m b which means that thunks of some type (a) evaluate to values of some dependent type (b). The code is monadic because GRIN is a monad, so the code looks similar to GRIN. The ultimate goal is to make GRIN code understandable by Haskell compiler. Everything is fine with "simple" types like Int, that is "instance Eval Int Int" means that Int (and Char, and Bool) do not need in fact evaluation at all. instance Eval Int Int where eval = return Everything is fine with thunks encoding calls to primitives. See instances for FADD and FSUB. All type information for primitives (primPlusInt, primMinusInt) is specified in the code. Then, a function "fun" is defined that calls the primitives. The "main" function illustrates its use, and everything works as expected, as output shows. But when I tried to define a thunk for "fun" (instance for Ffun) I was only able to do that with all constraints on its parameters explicitly set. OTOH, even if I comment out the instance Eval for Ffun, and load the code in Hugs (or GHCi, doesn't matter) then type signature of "fun" is correctly derived by the compiler. If I try to define instance for Ffun like this: instance (Eval x x) => Eval (Ffun a b c) x where eval (Ffun a b c) = fun a b c meaning only the fact that result of the function "fun" will be like Int or Bool - evaluates to itself, and we don't care about the types of arguments, I cannot use forall x. with instance declaration, so I have to say something about x. I get the error (Hugs): Error occurred ERROR line 51 - Instance is more general than a dependency allows *** Instance : Eval (Ffun a b c) d *** For class : Eval a b *** Under dependency : a -> b So, is there a way to define such an instance for a thunk without any constraints? Wouldn't it be reasonable to expect that eval (Ffun a b c) = fun a b c would allow the compiler to retrieve constraints on a, b, c from those already known for the called function? Thanks. -- Dimitry Golubovsky Anywhere on the Web

1 0

Fwd: Fwd: [Haskell-cafe] Haskell as a religion
by Alberto G. Corona 19 Dec '08

19 Dec '08

---------- Forwarded message ---------- From: Alberto G. Corona <agocorona(a)gmail.com> Date: 2008/12/19 Subject: Re: Fwd: [Haskell-cafe] Haskell as a religion To: Dan Piponi <dpiponi(a)gmail.com> As far as I know, const only protect from updates that the compiler can detect at compilation time. Moreover, the C/C++ code does not make use of true referential transparency properties, for example const a=1; const b=a perform a copy of content of a to b . In haskell a=1; b=a make b to point to a directly. 2008/12/19 Dan Piponi <dpiponi(a)gmail.com> On Thu, Dec 18, 2008 at 4:15 PM, Henning Thielemann > <schlepptop(a)henning-thielemann.de> wrote: > > > In C/C++ referential transparent functions code can be declared by > > appending a 'const' to the prototype, right? > > For one thing, some fields in a const C++ object can be explicitly set > mutable. mutable is sometimes used in C++ a similar way to > unsafePerformIO in Haskell. You have something that uses mutability in > its internals but that mutability shouldn't be observable to the > caller. In both cases you have no means of actually ensuring that the > mutability is actually unobservable. > -- > Dan >

1 0

Thread scheduling and GHC.Conc
by Jake Foell 19 Dec '08

19 Dec '08

using ghc v6.8.2 Problem: I am creating a program that forks two other lightweight threads. One of the forked threads seems to be stuck or dead after running successfully for a non-trivial amount of time. I am receiving no error messages. Questions: What is the best way to diagnose this problem? (perhaps a ghc upgrade to a version that includes processStatus?) Does the runtime system ensure that no thread will starve for processor time? My initial diagnosis: by looking at log files that this program produces, it seems that the thread in question is failing while receiving a response from a server. Here is a simplified exerpt: h <- connectTo server port appendFile file "Connection Established\n" hPutStr h httpRequestString hFlush h reply <- hGetContents h appendFile file reply If I look at the tail of file that is created, I see something similar to this: ... Connection Established here is the response... Connection Established Answers to my questions and/or any advice would be appreciated. thanks

3 2

lengthOP rewrite rules
by Cetin Sert 19 Dec '08

19 Dec '08

Hi *^o^*, With the following rewrite rules: lengthOP :: (Num a, Ord a) ⇒ Bool → (a → a → Bool) → [b] → a → Bool lengthOP v (⊜) [] n = 0 ⊜ n lengthOP v (⊜) xxs n = co xxs 0 where co [] c = c ⊜ n co (_:xs) c | n > c = co xs (c+1) | otherwise = v lenEQ = lengthOP False (==) lenLT = lengthOP False (<) lenLE = lengthOP False (<=) lenGT = lengthOP True (>) lenGE = lengthOP True (>=) {-# RULES -- | length "lenEQ_LHS" forall xs n. (length xs) == n = lenEQ xs n "lenLT_LHS" forall xs n. (length xs) < n = lenLT xs n "lenLE_LHS" forall xs n. (length xs) <= n = lenLE xs n "lenGT_LHS" forall xs n. (length xs) > n = lenGT xs n "lenGE_LHS" forall xs n. (length xs) >= n = lenGE xs n "lenEQ_RHS" forall xs n. n == (length xs) = lenEQ xs n "lenLT_RHS" forall xs n. n < (length xs) = lenGE xs n "lenLE_RHS" forall xs n. n <= (length xs) = lenGT xs n "lenGT_RHS" forall xs n. n > (length xs) = lenLE xs n "lenGE_RHS" forall xs n. n >= (length xs) = lenLT xs n -- | genericLength "glenEQ_LHS" forall xs n. (genericLength xs) == n = lenEQ xs n "glenLT_LHS" forall xs n. (genericLength xs) < n = lenLT xs n "glenLE_LHS" forall xs n. (genericLength xs) <= n = lenLE xs n "glenGT_LHS" forall xs n. (genericLength xs) > n = lenGT xs n "glenGE_LHS" forall xs n. (genericLength xs) >= n = lenGE xs n "glenEQ_RHS" forall xs n. n == (genericLength xs) = lenEQ xs n "glenLT_RHS" forall xs n. n < (genericLength xs) = lenGE xs n "glenLE_RHS" forall xs n. n <= (genericLength xs) = lenGT xs n "glenGT_RHS" forall xs n. n > (genericLength xs) = lenLE xs n "glenGE_RHS" forall xs n. n >= (genericLength xs) = lenLT xs n #-} 1) Is there a way to tell where 'length' is mentioned, what is meant is for example 'Prelude.length' or any length that works on lists? 2) How can I avoid the following error messages? module Main where import Data.List main :: IO Int print $ length (repeat 0) > 200 print $ 200 < length (repeat 0) print $ genericLength (repeat 0) > 200 -- error print $ 200 < genericLength (repeat 0) -- error return 0 ########: Could not deduce (Ord i) from the context (Eq i, Num i) arising from a use of `lenEQ' at ######## Possible fix: add (Ord i) to the context of the RULE "glenEQ_LHS" In the expression: lenEQ xs n When checking the transformation rule "glenEQ_LHS" ########: Could not deduce (Ord a) from the context (Eq a, Num a) arising from a use of `lenEQ' at ######## Possible fix: add (Ord a) to the context of the RULE "glenEQ_RHS" In the expression: lenEQ xs n When checking the transformation rule "glenEQ_RHS" 3) What speaks for/against broad usage of such rewrite rules involving list lengths? Best Regards, Cetin Sert

5 7

Conditional properties in QuickCheck alter test data generation?
by Kevin Van Horn 19 Dec '08

19 Dec '08

I'm learning QuickCheck, and I'm puzzled by the behavior I'm seeing with conditional properties. After writing and loading a simple qsort function from a separate file, I typed these into ghci: let prop_minimum xs = (length xs > 0) ==> head (qsort xs) == minimum xs where types = xs :: [Integer] let prop_minimum1 xs = (length xs > 3) ==> head (qsort xs) == minimum xs where types = xs :: [Integer] These differ only in that prop_minimum1 uses a more restrictive condition. Then quickCheck prop_minimum outputs "OK, passed 100 tests" but quickCheck prop_minimum1 outputs "Arguments exhausted after 0 tests" Investigating with verboseCheck yields puzzling results. For example, verboseCheck prop_minimum says "OK, passed 100 tests", but some of the test instances it shows have length 0, contrary to the condition... and a significant fraction of the test instances have length > 3, or even length > 10! So why the problem when running quickCheck on prop_minimum1? Running verboseCheck prop_minimum1 just deepens the mystery. Now we see most of the test instances generated having 0 length, and none of them having length > 3. What's going on here? Why is the distribution of generated test instances so drastically altered? BTW, I'm using ghc version 6.10.1, running on Intel Mac OS 10.5.5.

5 6

RWH book club
by Don Stewart 19 Dec '08

19 Dec '08

Matt Podwysocki set up a Real World Haskell book club, http://groups.google.com/group/real-world-haskell-book-club (a mailing list on google groups), with already some 200 members discussing typical new user Haskell questions. Feel free to join if you like talking about Haskell, or teaching new users. -- Don

1 0

ANN: Thingie-0.80
by Jeff Heard 18 Dec '08

18 Dec '08

I need a better name for this, but I have software, so I shall release it with a dumb name. Thingie has just been uploaded to hackage. It is a library for creating 2D visualizations in a purely functional manner. It supports static visualizations and animation, and like most vis libraries, can probably do games as well as simple viz graphics. The backend uses Cairo for rendering, but I'm looking to port it to OpenGL/GLUT for systems where Gtk/Cairo is hard to get working (i.e. OS/X). The idea is that you create a graph of objects or function that return objects and the library renders them for you in 2D. Right now, there's one thing I would like to add to the system above all other things: The interactive system has the concept of a tracked program state that is threaded through the graph. This state is defined by a UIState class, and any state (which is a record object) must be an instance of UIState and provide the system with a certain number of getters and setters for basic bits of state. I would like to use Template Haskell to help create/derive these structures. Does anyone on the list want to help with that? Here are two examples. Each draws a smiley face, and the interactive one tracks your mouse with a little red ball. First the non-interactive: module Main where import Graphics.Rendering.Thingie.Primitives import Graphics.Rendering.Thingie.Cairo import qualified Graphics.Rendering.Cairo as Cairo smiley = Context [FillRGBA 0 0 0 0, Operator Cairo.OperatorClear] $ Group [Draw rectangleFilled{ topleft=Point2D 0 0, width=200, height=200 } ,Context [FillRGBA 1 1 0 1, OutlineRGBA 0 0 0 1, Translate 100 100, Operator Cairo.OperatorOver] $ Group [Draw arc{ radius=100, filled=True } ,Context [FillRGBA 0 0 0 1] $ Group [Draw arc{ center=Point2D (-33) (-33), radius=10, filled=True } ,Draw arc{ center=Point2D 33 (-33), radius=10, filled=True } ,Draw arc{ angle1=degrees 30, angle2=degrees 150, radius=70 }]]] main = renderObjectToPNG "smiley.png" 200 200 smiley ----- Now the interactive: import Graphics.Rendering.Thingie.Interactive import Graphics.Rendering.Thingie.BasicUIState import Graphics.Rendering.Thingie.Cairo import Graphics.Rendering.Thingie.Primitives import qualified Graphics.Rendering.Cairo as Cairo smiley = Context [FillRGBA 0 0 0 0, Operator Cairo.OperatorClear] $ Group [Draw rectangleFilled{ topleft=Point2D 0 0, width=200, height=200 } ,Context [FillRGBA 1 1 0 1, OutlineRGBA 0 0 0 1, Translate 100 100, Operator Cairo.OperatorOver] $ Group [Draw arc{ radius=100, filled=True } ,Context [FillRGBA 0 0 0 1] $ Group [Draw arc{ center=Point2D (-33) (-33), radius=10, filled=True } ,Draw arc{ center=Point2D 33 (-33), radius=10, filled=True } ,Draw arc{ angle1=degrees 30, angle2=degrees 150, radius=70 }]]] undercursor uistate = Context [FillRGBA 1 0 0 1] $ Draw arcFilled{ center=mousePosition uistate, radius=5 } scene = [StaticElement smiley (Rect2D 0 0 0 0) ,UnboundedElement undercursor] main = simpleMotionSensitiveGui defaultBasicUIState scene "smiley face"

1 1

Coroutines
by Ryan Ingram 18 Dec '08

18 Dec '08

Andrew was recently asking about co-routines. A couple of years ago, I was in much the same position as him; although I am pretty sure I had heard the term before, it seemed like a mysterious idea with no practical use. Then I learned Ruby. Ruby makes extensive use of coroutines; it's not uncommon to have three or more coroutines executing cooperatively, made simple by how easy it is to pass blocks of code around in that language. The entire collection iteration system in Ruby is based on coroutines; if an object implements "each", it can be iterated over: [1, 2, 3].each { |x| print x } Implementing "each" for a container is generally simple; you just write a loop and call "yield" def each [1 .. length].each { |index| yield self[index] } end It surprised me how simple and powerful this concept was; code that previously was incredibly ugly to write became simple. I think this abstraction is one of the big reasons for Ruby's current success. At the Haskell Symposium this year, Jesse Tov gave a talk about Session Types in Haskell, and it struck me that they are ideal for implementing coroutines in a type-safe manner. Here you can write pure functions that represent a communicating routines, and guarantee that the communication completes successfully (assuming the routines terminate, of course). Consider these two values: f1 :: Int -> (Char, ()) f2 :: (Int, Char -> String) You can see a natural way to connect them, using the duality of (a, _) and (a -> _): connect_f1f2 :: ((), String) connect_f1f2 = let (arg1, k2) = f2 (arg2, result1) = f1 arg1 result2 = k2 arg2 in (result1, result2) I implemented this idea, along with a nice syntax for these coroutines, in http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Coroutine-0.1.0.0: f1 :: InSession (Int :?: Char :!: Eps) () f1 = runSession $ do x <- get put (head $ show x) return () f2 :: InSession (Int :!: Char :?: Eps) String f2 = runSession $ do put 6 result <- get return ("the answer is " ++ [result]) (Caveat: while this uses the do-notation, it's not *exactly* a monad; it's something more general than that. See Control.Monad.Indexed for the details. Thanks to the GHC team for NoImplicitPrelude!) You can then add choice, looping constructs, etc., to allow increasingly complicated protocols: peer1 :: InSession ((Int :?: Int :!: Eps) :?* Eps) Int -- read an Int, then write an Int, any number of times we are told to do so -- then return an Int peer2 :: InSession ((Int :!: Int :?: Eps) :!* Eps) [Int] -- write an Int, then read an Int, any number of times we want -- then return a list of Ints. The neat thing about this library is that the communication is completely pure! No side effects required! ghci> :t connect peer1 peer2 connect peer1 peer2 :: (Int, [Int]) -- ryan On Wed, Dec 17, 2008 at 6:54 PM, Richard O'Keefe <ok(a)cs.otago.ac.nz> wrote: > On 18 Dec 2008, at 11:26 am, Andrew Coppin wrote: >>> >>> (Also, "coroutines"? Seriously? That's hardly an obscure term in >>> programming circles.) >>> >> >> Well now, I'm curios. I've been writing computer programs since I was 9 >> years old. I hold a diploma *and* an honours degree in computer science. And >> I have never even *heard* of a coroutine. To this day I still don't know >> what it means. I rather suspect I'm not the only "programmer" on earth who >> finds themselves in this position. ;-) > > Shame on you for not reading Knuth's > "The Art of Computer Programming", Volume 1, "Fundamental Algorithms". > The then available three volumes of TAOCP > "were named among the best twelve physical-science monographs > of the century by American Scientist" "at the end of 1999". > (Fasicles 0, 2, 3, and 4 of volume 4 are now available, and > parts of fasicle 1 are on-line. Hooray hooray!) > > Quoting the first two paragraphs of the Wikipedia entry: > "In computer science, coroutines are program components that generalize > subroutines to allow multiple entry points for suspending and resuming of > execution at certain locations. Coroutines are well-suited for implementing > more familiar program components such as cooperative tasks, iterators, > infinite lists and pipes. > The term "coroutine" was originated by Melvin Conway in his seminal 1963 > paper.[1]" > > So "coroutine" has been standard hacker-type programming terminology > since 1963. I was able to use coroutines in Burroughs Extended Algol > (designed in the mid to late 60s), Simula 67, and Interlisp-D (80s). > Current languages supporting them include (thanks, Wikipedia) Lua, > Limbo, JavaScript, Python, and Ruby. Since anything with continuations > can do coroutines, we add Scheme and SML/NJ. Sather's iterators may be > a more familiar form of coroutine. You will commonly find something > like a "yield e" statement that reports the value of e to the caller > without actually returning, and "resume c" that resumes a coroutine > to get the next value. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

3 2

gtk2hs question - derive SettingsWindow from Window
by Cetin Sert 18 Dec '08

18 Dec '08

Hi all, For a network manager of sorts I'm working on, I want to derive a SettingsWindowClass from the WindowClass present in Gtk2Hs: I want (the) instance(s) of the SettingsWindowClass to have a field to store connection settings: 1) Is it safe to do it like this? class WindowClass self ⇒ SettingsWindowClass self where settingsWindowGetSettings :: self → IO [ConnectionSetting] settingsWindowSetSettings :: self → [ConnectionSetting] → IO () newtype SettingsWindow = SettingsWindow (Window,[ConnectionSetting]) mkSettingsWindow = SettingsWindow unSettingsWindow (SettingsWindow o) = o settingsWindowNew :: IO SettingsWindow settingsWindowNew = do win ← windowNew return $ mkSettingsWindow (win,[]) 2) Is this a common practice in gtk2hs usage? 3) And will GC properly free the memory allocated for the Window object? How is this ensured, do ForeignPtr's always call delete on the underlying C ptr when they get garbage collected? Best Regards, CS

2 1