- Haskell-Cafe - Haskell.org

Haskell-cafe message-length restriction
by Graham Klyne 23 Nov '04

23 Nov '04

To the list Haskell-cafe admin... May I suggest that the maximum message length for postings to the haskell-cafe list without moderation be raised from its current 5K limit? It seems to me that a value of (say) 20K would reduce the moderator's workload without obviously allowing too many undesirables ... (though I allow the moderator surely knows more about what is thrown at the list that most of us don't see.) Just a thought. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Mutable and persistent values (was: Top Level TWI's again)
by Graham Klyne 23 Nov '04

23 Nov '04

[I'm moving my response to the Haskell-cafe mailing list, as it seems more appropriate for this kind of discussion.] Your question seems to touch on the old chestnut of how to reconcile pure functional programs with the inherently procedural aspects of I/O and state management. Most of the richness to which you refer is, to my mind, a fairly esoteric corner of Haskell with which I've had little cause to engage. I sense you may be coming from a perspective similar to mine of a couple of years ago, hence this response. Maybe what follows is already well known to you (some of it is basic stuff), so please accept my apologies if I'm retreading well-worn paths for you. The classical work (c. 1970's) on using functions to describe programs that update machine state models such programs as functions that take a state and return a new state, maybe returning some other values as well. This could get complicated to handle, and along the way functional structures based on monads were invoked to tidy up the housekeeping. (A paper by Simon Peyton-Jones and John Launchbury [1] about handling state in Haskell was useful for me.) Note the central role of higher order functions in dealing with this: a state-monad function represents a computation on some state, not the result of that state; the result of the computation is available only when the function is applied to some initial state. The do-notation is a syntactic sugar to make this easier to write, but (I think) it can sometimes obscure what is going on. Philip Wadler's paper "The Essence of Functional Programming" [3] nicely illustrates how monads can take care of various housekeeping chores. The IO monad can be viewed as a special case that allows a program to access and update state ("the real world") that exists outside the program. So, turning to your specific questions/concerns: >Also, ultimately, I want to be able to save my work and restart >the next day (say) picking up the tags where I left off. Your top-level program must be "in the IO monad" (or: is an expression that describes an IO monad value, which is a computation that interacts with the real world). Thus, it can access yesterdays work, and also your interactive inputs, and compute a new value that is today's work. The IO monad allows you to sequence the various interactions with persistent state and user dialogue, in a purely functional way. >I'm darned if I can see how to do this in a callback without a global >variables (and references from other callbacks, by the way). I would expect the callback function to accept an initial value of the "global" variable(s), and return its new value(s), leaving the calling site to ensure that the new value is used as required. (This interaction may be "hidden" in a monad (e.g. a state monad), and if the "callback" itself involves interaction with a user must use the IO monad.) > I want to use the old value of a tag to compute the new value, in a > callback, > > I want to access the tag from other callbacks, and > > I want to the value to a mutable list from within the callback. All of these are accommodated by adopting the accept-a-value-and-return-a-new-value perspective. The calling program that invokes the callbacks deals with ensuring that the callbacks have access to the appropriate results from other callbacks. It is my view that use a functional language effectively, it is necessary to think differently about its structure than one would for a conventional imperative program. Global values become parameters and return values; mutable values become input values and new (separate) return values. If you're used to writing imperative programs that do not use global state, but rather use parameters to pass values, the difference isn't always quite as great as might be imagined. For complex values, this sounds horribly inefficient, but because values are pure (not mutable), very high levels of sharing can (sometimes, with good design!) be extensively shared. Thus, a return value may well consist mostly of a copy of the input value, with differences, rather than actually being a complete new copy. (Chris Okasaki's book shows well how to design to obtain these benefits.) Also, because Haskell is lazy, complex structures passed between functions don't necessarily ever exist in their entirety. Sometimes, I think of a data structure as describing a computational traversal through some data, rathert than something that actually exists. (This leads to very elegant expression of things like Prolog search-and-backtrack algorithms.) So the main point of this posting is to say that I think that the "richness" of "implicit parameters, linear implicit parameters, unsafePerformIO, ..." to which you refer is a shoal of red herring, as far as your goals are concerned. I hope this helps. I've added below a couple of links to my web site to stuff that I accumulated while learning Haskell over the past couple of years. #g -- [1] Simon Peyton-Jones and John Launchbury, State in Haskell, linked from: http://research.microsoft.com/Users/simonpj/Papers/papers.html#monads, document at: http://research.microsoft.com/Users/simonpj/Papers/state-lasc.ps.gz, also at: http://www.cse.ogi.edu/~jl/Papers/stateThreads.ps. Introduces monads as a general technique for handling state, and then introduces a concept of "the world" as a state manipulated by IO. I found this to be one of the more illuminating introductions to Monads (which are central to Haskell I/O). [2] Chris Okasaki, "Purely Functional Data Structures", Cambridge University Press, 1998 [3] Philip Wadler, "The essence of functional programming", linked from http://homepages.inf.ed.ac.uk/wadler/topics/monads.html, paper at http://homepages.inf.ed.ac.uk/wadler/papers/essence/essence.ps . [4] http://www.ninebynine.org/Software/Learning-Haskell-Notes.html [5] http://ninebynine.org/Links.html#Programming-Haskell At 15:34 22/11/04 -0800, John Velman wrote: >On Mon, Nov 22, 2004 at 07:27:44PM +0100, Lennart Augustsson wrote: > > >[snip] > > I admit there are proper uses of global variables, but they are very > > rare. You have not convinced me you have one. > > > > -- Lennart > >It's with some trepidation I bring a problem as a total newbie, but I've >been obsessed with this and hung up on it ever since I decided a couple of >weeks ago to learn Haskell by using it. > >Some brief background: > >A while back I decided I wanted a simple 'concept mapping' program that >would work the way I work instead of the way someone else works. I >envisioned a GUI with a canvas and an entry box (TK/tcl). I type a >"concept name" into the entry box, and it shows up on the canvas (initially >in a slightly randomized position), in a box, with a unique sequenced >identifier. The identifier is also used as a canvas tag for the item. >Similar input for relations between concepts. I think that's enough >description for now. > >Initially, I started programming this with PerlTK, but that effort was >interrupted for a few weeks. When I got back to it, I decided to do it in >Python instead. But that effort also got interrupted for a few weeks. >Before I got back to it, I ran across some material on Haskell I've had in >my files for a few years, and decided that I'd use this as a vehicle to >actually learn Haskell. (This all sounds a bit unfocused, and it is: I'm >retired, sometimes describe myself as an ex mathematician or an ex-PhD >having spent years in the aerospace industry instead of academia. Anyway, >I have both the luxury and lack of focus of no deadlines, no pressure to >publish. I hope to use Haskell to further my main hobby of knowledge >representation.) > >In perl, my labels/tags were very easy: > >In the initialization code: > > my @taglist = (); > my $nextag = "a"; > >and in the callback for the entry box: > > push(@taglist,$nextag); > $nextag++; > >(With the starting tag of "a" this results in "a",...."z","aa","ab",...) > >Also, ultimately, I want to be able to save my work and restart >the next day (say) picking up the tags where I left off. > >I'm darned if I can see how to do this in a callback without a global >variables (and references from other callbacks, by the way). > >In looking for a method, I've discovered that Haskell is a lot richer than >I thought (or learned when I tinkered with it back in the late '90s ). >I've found out about (but don't know how to use properly) implicit >parameters, linear implicit parameters, unsafePerformIO, "safe and sound >implementation of polymorphic heap with references and updates (Oleg >Kiselyov, (http://www.haskell.org/pipermail/haskell/2003-June/011939.html) >implicit configurations, phantom types, ... > >I've also found warnings against many of these. I'm inclined to try the >unsafePerformIO route as being the simplest, and most commonly used, even >though perhaps the least haskell-ish. I like implicit configurations, but >couldn't begin to say I understand them yet, and it's a bit heavy for a >novice. > >In a nutshell: > > I want to use the old value of a tag to compute the new value, in a > callback, > > I want to access the tag from other callbacks, and > > I want to the value to a mutable list from within the callback. > >I'd certainly be interested in doing without global variables, and would >appreciate any advice. > >(By the way, I'm using Linux, and so far it looks like HTk is my choice for >the GUI interface.) > >Best, > >John Velman >_______________________________________________ >Haskell mailing list >Haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

