- Haskell-Cafe - Haskell.org

iterative algorithms: how to do it in Haskell?
by Tamas K Papp 21 Aug '06

21 Aug '06

Hi, I am a newbie learning Haskell. I have used languages with functional features before (R, Scheme) but not purely functional ones without side-effects. Most of the programming I do is numerical (I am an economist). I would like to know how to implement the iterative algorithm below in Haskell. f is an a->a function, and there is a stopping rule goOn(a,anext) :: a a -> Bool which determines when to stop. The algorithm looks like this (in imperative pseudocode): a = ainit while (true) { anext <- f(a) if (goOn(a,anext)) a <- anext else stop and return anext } For example, f can be a contraction mapping and goOn a test based on the metric. I don't know how to do this in a purely functional language, especially if the object a is large and I would like it to be garbage collected if the iteration goes on. Thank you, Tamas

11 18

Haddock/Cabal/base bug?
by Neil Mitchell 21 Aug '06

21 Aug '06

Hi, I want to generate documentation for the base libraries, so I darcs get the base libraries, and a very basic (the sample default) Setup.hs, and try: runhaskell Setup configure runhaskell Setup build Pretty much no luck, but I'll leave that for someone else to sort out :) runhaskell Setup haddock First task is to remove errors about -fno-implicit-bangs, which are in a few files, relatively easy to do. After that it gets quite far (invokes haddock a fair bit) before failing with: haddock.exe: Main.all_subs_of_qname: unexpected unqual'd name:IOMode This is on Windows, cabal, base and haddock all fresh from darcs, GHC 6.4.2 Can anyone point out what the problem is, whose fault it is, and what can be done to fix it? Thanks Neil

2 2

type gurus, can you please help?
by Bulat Ziganshin 21 Aug '06

21 Aug '06

