- Haskell-Cafe - Haskell.org

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