foldlWhile
by Serge D. Mechveliani 22 Nov '04

22 Nov '04

Is such a function familia to the Haskell users? foldlWhile :: (a -> b -> a) -> (a -> Bool) -> a -> [b] -> a foldlWhile f p a bs = case (bs, p a) of ([], _ ) -> a (_, False) -> a (b:bs', _ ) -> foldlWhile f p (f a b) bs' foldl does not seem to cover this. Example. Sum the list while the sum is less than bound: boundSum :: Integer -> [Integer] -> Integer boundSum b = foldlWhile (+) (< b) 0 Example: boundSum 100 $ map (^2) [1 ..] Is this reasonable? More `generic' variant: foldlWhileJust :: (a -> b -> Maybe a) -> a -> [b] -> a foldlWhileJust f a bs = case bs of [] -> a b:bs' -> case f a b of Just a' -> foldlWhileJust f a' bs' _ -> a Please, copy the replies to mechvel(a)botik.ru ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Re: [Haskell-cafe] foldlWhile
by Serge D. Mechveliani 22 Nov '04

22 Nov '04

To my question of >> foldlWhile :: (a -> b -> a) -> (a -> Bool) -> a -> [b] -> a >> foldlWhile f p a bs = >> case >> (bs, p a) >> of >> ([], _ ) -> a >> (_, False) -> a >> (b:bs', _ ) -> foldlWhile f p (f a b) bs' >> >> foldl does not seem to cover this. Dylan Thurston wrote: On Nov 20, 2004 > An alternative is > > foldlWhile f p a bs = last $ takeWhile p $ scanl f a bs > Yes. Thank you. Inspecting Prelude, we find out that scanl expresses, mainly, the thing. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Predicates in HaXml
by Tom Spencer 21 Nov '04

21 Nov '04

Hi there, In XSLT there is an XPath function that will let you select a particular node in the current context, for example; <xsl:value-of select="team[1] "/> in Michael Kay's article http://www-106.ibm.com/developerworks/xml/library/x-xslt/?article=xr This selects the first team element in the current context. Is there a work around to get similar functionality from the HaXml library? Many Thanks Tom Spencer

2 2

Re: [Haskell-cafe] foldlWhile
by dpt＠bostoncoop.net 20 Nov '04

20 Nov '04

On Sat, Nov 20, 2004 at 03:48:23PM +0000, Jorge Adriano Aires wrote: > > On Sat, Nov 20, 2004 at 12:47:58PM +0300, Serge D. Mechveliani wrote: > > > foldlWhile :: (a -> b -> a) -> (a -> Bool) -> a -> [b] -> a > > > foldlWhile f p a bs = > > > case > > > (bs, p a) > > > of > > > ([], _ ) -> a > > > (_, False) -> a > > > (b:bs', _ ) -> foldlWhile f p (f a b) bs' > > > > Why not just > > foldlWhile f p a bs = takeWhile p $ foldl f a bs > > Quite different. The former stops a foldl when the accumulating parameter no > longer satisfies p, the later assumes the accumulating parameter of the foldl > is a list, and takes the portion of the list that does satisfy p. Yes, this was a mistake. > The following is closer to the original, but doesn't work when the whole list > is folded (i.e., p always satisfied): > foldlWhile f p a = head . dropWhile p . scanl f a Serge's version returns the last 'a' that satisfies 'p', while yours returns the first 'a' that does not satisfy 'p'. This should be an equivalent version: foldlWhile f p a = tail . takeWhile p . scanl f a But what about the version with Maybe? There ought to be a concise way to write that too. Peace, Dylan

2 1

No need for integer literals
by Henning Thielemann 19 Nov '04

19 Nov '04

In addition to Paul Hudak's "The Haskell School of Expression", Appendix A "Built-in types are not special" I want to note that there is also hardly a need for integer literals. :-] module Digits where infixl 9 # (#) :: a -> (a -> b) -> b x # f = f x int :: Num a => a int = 0 d0, d1, d2, d3, d4, d5, d6, d7, d8, d9 :: (Enum a, Num a) => a -> a d0 n = n+n+n+n+n+n+n+n+n+n d1 = succ . d0 d2 = succ . d1 d3 = succ . d2 d4 = succ . d3 d5 = succ . d4 d6 = succ . d5 d7 = succ . d6 d8 = succ . d7 d9 = succ . d8 test :: (Enum a, Num a) => a test = int#d1#d4#d2#d8#d5#d7 * int#d2#d1

1 0

Sample rate inference
by Henning Thielemann 19 Nov '04

19 Nov '04

I want to connect several functions for signal processing. The typical case is that in a network of signal processor there are parts that are already discretized such as sampled sounds, and there are processors with no particular sample rate such as amplifiers. But when it comes to computation each processor must choose a sample rate for processing. There are also processors for converting sample rates. They divide the network into components of equal sample rate. The computation sample rate should be propagated through the network as follows: If in a component of equal sample rate some processors have the same fixed sample rate, all uncertain processors must adapt that. If some processors have different fixed sample rates this is an error. If no processor has a fixed sample rate, the user must provide one manually. To me this looks very similar to type inference. Is there some mechanism in Haskell which supports this programming structure?

6 10

RE: [Haskell-cafe] Parsec question
by Bayley, Alistair 19 Nov '04

19 Nov '04

I've also used Parsec for separated lexer + parser and currently have something like this to invoke them: testParse inputString = do case (parse myLexer "" inputString) of Left err -> fail ("lexical error: " ++ err) Right tokens -> case (parse myParser "" tokens) of Left err -> fail ("parse error: " ++ err) Right result -> return result ... or was this the "manual startup" that you were referring to? The above seems clunky to me, so I'd also welcome suggestions for piping the lexer output into the parser. What do you mean by "makes position calculations very complex"? Are you talking about reporting the position of lexical or parse errors? (If so, Parsec supports this quite well.) Alistair. > -----Original Message----- > From: John Goerzen [mailto:jgoerzen@complete.org] > Sent: 19 November 2004 14:28 > To: haskell-cafe(a)haskell.org > Subject: [Haskell-cafe] Parsec question > > Hi, > > I'm porting a parser over from an OCamllex/Ocamlyacc version and I'm > using Parsec for both the tokenizer and the resulting token > stream parser. > > I have both of them working fine, but now my question is: how do I > combine them? I can't quite figure out how to say "take the > output from > this GenParser Char () Tok and use it as the input for this > GenParser Tok () ParserOutput". > > Well, I have figured out an ugly way involving manually > starting up both > parsers, but it makes position calculations very complex. I > suspect I'm > missing something. > > Ideas? ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

Parsec question
by Tomasz Zielonka 19 Nov '04

19 Nov '04

On Fri, 19 Nov 2004 14:28:07 +0000 (UTC), John Goerzen <jgoerzen(a)complete.org> wrote: > Hi, > > I'm porting a parser over from an OCamllex/Ocamlyacc version and I'm > using Parsec for both the tokenizer and the resulting token stream parser. > > I have both of them working fine, but now my question is: how do I > combine them? I can't quite figure out how to say "take the output from > this GenParser Char () Tok and use it as the input for this > GenParser Tok () ParserOutput". > > Well, I have figured out an ugly way involving manually starting up both > parsers, but it makes position calculations very complex. Did you try to pair tokens with their SourcePos'es? What I did in my program was this: tokenize :: CharParser st tok -> CharParser st [(SourcePos, tok)] tokenize tp = do l <- many t eof return l where t = do pos <- getPosition tok <- tp return (pos, tok) token :: (Show tok) => (tok -> Maybe a) -> GenParser (SourcePos, tok) st a token f = Parsec.token (show . snd) fst (f . snd) This has a space leak, but I didn't care, because my inputs are at most 10kb long. You can do a lazy version with getInput. BTW, it would be useful if Parsec allowed to throw a ParseError from one type of parser in another parser. It would help me in a situation, where I parse the whole file with one parser, but I retokenize some parts of it and parse them with another parser type. Right now I am using this workaround, but it doesn't work well: cs <- chars pos <- getPosition x <- case p pos cs of Left err -> do setPosition (errorPos err) fail (messageString (head (errorMessages err))) Right x -> return x How about making an instance for instance Control.Monad.Error.MonadError ParseError (GenParser tok st) PS. I guess I could do this myself. Best regards, Tomasz

1 0

Parsec question
by John Goerzen 19 Nov '04

19 Nov '04

Hi, I'm porting a parser over from an OCamllex/Ocamlyacc version and I'm using Parsec for both the tokenizer and the resulting token stream parser. I have both of them working fine, but now my question is: how do I combine them? I can't quite figure out how to say "take the output from this GenParser Char () Tok and use it as the input for this GenParser Tok () ParserOutput". Well, I have figured out an ugly way involving manually starting up both parsers, but it makes position calculations very complex. I suspect I'm missing something. Ideas?

1 0

IO and State (was Re: [Haskell] Re: Global Variables and IO initializers)
by Iavor S. Diatchki 17 Nov '04

17 Nov '04

Hello, Just wanted to point out that the suggested idea is not quite correct. (well that has to be quantiifed a bit, see bellow) Krasimir Angelov wrote: >--- Ben Rudiak-Gould ><Benjamin.Rudiak-Gould(a)cl.cam.ac.uk> wrote: > > >>This is solved by merging the IO and ST monads, >>something that ought to >>be done anyway: >> >> type IO = ST RealWorld >> type IORef a = Ref RealWorld a >> type STRef s a = Ref s a >> >> It is not (should not be?) the case that IO = ST RealWord, as IO is not a state monad as we understand it. In a state monad, the changes to the state are all in the program, i.e. one can always point to the part of the program that modified the state. On the other hand, the "state" of the RealWorld can change on its own, without anything in the program affecting it. I guess this is similar to "volatile" state in C. For example, one might expect the following rule in a state monad: do x <- readSTRef r y <- readSTRef r f x y = do x <- readSTRef r f x x But this is not true for the IO monad, as for example reading a file twice does not guarantee that you will get the same result, even if no part of the program ever wrote to the file. Now the above law already doesn't hold when all GHC extensions are used, as when concurrency is present we cannot assume that nobody modified the state concurrently. As a result all pointers in GHC probably behave as if they were "volatile", which is not very nice. I think that inherently there are two concepts here, and I see no point in mixing them (even though they are already a bit mixed up, because of stToIO). The one is the usual sequential state that we know and love (and I think we use that a lot of the time). In the sequential state the above optimization is one of the laws specifying the monad. The other concept is that of "volatile" or concurrent state, and then the law doesn't hold. The two monads have a very similar inetrafce (reading and wrinting pointers, and creating new pointers) but the laws that the operations satisfy are different. -Iavor

6 9

Pure Haskell Printf
by John Goerzen 17 Nov '04

17 Nov '04

(Sorry for the crosspost; I'm not sure which list this should go to.) I've just completed a pure-Haskell printf. Docs at [1], download at [2]. Here are some examples: vsprintf "Hello" > "Hello" vsprintf "Hello, %s\n" "John" > "Hello, John\n" vsprintf "%s, your age is %d\n" "John" (10::Integer) > "John, your age is 10\n" sprintfAL "%(name)s, your age is %(age)d\n" [("name", v "John"), ("age", v (10::Integer))] > "John, your age is 10\n" I have more examples available at the doc page[1]. I used Ian Lynagh's Printf.Printer module to do the actual formatting (I converted it away from TH first). I got the idea for simulating handling variable numbers of function arguments from the haskell-xml-rpc code. I would appreciate comments/critiques. -- John [1] http://gopher.quux.org:70/devel/missingh/html/MissingH.Printf.html [2] http://gopher.quux.org:70/devel/missingh

14 25

Re: [Haskell-cafe] Re: Pure Haskell Printf
by MR K P SCHUPKE 16 Nov '04

16 Nov '04

Of course you can do intertationalisation with show... There is a paper on using type classes to define implicit confugurations, perhasps someone can provide the reference? This can be used to nicely redefine show... Ill see if I cant dig out an example. Keean.

1 0

Re: [Haskell] Problems installing HTTP and Browser modules
by Bjorn Bringert 13 Nov '04

13 Nov '04

Ranasaria, Kamal Kishor wrote: > Dear Sir, > > I was trying to install the HTTP module and came across the following > error. Would really appreciate if could help me find the cause of the error. > [...] I am guessing that you are using the version from http://homepages.paradise.net.nz/warrickg/haskell/http/ There is an updated version of the package at http://www.bringert.net/~d00bring/haskell-xml-rpc/http.html The code is in a darcs repo at http://cvs.haskell.org/darcs/http/ Graham Klyne has a slightly different version which uses the new Network.URI module. His code can be found at http://www.ninebynine.org/Software/HaskellUtils/Network/ /Bjorn

1 0

RE: [Haskell-cafe] One-shot? (was: Global variables and stuff)
by Simon Marlow 13 Nov '04

13 Nov '04

On 09 November 2004 11:54, Graham Klyne wrote: > I've not been following the Global variables debate too closely, it > seeming to have something of a religious wars flavour, but I noticed > that an example being proposed was how to achieve a "one shot" > execution. Here's something I did when working on modifications to > the HaXML parser: > > [[ > -- Memoization of withSocketsDo to prevent multiple calls. > -- (cf. http://tangentsoft.net/wskfaq/articles/lame-list.html) > socketsInitialized :: Bool > socketsInitialized = unsafePerformIO ( withSocketsDo ( return True ) ) > ]] > > Does it work as I think it does? ARe there any problems I'm > overlooking? You should add {-# NOINLINE socketsInitialized #-} to be on the safe side, but in practice GHC won't inline it anyway. The pragma would be good documentation though. Cheers, Simon

9 29

Currying confusion
by John Goerzen 12 Nov '04

12 Nov '04

I'm trying to do something -- I think it's called uncurrying. I've boiled up a little test case to show what I mean: test1 :: Int -> String test1 = show test2 :: Int -> Int -> String test2 x y = (show x) ++ (show y) OK, that works OK. Now let's say I want to provide a function that generates the string to use in place of (show y) -- perhaps, test1. I like the partial application feature (and used it in test1). So, I thought I could use that to my advantage in test3 and test4: test3 :: Int -> Int -> String test3 x f = (show x) ++ f test4 :: Int -> (Int -> String) test4 x f = (show x) ++ f Of course, I could say test3 x f y = (show x) ++ (f y) but for various reasons that's not the most useful in my program. Thoughts?

2 3

Re: [Haskell] Re: About Random Integer without IO
by Georg Martius 12 Nov '04

12 Nov '04

Hi, Sorry, but I don't really get the point of the discussion so far. I think any computation should be done in pure functional style, that gets a random generator (seed) and passes it around. Your program starts in the IO monad anyway, so you have the choice of using newStdGen to get a new seed or initialise it by hand from a command line argument or whatever. I think automatic random initialisation is very important and handy in programs that run non-deterministic simulations. Cheers, Georg On Thu, 11 Nov 2004 22:43:28 +0000, Thomas Davie <tatd2(a)kent.ac.uk> wrote: > On 11 Nov 2004, at 22:02, karczma wrote: > >> Thomas Davie writes: >>> This method unfortunately depends on having a seed first though. >> >> Which "this method"? Please, quote the text you are referring to >> *before* >> your answer. >>> One must use a different value every time the program is started, >>> commonly time or the first few bytes from /dev/random. Any one of >>> these is going to require a monadic function to generate (i.e. it >>> must come from the environment in some way - it must change every >>> time you run the program) So while this eliminates the IO monad from >>> most of the program, it must still be initiated using it. >> >> I understand that you mean the seed-propagation method. >> You are *partly* right, that the same program executed several times >> will >> generate the same sequence, if initialized identically. But there is no >> need for monads, it suffices to pass a parameter, or to read a >> different >> initialization file each time. >> Of course, anybody, especially somebody contributing to this list has >> the right to be a nit-picker. But, if one is a *practical* user of >> random stuff, then he/she usually knows such details. Moreover, it is >> sometimes very useful to control absolutely the initialization, to be >> able to repeat the experiment, so, professionals in Monte Carlo, etc. >> rarely if ever, use time, or system-dependent (and hidden) random >> values. >> For me the initialization is a *context* problem, which I separate from >> the properties of the random generator. It is its quality, lack of >> correlations, etc. which is important. Do you know of many problems >> requiring an automated, truly random initialization? In this case one >> may well delegate this issue to the *launching* of the functional >> program, >> instead of struggling with it from within. >> This is my personal philosophy, everybody is entitled to his/hers. >> > While I agree that it is often useful to start your program with > different parameters each time to seed the random number generator, I > would argue that this is often inappropriate - supposing we are writing > a very simple program to roll a virtual dice. If the user finds one > input that rolls a six, they can then use this repeatedly. Reading an > initialisation file is back to the situation of using IO to generate > our seed. > > Thanks > > Tom Davie > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- ---- Georg Martius, Tel: (+49 34297) 89434 ---- ------- http://www.flexman.homeip.net ---------

1 0

Space efficiency problem
by Adrian Victor CRISCIU 12 Nov '04

12 Nov '04

Hi, This may be silly, but I tried to code a simmulated annealing method to solve the travelling salesman prblem, by adapting the algorithm described in "Numerical Recipes in C". The problem is that there are so many iterations, that the program gets killed (kill -9) by the system. I use the State monad to code the optimisation algorithm, and a simple configurations generator for generating the each path. After profiling with -hc, the heap profile shows that the top-level function of the algorithm uses about 40Mb of heap space. How can I improve this awful program? The optimisation algorithm is coded as simmann = untilM theEnd refine path0 untilM :: (Monad m) => (m a -> m Bool) -> (a -> m a) -> m a -> m a untilM p f m0 = do isOver <- p m0 if isOver then m0 else untilM p f (m0 >>= f) theEnd tests if the current temperature has reached the lower limit, and refine produces a new path via a random modification on the current one. What can I do to get this running? It seems to eat up all the available space. I coded this previously in C, with destructive update of the state and path, but in Haskell, with recursion, this seems to be hoplessly inefficient. I use ghc-6.2.1 on a Slackware box based on kernel 2.4.18 with glibc 2.2.5 Thanks for your time! Adrian.

4 4

Re: [Haskell] Re: About Random Integer without IO
by Graham Klyne 12 Nov '04

12 Nov '04

At 00:10 12/11/04 +0100, karczma wrote: >But it was MUCH more important to repeat the same >sequence, e.g., after making fast some nice fractal sketch, I relaunched >the program with bigger size/precision, but exploiting the same random >sequence. I repeat, such is my philosophy. I agree. I've used similar randomization techniques for software testing, having similar requirements for repeatability. (E.g., finding a seed that generates an error after several million iterations, with a specific iteration number, and then re-running the test to enable tracing at exactly the required iteration number.) #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Re: [Haskell] Re: About Random Integer without IO
by Clive Brettingham-Moore 12 Nov '04

12 Nov '04

This really really should have moved to haskell-cafe as previously suggested (sending to both with this in mind); apologies for being a little confising to haskell-cafe This isn't a language design issue, it is a FAQ, or at best a nebulous conceptual debate (speaking of which, has anyone got something more specific than http://www.haskell.org/hawiki/ThatAnnoyingIoType) This question comes up again and again with Haskell newbies - the answer is of course you can't - not maybe, not sometimes, not sort of, but no. What you can do is confine the IO-ness at the outermost layer of the program - by seeding a psudo-random list at program initialization, as both solutions suggested - giving the original question the benefit of the doubt, we'll assume this was what the questioner wanted. Suggesting parameters is not an escape - it is exactly the same as using /dev/random in that they are also IO, weaker IO but still IO (getArgs:: IO [String], though there are counter arguments); besides, reproducability was not a requirement mentioned or implied by the original question (though relevent, not actually haskell specific.. haskell-cafe, again). Chaotic is not the same as Random (Jerzy you obviously know this, but please be clear about it, don't add to the confusion). Chaotic algoritms are used as a 'random-extender'. Random only happens when you seed you algorithm with a non-deterministic value (ie random). karczma wrote: > noise). I generated random fractals, etc. It didn't cost me anything to > put different initializations by hand on every run when I wanted to have > different behaviour. But it was MUCH more important to repeat the same > sequence, e.g., after making fast some nice fractal sketch, I relaunched > the program with bigger size/precision, but exploiting the same random > sequence. I repeat, such is my philosophy. Yours is easier, since you are > just discussing, most probably you never used RN for a serious work. If > I am wrong, I apologize. > > Jerzy K. I have to say this.. SERIOUS WORK?! I don't know what Thomas does, but I'm working with security at the moment, and a "serious" random program with default constant seeding strikes me as serious and not in a good way. Overridable seeding sure, if the application demands it, but not broken by default. It's not random; it may be alright for screensavers, but it's not a good coding habit. Clive (Sorry, pet peeve)

1 0

Re: [Haskell-cafe] One-shot? (was: Global variables and stuff)
by Adrian Hey 11 Nov '04

11 Nov '04

On Thursday 11 Nov 2004 6:36 am, Judah Jacobson wrote: > AFAIKS, the definition of "once" that I gave uses unsafePerformIO in a > perfectly sound manner; namely, the creation of a top-level MVar. It > only becomes unsafe if certain "optimizations" are performed; but > then, that's also true for the SafeIO proposal (as I understand it). That's the trouble with unsafePerformIO. Haskell is supposed to be a purely functional language and the compiler will assume all functions are pure. As soon as you use unsafePerformIO to create something that isn't a function you're in grave danger, even if it "looks safe" at the local level, it still isn't a function and the damage can't be contained at the local level. It's only really OK if it still is a function despite the use of unsafePerformIO (which is possible, but often hard to be sure about). > Yeah, perhaps it hasn't been said so much before. :-) You noted > several days ago that oneShot (a variant of my "once") can be defined > using top-level mutable variables. I was just pointing out that the > converse is true: top-level mutable variables can be emulated using I'm not too sure about that. But I guess the devil's in the detail, so until that's been thrashed out I'll reserve judgement. > Again, I would assume that any translation of (x <- someAction) needs > to have a prohibition on CSE, inlining, etc on the RHS; there's > nothing special to once here. Yes, but the trouble is in Haskell if you have x = y that really means any occurance of x can be replaced by y (and vice-versa) without changing the meaning of the program (subject to scoping rules of course). You're right that your once solution and the (x <- someAction) both have the same problem. But the difference is the compiler doesn't know that with the once solution because you've told it that.. myRef = once (newIORef 'a') ..and it will believe you. > I disagree that this only works for newIORef. Consider (in ghci): Well no, of course newIORef isn't the *only* case where it works :-) But I thought the point you were making was that the once guaranteed that the resulting value was independent of when it got reduced (presumably for any action). This isn't generally true, any more than it would be true for the x <- someAction solution if some action can be *any* IO monadic operation. That's why the proposal to use a restricted monad was put forward I.E. an "IO monad" which was not capable of doing any real IO. In principle at least, with the SafeIO/CIO monads the resulting initial value could be determined at compile time, which is exactly what we want I think (same intial value for every program run). Regards -- Adrian Hey

2 1

RE: [Haskell-cafe] FiniteMap-like module for unordered keys?
by Simon Marlow 11 Nov '04

11 Nov '04

On 10 November 2004 10:54, Graham Klyne wrote: > At 23:25 09/11/04 +0100, Remi Turk wrote: >>> (I looked at Data.HashTable, but I couldn't figure why it needs to >>> be implemented in the IO monad, except to optimize the internal >>> implementation. Also, it's not clear to me how it behaves when a >>> key is inserted that already exists.) >> A hash-table becomes rather useless without mutable state AFAICS. >> Without it, one might almost just as well use a list of pairs... >> Actually, some kind of freezeHashTable may be useful, and >> a HashTable in the ST monad is definitely useful: I guess patches >> are welcome.. > > I can see why using (something like) a state monad might be useful, > but not why it needs to be an IO monad, unless there's some fairly > low-down optimization being performed. > > (I'm not asking for this, BTW, just commenting on the apparent lack. > For my application, I am using a list of pairs, as I expect these > tables to be relatively small.) There is no good reason that Data.HashTable needs to be in the IO monad, other than that's where I wanted to use it and having two versions (or using lots of stToIO) would have been a pain. The performance of ST & IO are the same. Long ago, when IO exceptions were implemented explicitly in the IO monad, IO used to be less efficient than ST. Cheers, Simon

1 0

FiniteMap-like module for unordered keys?
by Graham Klyne 11 Nov '04

11 Nov '04

Is there a module that provides functionality similar to that of Data.FiniteMap for keys that do not have a defined ordering relation? (I looked at Data.HashTable, but I couldn't figure why it needs to be implemented in the IO monad, except to optimize the internal implementation. Also, it's not clear to me how it behaves when a key is inserted that already exists.) #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

6 7

ANNOUNCE: Haskell Communities & Activities Report (7th ed., November 2004)
by Andres Loeh 10 Nov '04

10 Nov '04

Right in time, I am pleased to announce -- on behalf of the many contributers -- that the Haskell Communities and Activities Report (7th edition, November 2004) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in several formats: PDF, for screenreading as well as printing, HTML, for those of you who prefer not to deal with plugins or external viewers, and PostScript, for those of you who have nice quick printers that do not grok PDF. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as we did. If you haven't encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and well in time for the actual deadline ;) ) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ---------------------------------------- End of April 2005: target deadline for contributions to the May 2005 edition of the HC&A Report ---------------------------------------- Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to `register' with the editor for a simple e-mail reminder in the middle of April (you could point us to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Andres Loeh <hcar(a)haskell.org> <andres(a)cs.uu.nl> -- Haskell Communities and Activities Report (http://haskell.org/communities)

1 0

Space efficiency problem
by Adrian Victor CRISCIU 09 Nov '04

09 Nov '04

Hi, This may be silly, but I tried to code a simmulated annealing method to solve the travelling salesman prblem, by adapting the algorithm described in "Numerical Recipes in C". The problem is that there are so many iterations, that the program gets killed (kill -9) by the system. I use the State monad to code the optimisation algorithm, and a simple configurations generator for generating the each path. After profiling with -hc, the heap profile shows that the top-level function of the algorithm uses about 40Mb of heap space. How can I improve this awful program? The optimisation algorithm is coded as simmann = untilM theEnd refine path0 untilM :: (Monad m) => (m a -> m Bool) -> (a -> m a) -> m a -> m a untilM p f m0 = do isOver <- p m0 if isOver then m0 else untilM p f (m0 >>= f) theEnd tests if the current temperature has reached the lower limit, and refine produces a new path via a random modification on the current one. What can I do to get this running? It seems to eat up all the available space. I coded this previously in C, with destructive update of the state and path, but in Haskell, with recursion, this seems to be hoplessly inefficient. Thanks for your time! Adrian.

1 0

Re: [Haskell] Re: Global Variables and IO initializers
by Keean Schupke 09 Nov '04

09 Nov '04

I might really want to call the initialisation twice. If you use global variables, the library can only be initialised once... but what if I really want to use the library twice? With the state in a type passed between functions, you can have multiple different states active at once. Keean. Benjamin Franksen wrote: >Yes, whenever possible I would use this approach. Unfortunately, there are >libraries (or just modules) that need to do some IO action in order to >produce the (A)DT. In this case it _will_ make a difference how often you >call it. But then this is just how IO actions are by nature, isn't it? > >Ben > >

5 7

One-shot? (was: Global variables and stuff)
by Graham Klyne 09 Nov '04

09 Nov '04

I've not been following the Global variables debate too closely, it seeming to have something of a religious wars flavour, but I noticed that an example being proposed was how to achieve a "one shot" execution. Here's something I did when working on modifications to the HaXML parser: [[ -- Memoization of withSocketsDo to prevent multiple calls. -- (cf. http://tangentsoft.net/wskfaq/articles/lame-list.html) socketsInitialized :: Bool socketsInitialized = unsafePerformIO ( withSocketsDo ( return True ) ) ]] Does it work as I think it does? ARe there any problems I'm overlooking? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Currying and errors
by Graham Klyne 09 Nov '04

09 Nov '04

I just found myself writing a function that looked like this: > isSubsumedByWith :: TBox c -> c -> c -> Bool > isSubsumedByWith [] c d = isALSubsumedBy c d > isSubsumedByWith _ _ _ = error "TBox reasoning not supported for AL" and immediately noticed that I might also write this: > isSubsumedByWith :: TBox c -> c -> c -> Bool > isSubsumedByWith [] = isALSubsumedBy > isSubsumedByWith _ = error "TBox reasoning not supported for AL" which led me to thinking about the difference between these two functions (I reason there must be a difference, because the call of 'error' is required to fulfil (terminology?) values of different types). I think it is this: Suppose I evaluate an expression: let s = isSubsumedByWith [foo] in seq s e then I think the first case will return a legitimate function, albeit one that returns error when it is applied, and the second will cause an error to be returned immediately. Am I right? Is this all? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

4 3

Re: [Haskell] Re: Global Variables and IO initializers
by Keith Wansbrough 09 Nov '04

09 Nov '04

[posted to haskell-cafe per SLPJ's request] Hi Adrian, > I can assure you that for the intended applications of oneShot it > is vital that realInit is executed once at most, but the user must [..] > So please, no more handwaving arguments about this kind of thing > being unnecessary, bad programming style, or whatever.. > > Please show me a concrete alternative in real Haskell code, other I'm mystified as to why you are insisting others provide real examples when you are not. Can you give one concrete example of an "intended application of oneShot", so that we can either propose a concrete Haskell implementation of it, or agree that global variables really are necessary. Hoping to increase the light / heat ratio in this discussion... Cheers, --KW 8-)

7 15

Re: [Haskell] Re: Global Variables and IO initializers
by Benjamin Franksen 08 Nov '04

08 Nov '04

[moving to haskell-cafe] Sorry for the long post. On Sunday 07 November 2004 22:55, Adrian Hey wrote: > On Sunday 07 Nov 2004 1:45 pm, Benjamin Franksen wrote: > > It's a similar advantage as using the IO monad has over allowing > > arbitrary side-effects in functions: The IO monad gives you a clear > > separation between stuff that has (side-) effects (i.e. depends on the > > real word) and pure functions (which don't). Abandoning global variables > > gives you a clear separation of stuff that depends on initialized state > > and other stuff that does not depend on it. > > I don't agree. Hidden dependencies are a fact of life with stateful > programming in general and IO monad in particular. Making some > references explicit arguments (as you seem to be suggesting) does > not eliminate the problem, it merely complicates an api for no good > reason. You have point here: hidden dependencies are something that is inherently possible in the IO monad. You can for instance easily create global variables using the FFI without resorting to unsafePerformIO. I'll take back what I said above. But I maintain that it is a good idea to avoid hiding dependencies if possible. > Hiding internal state dependencies is a *good thing*. The trick is > organise the dependencies and provide a robust "idiot proof" api so > that users don't have to know about the internal organisation and any > dependencies. Oh, but the user *has* to know about them. The user must call the init routine before using otehr routines of the library, remember? Why are you against the type checker reminding her? I know a lot of those "idiot proof" libraries: "You need to call X then call Y but not if Z was called before..." One of the ideas behind using functions with arguments and a static type system is to encode dependencies so that the compiler can enforce them. And BTW what if your idiot proof initialization routine needs arguments to configure the library? Is the user still allowed to call it from several places in his code, now with possibly different arguments? And with what effect? > I don't believe this is a new (or controversial) idea. > Its the basic idea behind stateful modular or OO programming. > All the user sees is a set of actions which collectively deliver on > a promise (by unknown means). OO is the best argument *against* global variables. Pure OO languages have *no* hidden global state. In every real OO programm you have the dependency explicit, since you always need a "target" object on which to invoke methods. It doesn't matter that you write "object.f" instead of "f object" as you would in Haskell. I have never heard anyone using an OO language complain about that. The two best OO languages I know of are Eiffel and O'Haskell/Timber. Both do not have global variables. Eiffel has 'once' routines which seem similar to be what you are after. Timber doesn't even have top-level IO actions, instead everything you need from the environment is given as an argument to main. Mark that Timber is used for real-time control, an inherently stateful and IO intensive field. Your opinion that it automatically leads to a horrible API if you have to pass the initialized state around amounts to saying that in an OO language like Eiffel only libraries with horribly inconvenient APIs can be written. This is ridiculous. Even in C++ using global variables is nowadays generally regarded as bad design, especially for libraries. > > [...] You know that IO actions have (side-) effects, so you > > would take care that the actions get executed as many times as is > > apropriate. If the library docs indicate that it makes no sense to call > > it twice, why would you do so? > > Given such a statement about realInit you wouldn't (or to be more precise, > given a statement that calling it twice or more will really screw things > up). I would be really interested to know what kind of init action you are talking about, that so badly screws everything up if called twice. This is not rethoric, I mean it. > But the question is *how* is the user to ensure that it is only called > once. I see no other way than the darned awkward alternative I gave. We have an interesting patt situation here: You argue that you want a feature so that you can enforce that a routine is called *at most* once. I argue that if you do this by hiding state dependencies, you are loosing the ability to enforce that it is called *at least* once. You argue that it might be catastrophic if the library initialized more than once. I argue that it is usually catastrophic (with this I mean core dump or at least exception if it is programmed defensively) if you don't initialize it at all. > I > suppose the other alternative is the noddy realInit is only used once in an > action which is only used once, in an action .. from main (which is only > used once hopefully). Is this what you have in mind? It's the same patt as above: If you do it your way, you have the problem with ensuring that it gets called at least once before you call routines that depend on it. And that gets *really* hard as soon as you have concurrent threads. Maybe we should look for a solution that can enforce *both* invariants, "at least once" as well as "at most once"? Its only that I can't see such a solution and therefore my preferences would be to redesign 'realInit' in such a way that calling it twice is not fatal but just creates another 'instance' (can't be more specific without knowing what the library does). > The behaviour of (and consequent constraints on correct useage of) > realInit and putString are very different. Must I eloborate them? True, I can't see any constraints on correct usage of 'putString' that aren't enforced by the type checker. And that is exactly how it should be. Maybe the problem with your 'realInit' is that it needs such constraints? Again, giving an example might convince me that these constraints are inherent to the problem domain and can't be worked around. > > > It doesn't seem very attractive to users either > > > (considerably complicates their code and places the burden on them to > > > "get it right"). > > > > It may seem so at first, but I think it's a delusion. > > Trust me on this, for whatever reason, it's absolutely vital that realInit > is used 0 or 1 times only, 2 or more is a catastrophic error. I would very much like to trust you, but why can't you give us an example? Are you talking about misssion-critical stuff like controlling an airplane? But you don't initialize a library in full flight, do you? So why is it catastrophic and what exactly does that mean? I thought you mean core cump, but I am no longer sure... Maybe the reason is that it calls out to C libraries with a broken API? (I know of enough such libraries, and interfacing them in a clean manner is sometimes a pain in the ass.) > So I'll ask again. Please provide a simpler _and_ safer alternative > (some real Haskell code please). And I'll ask again for an example to convince me of the necessity. > > At the moment I cannot imagine a well designed library interface where > > user code would be considerably complicated if no global variables were > > used. But maybe you have a good example at hand to prove that this is > > merely due to lack of imagination on my side, and that I was extremely > > lucky with the HWS? ;-) > > Indeed, I believe this is the case. I'm guessing of course, but I imagine > all your IO is done via standard Haskell library calls (socket API > or whatever), in which case they will hide a lot of the stateful compexity > of their implementation already. I don't know about the latter. I do know that there are no constraints on usage in the form of "this must be called before that", besides the ones automatically enforced by the type system. An exception might be the posix libraries, but they are only a thin layer over a badly designed C API. I could be wrong, but I doubt that there is lots of hidden state in the Haskell part. I once wrote a Haskell binding to a C library for a special network protocol. I never even considered using unsafePerformIO except for C routines that were actually pure functions. What I *did* need to consider and work around was that the C API was in some places hiding global state, which was *very* bad. Another example: Have you ever been using ONC/RPC (Remote Procedure Call)? I saw implementations that came with a real-time multithreaded OS where the docs said, more or less: "All created objects such as client handle may only be used from the thread that created them." *That* is a horrible API, because it means you can not pass these objects around freely but have to make sure your routine isn't called from the "wrong" thread! And the reason for this restriction was (of course) that the library was hiding state inside thread-local variables. > If so it seems to me you're using the fact > that somebody has already solved the problem for you as an argument that > no solution is necessary. Maybe. We can talk in "if" sentences until we both die of old age. > (It would be interesting to see what the api's > of the libraries you're using would look like, if they had been designed > according to the principles you're advocating). Yes, that would be interesting. And it is not a matter of me holding up holy principles against an evil reality. I am talking about practical considerations, not ideals. I hope I've made that clear with the above examples. Cheers, Ben

8 16

RE: [Haskell-cafe] Re: Processing of large files
by Simon Marlow 08 Nov '04

08 Nov '04

John Goerzen writes: > Yes it does. If you don't set block buffering, GHC will call > read() separately for *every* single character. (I've > straced stuff!) This is a huge performance penalty for large > files. It's a lot more efficient if you set block buffering > in your input, even if you are using interact and lines or > words to process it. That shouldn't be the case. GHC's IO library checks whether a Handle refers to a TTY, and enables line buffering if it does. Otherwise, block buffering is the default. Could you isolate the test case and submit a bug report? Cheers, Simon

1 0

Re: [Haskell] Re: Global Variables and IO initializers
by Keean Schupke 08 Nov '04

08 Nov '04

>I don't understand the relevance of this. In the example I gave >we're not talking about an abstract data structure and the init >function is not stateless. > > Well, it works like this, to call any function in your library you must present a state-type. The only way to get a state-type would be to call the init function. Therefore the type system enforces that initialisation has occured before a function is called. The user would not need to call the initialiser again as you would pass the state-type between functions. The neatest way to do this would be to make functions in your interface instances of a state-monad-transformer that could be layered over the IO monad. >I can assure you that for the intended applications of oneShot it >is vital that realInit is executed once at most, but the user must >have the freedom to execute userInit as many times as they need >(I.E. without the burden of having to keep track of whether or not >they've used it before). > > I don't understand this - If you pass the state type you do not need to call init again. It would work like openFile, which seems easy enough for users to understand is called only once on a file to get the filehandle that is used with the IO functions. You can call the state-type returned from your library an opaque-handle, and treat it like a file handle. >So please, no more handwaving arguments about this kind of thing >being unnecessary, bad programming style, or whatever... > > I am only trying to understand the need for this. As it appears the cost of using the unsafePerformIO style is that certain optimisations need to be switched off, it seems it would be better to find an alternative. If you could give more details of the application someone may be able to suggest a resonable way of refactoring. Keean.

3 3

Hal Daume III's NewBinary now ghc6ized, cabalized, debianize, darcsized.
by Jeremy Shaw 08 Nov '04

08 Nov '04

Hello, I am quite interested in having better Binary support in Haskell -- especially support for reading and writing binary files and protocols that have fields smaller than 8-bits and non-byte alignment. As a first step, I have republished Hal Daume III's NewBinary package in hopes that it will inspire some forward movement on it. I have made the following 'improvements': ~ ghc6ized cd /tmp/NewBinary/ diff /tmp/Binary.hs /tmp/NewBinary/NewBinary/Binary.hs 81c81,82 < import GHC.Handle ( openFileEx, IOModeEx(..) ) --- > import GHC.Handle > import IOExts ( openFileEx, IOModeEx(..) ) (hrm, I probably don't need to import GHC.Handle anymore either...) ~ cabalized To build, you need the Cabal libraries installed. Then do something like this: ghc -package Setup.lhs -o setup ./setup configure ./setup build ./setup install ./setup register (? maybe not needed ?) ~ debianized You should be able to build and install it like any other debian package: dpkg-buildpackage && debi ~ darcsized darcs get http://www.n-heptane.com/nhlab/repos/NewBinary I hope I am not stepping on anyone's toes or duplicating efforts. Jeremy Shaw. ps. The original is available at: http://www.isi.edu/~hdaume/haskell/NewBinary/ -- This message contains information which may be confidential and privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender and delete the message. Thank you.

1 0

Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
by MR K P SCHUPKE 08 Nov '04

08 Nov '04

>I would be very careful of adding non-rationals to the Rational type. Why is there no Irrational class. This would make more sense for Floats and Doubles than the fraction based Rational class. We could also add an implementation of infinite precision irrationals using a pair of Integers for exponent and mantissa. Keean.

7 8

Dynamic Type Contruction
by Vitor Rodrigues 08 Nov '04

08 Nov '04

I'm trying to create a library to querying XML data using Strafunski. I'm also using DrIFT to generate the instances of Typeable and Term of my Datatypes to be used inside Strafunski. Supose i've this datatypes: data Shape = Circle Float (Float,Float) | Triangle (Float, Float) (Float, Float) (Float, Float) then DrIFT, among other things, creates the functions: isCircle (Circle _ _ ) = True isCircle _ = False isTriangle (Triangle _ _ _) = True isTriangle _ = False what i'd like to have "is" as a generic "isFoo" function, with the type: is :: String -> DataType -> Bool that when running will act like this: is "Circle" (Circle 3.4 (3.0,3.1)) = True is "Triangle" (Circle 3.4 (3.0,3.1)) = False is "Circle" 2 = False I was looking on TyCon constructor and mkTyCon function, but i didn't understood it well. Can anyone tell me how can i create this "is Foo" function? I was thinking about create a dynamic type with mkTyCon and then see if it matches with the DataType receiveid as function parameter. Regards, Vitor Rodrigues

2 1

RE: [Haskell-cafe] Making MVar and Chan Instances of Typeable
by Simon Peyton-Jones 08 Nov '04

08 Nov '04

| instance Typeable a => Typeable (MVar a) where | typeOf x = | mkAppTy (mkTyCon "Control.Concurrent.MVar.MVar") [typeOf (undefined::a)] As I think you now know, the above declaration is fine if you use -fglasgow-exts. Haskell 98 does not support lexically scoped type variables, but GHC -fglasgow-exts does. You can read about it in the GHC user manual. Type variables are bound by instance declarations, as above, but you can also bind them in patterns. So as others have said an alternative is | instance Typeable a => Typeable (MVar a) where | typeOf (x::MVar b) = | mkAppTy (mkTyCon "Control.Concurrent.MVar.MVar") [typeOf (undefined::b)] But that's not legal in Haskell 98 either, and since 'a' is already in scope with -fglasgow-exts, the extra binding for 'b' seems less nice. The best Haskell 98 solution is the one Remi gives: instance Typeable a => Typeable (MVar a) where typeOf v = mkAppTy (mkTyCon "Control.Concurrent.MVar.MVar") [typeOf (t v)] where t :: a b -> b t = undefined Simon

1 0

Lnear algebra library for game programming.
by Serguey Zefirov 08 Nov '04

08 Nov '04

Right now I explore the possibilities of building the prototype for game physics library in Haskell. This is a purely hobby approach to gain more knowledge on Haskell and library design in general. One of intermediate steps is to build linear algebra library for further utilisation. But, here I face some difficulties. In C++ I could define needed operators on per-type basis, and define universal operators for, say, Vec3 * Mat3x3, Vec3 * Mat3x4, etc. In Haskell I should define different operators, something like `v3mulm3x3`, `v3mulm3x4`. This is somewhat inconvenient, given that I expect to utilize Vec2,3,4 and Mat(3,4)x(3,4) parametrized by Double and Float. So the question is: what other people do in situation like this and is there any paper(s) on linear algebra library design? -- Yours truly, Serguey Zefirov, theszATmail.ru.

4 4

Re: [Haskell-cafe] (Re arrows and Haskell) ...
by Andy Elvey 07 Nov '04

07 Nov '04

On Saturday 06 November 2004 08:36 am, you wrote: < snip > > > It might be an immense project, but I also think it would be interesting. > I wonder if Haskell would be much faster after being restructured around > arrows. > If an arrow-based version of Haskell existed, I'd love to try it. > > I think it's entirely possible that it would have significant benefits in > speed, elegance, and structural simplicity. > -- > Shae Matijs Erisson - Programmer Hi Shae! Thanks for your comments, and i agree totally! It would indeed be very interesting, and I tend to agree too that speed might be helped if this were done. ( and yes - I'd love to try an arrow-based Haskell too! ). While I was mulling this over this morning, I was thinking how (or even "if" ) an EBNF grammar (Haskell's in this case) could be represented in terms or arrows. I stopped pretty quickly as it made my head hurt just thinking about it ... :-)) - Andy