Hello haskell, i'm started to write article about type classes. can you, type gurus, please check this initial text for correctness in explaining differences between classes and type classes? at this moment C++/C#/Java languages has classes and templates/generics. what is a difference? with a class, type information carried with object itself while with templates it's outside of object and is part of the whole operation for example, if == operation is defined in a class, the actual procedure called for a==b may depend on run-time type of 'a' but if it is defined in template, actual procedure depends only on template instantiated (and determined at compile time) Haskell's objects don't carry run-time type information. instead, class constraint for polymorphic operation passed in form of "dictionary" implementing all operations of the class (there are also other implementation techniques, but this don't matter). For example, eqList :: (Eq a) => [a] -> [a] -> Bool translated into: type eqDictionary a = (a->a->Bool, a->a->Bool) eqList :: eqDictionary a -> [a] -> [a] -> Bool where first parameter is "dictionary" containing implementation of "==" and "/=" operations for objects of type 'a'. If there are several class constraints, dictionary for each is passed. If class has base class(es), the dictionary tuple also includes tuples of base classes dictionaries: class Eq a => Cmp a where cmp :: a -> a -> Comparision cmpList :: (Cmp a) => [a] -> [a] -> Comparision turns into: type cmpDictionary a = (eqDictionary a, a -> a -> Comparision) cmpList :: cmpDictionary a -> [a] -> [a] -> Bool Comparing to C++, this is like the templates, not classes! As with templates, typing information is part of operation, not object! But while C++ templates are really form of macro-processing (like Template Haskell) and at last end generates non-polymorphic code, Haskell's using of dictionaries allows run-time polymorphism (explanation of run-time polymorphism?). Moreover, Haskell type classes supports inheritance. Run-time polymorphism together with inheritance are often seen as OOP distinctive points, so during long time i considered type classes as a form of OOP implementation. but that's wrong! Haskell type classes build on different basis, so they are like C++ templates with added inheritance and run-time polymorphism! And this means that usage of type classes is different from using classes, with its own strong and weak points. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5 19

Ix, Random, and overlapping instances
by Lambda The Insignificant 21 Aug '06

21 Aug '06

Greetings Haskellers, I have recently found myself in a situation where I was needing to general tuples of randomized things; in my case, two coordinates and a custom data type, Direction. As it is always better to generalize, I decided to try to write some code which would generalize randomR to any type which is Ix-able: > instance Ix i => Random i where > random = error "No supported instance for random" > randomR r g > = let > r' = range r > (i, g') = randomR (0,length r'-1) g > in > (r' !! i, g') This works splendidly; with my given example above, I could do: > data Dir = N | NE | E | SE | S | SW | W | NW deriving (Eq, Ord, Show, Ix) ghci> newStdGen >>= print . take 10 . randomRs ((1,1,N),(10,10,NW)) [(5,4,S), (3,10,SE), (6,5,N), (6,6,NW), (10,8,SE), (3,10,W), (10,3,E), (1,6,NE), (10,10,SE), (3,3,S)] As you can see, this results in random tuple(s) of these indexable types. My implementation required -fallow-overlapping-instances and - fallow-undecidable-instances for the code to compile. A few questions: 1) How does the compiler determine how to choose a particular instance for those cases where they overlap? I noticed that if I tried to generate a random :: Int, I was getting the error message defined in the above instance, indicating that the compiler was choosing my implementation over the default for Int (obviously because Int is an instance of Ix). Is there some way to exclude classes in the class qualifier, or to provide an instance as a default case without resorting to -fallow-overlapping-instances? 2) Is there a logical overlap between class Ix and class Bounded? It seems that we could use the ranges of data types of Bounded to generate a reasonably sane `random` implementation for all Ix, if we can guarantee that all Ix instances are Bounded. Would adding an additional class constraint be sufficient to catch the major cases? i.e., instance (HasBounds i, Ix i) => Random i where ... 3) Is there some reason that Ix is restricted to the Int datatype? Is there anything preventing us from moving to a genericIx,or something along those lines which support any integral type (say Integer), or is it merely for performance reasons that we use Int? Is the expectation that if you are using spaces larger than what an Int can accommodate, you should be using a different mechanism? Thanks much for any comments you all can give. Cheers, Lambda the Insignificant

2 1

cabal specify a "tested version", ghci target?
by Marc Weber 21 Aug '06

21 Aug '06

1.) I know I can use Build-Depends: lib == <version>, lib2 < version, lib3 >= version and so on. Do you think it would be useful to introducue some notation to indicate a "tested with" ? Reason, purpose: I think its sometimes the case that a author/ mantainer is quite busy with other projects and misses that some dependencies break things.. If you want to try out you're left with some compiler errors and a dependency and have to try out which version works. I would propose using this syntax: lib-1.3 >=1.1 to indicate that lib 1.1 is required at leeast and tested with up to 1.3.. Cabal might then give a warning if you try to use 1.4 or greater "using newer version than tested" or similar.. What do you think? Would this be useful? 2.) Is there a ghci target? I find it quite useful using ghci to debug test/ check types functions of single modules... My hack is using a Setup.hs file like this adding ./setup ghci which runs ghci and adds all dependency as -pakcage arguments: module Main where import Distribution.Simple import Distribution.Simple.Configure import System import System.Process import System.Exit import Monad main= do args <- getArgs -- check args to launch ghci when (length args > 0) $ do when ((args!!0) == "ghci") $ do lbi <- getPersistBuildConfig let packageArgs = (concat.concat) [ [" -package ", showPackageId pkg] | pkg <- packageDeps lbi ] system("ghci " ++ packageArgs) exitWith ExitSuccess defaultMain -- fallback to defaultMain Would this be useful for you, too? Marc W.

3 2

A backwards-compatible record proposal
by Brian Hulley 20 Aug '06

20 Aug '06