3 3

(Re arrows and Haskell) ...
by Andy Elvey 06 Nov '04

06 Nov '04

Hi again - Apologies for another post from me so soon (and for replying to my own post). Regarding my post about arrows and Haskell (and the idea of trying to define Haskell's grammar in terms of arrows) - upon thinking about that, I'm pretty much of the opinion that it'd be an immense task ... I also think that although maybe some of the grammar might be possible to define using arrows, it wouldn't be possible to do all of it :-) . So, I'll politely "withdraw to a corner" for a little while, resolving to think a bit more before I post! ;-) - Andy

1 0

Defining Haskell using "arrows"
by Andy Elvey 06 Nov '04

06 Nov '04

Hi all - I'm a first-timer here, and am *very* much attracted by Haskell's elegance and power ... :-) I have only poked around briefly with Haskell so far (at the "hello world" level). One thing that I have come across, and which really got me thinking, was the page on the Haskell website about "arrows". They really seem to take elegance and the "generic-ness" of algorithms to a new level. I was thinking - arrows are a relatively recent concept. Haskell's grammar (as defined in the Haskell report) has now been around for quite some time. So - I thought "what if?" What if Haskell were to be defined (er, *re*-defined) in terms of arrows? In other words, what if it were possible to start totally "from scratch", re-defining Haskell's grammar using arrows? (and preferably, *only* arrows ... ). This would presumably involve somehow coding up the arrows first, and then (haivng got them), using them to create/define the rest of the language. My reason for suggesting this - simply to see if it were possible to do a very small (but still quite comprehensive) Haskell implementation. Small meaning maybe 2-3 MB or so ... As an interesting "benchmark" of this, the Rebol language (though proprietary - sigh!) - comes in at 0.5 Mb or so, including a GUI. So, "very small but very powerful" is possible (although undoubtedly pretty difficult ... ) As a Haskell newbie, I have to defer to everyone else on this list (in terms of my Haskell ability), but just thought I'd post this idea anyway. I was thinking " I wonder if anyone has thought of this? ....... " . Arrows seem to be a recent "add-on", as it were, so I thought -given their power and flexibility, why not turn things totally around, and put them at the *very core* of the language, using them to define the language itself. Anyway, I'm keen to hear people's thoughts on this! Very many thanks in advance ... :-) - Andy

1 0

mkEmptyWeakPtr?
by David Roundy 06 Nov '04

06 Nov '04

I was wondering whether there might be any sort of trick one could use to create an empty "Weak a", i.e. one that has already been GCed? It should be possible to create such a pointer without having an object of type a. mkEmptyWeakPtr :: IO (Weak a) I know I could get this effect by using instead a "Maybe (Weak a)", but that's ugly and adds an additional layer of redirection. The point is that the weak pointer is being used to cache a value, but I'd like to not fill the cache until I actually need to read it. i.e. I have a data type AntiMemo (IO a) (IORef (Weak a)) where the second term is a cache of the result of the first, which is really a pure function, but I'm using the IO monad to force reevaluation, so the result, which is large, can be discarded and recomputed. So I could change this to AntiMemo (IO a) (IORef (Maybe (Weak a))) but it just seems a shame when Weak already effectively has a "Nothing" value type. I suppose one could also make it a "Weak (Maybe a)", but in any case, I'd rather be able to just initialize the IORef to an empty weak pointer, so there wouldn't need to be any extra code when reading the value. -- David Roundy http://www.abridgegame.org

1 0

Making MVar and Chan Instances of Typeable
by Benjamin Franksen 06 Nov '04

06 Nov '04

Hello Experts, I need MVar and Chan to be instances of Typeable. Any hint on how this is most easily done would be greatly appreciated. I could change the libraries and add 'deriving Typeable' but I hesitate to do so. Cheers, Ben