Hi - As I've been writing a Haskell program over the past few months the main problem I encounter is that record field names are not local to the record type, and any systematic way of making them local (eg by prepending "_Tycon_") results in names that are just too clunky, and I feel that identifiers *must* use systematic naming conventions to get code that will be easy to understand and maintain. Although it is relatively easy to think up a better record system, it has taken me up till now to discover how such a system could be integrated with Haskell as it is at the moment, since it's unlikely that the existing record system will ever disappear, at least not in the next few years, and in fact, there are some good points about the existing record system that I wouldn't like to lose. I'll motivate the proposal then talk about how it could be implemented. Motivation ======= Consider the following: data Vector3 a = Vector3{x :: a, y::a, z::a } data Normal3 a = Normal3{x :: a, y::a, z::a } We've got a problem because (x) has been introduced twice to the top level namespace. In the above example, it could be argued that I should have written: data Arr3 a = Arr3 {x::a, y::a, z::a} newtype Vector3 a = Vector3 (Arr3 a) newtype Normal3 a = Normal3 (Arr3 a) but for the sake of argument, let's suppose we can't do this - perhaps one of the record types has some different fields as well. A related problem is suppose I have: data Size = {width :: Int, height :: Int} data Rect = Rect{x1, y1, x2, y2::Int} width :: Rect -> Int width Rect{x1,_,x2,_} = x2 - x1 because a record field of Size has the same name as a top level function. This second conflict can be avoided by always using the rule that record fields begin with an underscore and all other variables don't. So applying this to the first problem, we have: data Vector3 a = Vector3{_x :: a, _y::a, _z::a } data Normal3 a = Normal3{_x :: a, _y::a, _z::a } Of course we haven't solved it yet! But now suppose we introduce a new piece of syntactic sugar, and write: data Vector3 a = Vector3{.x :: a, .y::a, .z::a } data Normal3 a = Normal3{.x :: a, .y::a, .z::a } ie putting a '.' before each field name. The intended meaning is that dotted field names do *not* generate top level functions. Instead they allow the compiler to generate instance decls as follows, where we've introduced a new form of identifier, the dotted id, which behaves as a postfix operator which binds more tightly than function application and can also be used as a class name (by the compiler only): class (.x) :: a b | a -> b where (.x) :: a -> b class (.y) :: a b | a -> b where (.y) :: a -> b class (.z) :: a b | a -> b where (.z) :: a -> b For each dotted id, there is a class defined as above, which is available globally to the whole program as if a module containing an infinite set of class decls as above was exported by the Prelude. In the module containing the data decl for the record, the compiler inserts the following: instance (.x) (Vector3 a) a where (.x) v = ... -- compiler generated code to access the field Then within the rest of the program we can write: magSquared :: Num a => Vector3 a -> a magSquared v = v.x*v.x + v.y*v.y + v.z*v.z -- explicit type when specific function is required vec_x = ((.x) :: (Vector3 a -> a)) The advantage of this proposal is that it is completely backwards compatible with records as they are at the moment, and we can choose which fields we want to be dotted and which we want to just keep as normal top level functions. The only extra thing we need to do is put a dot before the field names we want to access via the dotted syntax, but we in any case needed to use an underscore when we wanted a systematic way to avoid conflicts between field names and other top-level names so there is no extra effort involved. Implementation ========== The above could almost be implemented just by parsing a source file containing uses of dotted fields and using a conversion like: data Rec a = Rec { .f :: a} let rec = Rec {.f = 78} -- dot is used here too p = rec.f * rec.f ==> data Rec a = Rec a instance Dot__f (Rec a) a where __dot_f (Rec a) = a let rec = Rec 78 p = __dot_f rec * __dot_f rec So far so good, but the alert reader :-) will have noticed that we now have a *major* problem with abstraction because although we can write: module M (Rec) where ... code in another module can still say rec.f because in Haskell, all instance decls in a module are always exported [1]. This problem may disappear in Haskell' [2]. http://hackage.haskell.org/trac/haskell-prime/ticket/19 Therefore I think the desugaring would need to take place in the compiler so the compiler could avoid exporting the compiler-generated instances when the fields are not present in the module export list. Regards, Brian. [1] http://haskell.org/onlinereport/modules.html#import-instances [2] http://hackage.haskell.org/trac/haskell-prime/ticket/19 -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

4 9

rand* why not of type State g a
by Marc Weber 20 Aug '06

20 Aug '06

the rand* function are examples for a typical state usage, arent' they? Is there any reasoon why they are not defined RandomGen g => State g a rather than RandomGen g => (a,a) -> g -> (a,g) ? Marc

4 3

automatic instance derivation
by Greg Fitzgerald 19 Aug '06

19 Aug '06

How do you automatically derive an instance for a data type defined in an imported module? -- automatic instance derivation directly after type declaration data Val1 = V1 Int deriving Show -- manual instance derivation can be in separate file data Val2 = V2 Int instance Show Val2 where show (V2 i) = show i -- Is something like this possible? data Val1 = V1 Int ... derive Show Val2 Thanks, Greg

2 2

Problem getting started with graphics library in GHC on Windows
by Tomi Maila 19 Aug '06

19 Aug '06

Hi, I'm a Haskell newbie. I've been studying Haskell by reading the book The Haskell School of Expression. Most of the example in the book use graphics library SOEGraphics. Windows GHC didn't find the library, but I assumed that the new name for the library is Graphics.SOE which seemed to properly loaded. The problem is that I fail to get the Graphics library to work properly. Instead GHC freezes if I use the graphics library in interactive mode and if I compile into a binary the binary freezes. The problem is not only with Graphics.SOE but also with more general Graphics.HGL. If I execute the Hello World program presented in Graphics.HGL documentation front page, GHC interactive mode freezes after opening the window but before drawing any text on the window. Compiled binary never even opens a window but freezes before that. Examples in HSOE (the book) behave the exactly the same way. I get not error messages what so ever. The example I refer to above is below. module Main where import Graphics.HGL main :: IO () main = runGraphics $ withWindow_ "Hello World Window" (300, 200) $ \ w -> do drawInWindow w $ text (100, 100) "Hello World" drawInWindow w $ ellipse (100, 80) (200, 180) getKey w The question is what I could be doing wrong or is Graphics library just incompatible with my environment. I'm using GHC 6.4.2 on Windows XP SP2. I've been developing using Eclipse 3.2 with EclipseFP plugin. However I've also tried to compile on command line. Could somebody help me over (no I'm not moving to Linux...) Cheers, Tomi -- Tomi Maila Research scientist Bio- ja ympäristötieteiden laitos Department of Biological Biotieteellinen tiedekunta and Environmental Sciences PL 65 (Viikinkaari 1) P.O. Box 65 (Viikinkaari 1) 00014 HELSINGIN YLIOPISTO 00014 UNIVERSITY OF HELSINKI puhelin (09) 191 59837 tel. +358-9-191 59837 matkapuh. 040 554 9024 mobile. +358-40-554 9024 http://www.helsinki.fi/~tmaila/

2 1

Re: [Haskell-cafe] HTTPS in Haskell
by Adam Peacock 19 Aug '06

19 Aug '06

On 8/18/06, Pasqualino 'Titto' Assini <tittoassini(a)gmail.com> wrote: > > Is there any implementation of HTTPS/SSL in Haskell? > > > > This would seem to be critical to develop commercial web applications. WASH has a run time function ( runWithOptions ) that has type: runWithOptions :: CGIOptions -> CGI () -> IO () with... type CGIOptions = [CGIOption] data CGIOption = .... AutoHttps -- autodetect Https by checking for port number 443 and env var HTTPS ... Taken from: http://www.informatik.uni-freiburg.de/~thiemann/WASH/doc/WASH-CGI-CGI.html Adam.

2 1