4 6

Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
by MR K P SCHUPKE 05 Nov '04

05 Nov '04

>My guess is because irrationals can't be represented on a discrete computer Well, call it arbitrary precision floating point then. Having built in Integer support, it does seem odd only having Float/Double/Rational... Keean. ..

2 1

Literate Haskell and piecewise construction of classes/instances
by Graham Klyne 05 Nov '04

05 Nov '04

I'm experimenting with a Literate Haskell style to construct a tutorial about Description Logics [1][2]. I'm developing the material in small sections, and using examples in the document to test the code as I go along . I therefore find that I want to introduce the components of class and instance declarations in pieces, rather than having the entire declaration in a single place. Am I right in thinking this is not possible? For example, I find myself resorting to tricks like this: [[ So far, a single Description Logic (AL) has been considered. My next step is to generalize the function interface to a collection of type classes that can handle arbitrary description logics. The basic ideas of concepts, roles and interpretations are common to all description logics, so these are used as defined above. It is the concept descriptions, role descriptions and associated operations that need to be further abstracted: - class ConceptExpr c where - iConcept :: Ord a => TInterpretation a -> c -> Set a (The full and final definition of ConceptExpr is given later.) : ]] and later... [[ The class interface for concept expressions is therefore extended thus: > class ConceptExpr c where > iConcept :: Ord a => TInterpretation a -> c -> Set a > isSatisfiableWith :: TBox c -> c -> Bool > isSatisfiableWith t c = not (isSubsumedByWith t c emptyClass) > isSubsumedByWith :: TBox c -> c -> c -> Bool > isSubsumedByWith t c d = > not $ isSatisfiableWith t (intersectClass c (complementClass d)) > emptyClass :: c > complementClass :: c -> c > intersectClass :: c -> c -> c ]] What this suggests to me is that for Literate Haskell it is desirable to have multiple appearances of a class/instance declaration, constrained so that one version contains all of the definitions contained in any other appearance, and no two appearances contain differing definitions for any component (using a fairly strict syntactic comparison to determine difference here). Does this strike any chords with anyone? #g -- [1] http://dl.kr.org/ (Description Logics web page) [2] http://www.ninebynine.org/Software/HaskellDL/DLExploration.lhs (My tutorial, work-in-progress - implements "structural subsumption" for a simple Description Logic.) ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Re: [Haskell-cafe] Making MVar and Chan Instances of Typeable
by MR K P SCHUPKE 05 Nov '04

05 Nov '04

My mistake: instance Typeable a => Typeable (MVar a) where typeOf (x::MVar x) = mkAppTy (mkTyCon "Control.Concurrent.MVar.MVar") [typeOf (undefined::x)] Keean.

1 0

Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
by Benjamin Franksen 05 Nov '04

05 Nov '04

On Friday 05 November 2004 14:11, you wrote: > It's worse: Since according to IEEE +0 is not equal to -0, atan2 is not a > function! Sorry, I meant to write: Since according to IEEE +0 *is* to be regarded as equal to -0, atan2 is not a function. (Because it gives different values for argument combinations -0, +0.) Ben

2 1

Re: [Haskell-cafe] Making MVar and Chan Instances of Typeable
by MR K P SCHUPKE 05 Nov '04

05 Nov '04

nstance Typeable a => Typeable (MVar a) where typeOf (x::x) = mkAppTy (mkTyCon "Control.Concurrent.MVar.MVar") [typeOf (undefined::x)] Keean.

2 1

Re: Double -> CDouble, realToFrac doesn't work
by dpt＠lotus.bostoncoop.net 05 Nov '04

05 Nov '04

On Thu, Nov 04, 2004 at 08:32:52PM +0100, Sven Panne wrote: > It's an old thread, but nothing has really happened yet, so I'd like to > restate and expand the question: What should the behaviour of toRational, > fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report > is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on > something. > Can we agree on the special Rational values below? I would be very careful of adding non-rationals to the Rational type. For one thing, it breaks the traditional rule for equality a % b == c % d iff a*d == b*c You'd need to look at all the instances for Ratio a that are defined. For instance, the Ord instance would require at least lots of special cases. And when would you expect 'x/0' to give +Infinity and when -Infinity? For IEEE floats, there are distinct representations of +0 and -0, which lets you know when you want which one. But for the Rational type there is no such distinction. The behaviour that '1 % 0' gives the error 'Ratio.% : zero denominator' is clearly specified by the Library Report. In the meantime, there are utility functions for dealing with IEEE floats (isNaN, etc.) Peace, Dylan

1 0

Newbie Question on type constructors
by Brian Beckman 04 Nov '04

04 Nov '04

This is a tiny question on the "data" syntax. Consider the following (cribbed from Paul Hudak's "School of Expression" book, page 22): data Shape = Circle Float | Square Float I read this something along the lines of "'Shape' is a type constructor, for use in other type-defining expressions, and 'Circle' and 'Sqare' are its two data constructors, which should be used like functions of type 'Float -> Shape'". Indeed, typing "Circle" at the Hugs prompt reveals that Haskell has a "function" named "Circle" with type "Float -> Shape." However, I don't know of other circumstances where (1) I can declare functions with capitalized names (Hugs groans about syntax errors if I attempt the following: Circle2 :: Float -> Shape Circle2 = Circle And (2) where the argument-types of a function can be declared on the function's right-hand side. So, in some sense, am I right to think of "data" as a special syntax for special kinds of function declarations, namely data-constructor function declarations, and that this syntax is different in appearance, but not terribly different in meaning, from the ordinary syntax, typified by circle2 :: Float -> Shape circle2 = Circle (this is just the uncialized version of the one above, and is perfectly legal) Apologies if this is just too nitpicky and pedantic for words, but I try to notice everything.

8 13