May 2003 - Haskell-Cafe

re: re: 你好
by 高明 26 May '03

26 May '03

1 0

Italian-crafted Rolex - only $65 - $140!! Free SHIPPING ! !
by james＠hello.com 26 May '03

26 May '03

1 0

monomorphism restriction
by John Meacham 23 May '03

23 May '03

Just a random thought, What would be the effect of lifting the monomorphism restriction under the condition that assignments which would normally be subject to the restriction must be memoized on the class constraint parameter by the implementation? it seems that this would solve the problems which inspired the monomorphism restriction since the value can be shared among all instantiations when the type is the same. I am posting this to haskell-cafe because it might just be half-baked. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

1 0

Shooting yourself in the foot, a contribution
by Alain Cremieux 23 May '03

23 May '03

Hi, If I may contribute to the language definitions (http://burks.brighton.ac.uk/burks/language/index.htm) concerning *Haskell* : You shoot yourself in the foot. The gun fires half an hour later (lazy evaluation), blows your hand instead of your foot (polymorphism), and leaves you in a state of total amnesia (memory leaks). Alain

8 8

RE: Shooting yourself in the foot, a contribution
by Simon Marlow 23 May '03

23 May '03

> In Haskell, it's provably impossible to shoot yourself in the foot > without using unsafeShootSelfInFoot. Curiously, this doesn't > stop people > using unsafeShootSelfInFoot in released software. You can always use shootSelfInFootIO, but you need to be in the IO monad and use the MutableFoot type. The purely functional version, shootSelfInFoot, requires human cloning and won't be available for a couple of releases. Cheers, Simon

1 0

Question about Function Efficiency
by Matthew Donadio 22 May '03

22 May '03

Hi all, I want to create a function that creates a cascade of function applications: cascade [ f1, f2, f3 ] x == (f3 . f2 . f1) x It's a bit trivial, but it makes implementing flowgraphs (which are usually drawn left-to-right) a bit easier. I plan on profiling this, but which of the following do you think is the most efficient implementation: > cascade1 :: Num a => [[a] -> [a]] -> [a] -> [a] > cascade1 [] = \x -> x > cascade1 (f:fs) = cascade1 fs . f > cascade2 :: Num a => [[a] -> [a]] -> [a] -> [a] > cascade2 cs = foldr (.) (\x -> x) (reverse cs) > cascade3 :: Num a => [[a] -> [a]] -> [a] -> [a] > cascade3 cs = foldl (.) (\x -> x) (reverse cs) Thanks. -- Matthew Donadio <m.p.donadio(a)ieee.org>

2 1

RE: getpid() or something similar
by Simon Marlow 22 May '03

22 May '03

> Hal Daume writes: > > > In GHC in the Posix module, there's GetProcessID: > > Thanks for the pointer! > > Unfortunately, this is a GHC-only solution, which is really annoying > in my case because the software is completely compiler-independent, > and I don't want to restrict it to GHC because I need it to determine > a unique file name for a temporary file! > > Is there no other way? I cannot be the first person ever to need a > temporary file, can I? Surely there must be some portable way, too? Even using a ProcessID doesn't guarnatee uniqueness, it just gives you a good chance that your file won't conflict - you still have to cope with the situation that a file with that name already exists. The right way to do this is to try to open it for writing, and try a different name if the open fails. Using System.Random to get a starting point is probably just as good as using the ProcessID, and is more portable. Cheers, Simon

7 9

Re: IO monad and lazy evaluation
by Hal Daume III 22 May '03

22 May '03

Moved to haskell-cafe... > Thanks for your comments. (I had overlooked "readFile", which certainly > looks safer. I'm not yet fully used to the distribution of functions > between standard libraries and the Prelude. As for my 'hSafeGetContents', > I realized exactly your point about using 'id' too late, after I'd sent my > email. :-( ) I've done this many many times...too often do I find myself in the state of "open mouth, insert foot." People tend to be pretty forgiving though. > The broader debate I was trying to evoke was: how, as a programmer using a > combination of monads and non-strict functions, can I be confident that > there aren't hidden interactions waiting to bite? Well, I think it's more the combination of *strict* monads and non-strict functions that causes trouble. In fact, as pointed out before, lazy IO uses unsafeInterleaveIO to work. I think the rationale for lazy IO is clear. Without lazy IO, the following program, when run on a 2gb file, will allocate 2gb of memory: > main = interact (map toUpper) whereas, with lazy IO, it will run in constant (small) space. I think the point of lazy IO (and people who designed it can probably speak better to this) is to allow people to continue to write pure functions. That is, without lazy IO, the above would have to be written something like: > main = do > b <- hIsEOF stdin > when (not b) $ do > c <- hGetChar stdin > putChar (toUpper c) > main or something like that. obviously in *this case*, we would prefer to use the pure function map. However, in order to use map, we need to only read in characters as they are demanded, which means we need lazy IO. I think that what it really boils down to is you need to ask yourself: am I benefiting by using lazy IO. In the 'interact (map toUpper)' case, clearly you are, so you should probably continue to you it. However, in a case where you know you're going to read the whole file and store it in some data structure and need to simultaneously use data from the beginning and end of the file, then you're probably not benefiting from lazy IO. It is somewhat unfortunate that the IO library doesn't contain strict versions of all the operations, but they're easy enough to write with DeepSeq in your pocket. > Using the hOpen ... hClose vs readFile case as an example, is the > difficulty here to do with the interleaving of multiple statements that > modify some state with non-strict functions that return results based on > some particular instance of that state? Is this really a fundamental mismatch? Yes, this is precisely the problem. Using hGetContents implicitly uses unsafeInterleaveIO, which basically only performs IO as demanded. When you then say 'hClose h', none of the input has been demanded, so nothing gets read. Ever. Someone (one of the Simons, perhaps) could comment on this, but it seems that the primary problem with using readFile is the open handles issue, which boils down to the definition of hGetContents: > hGetContents :: Handle -> IO String > hGetContents handle = > withHandle "hGetContents" handle $ \handle_ -> > case haType handle_ of > ClosedHandle -> ioe_closedHandle > SemiClosedHandle -> ioe_closedHandle > AppendHandle -> ioe_notReadable > WriteHandle -> ioe_notReadable > _ -> do xs <- lazyRead handle > return (handle_{ haType=SemiClosedHandle}, xs ) If this were changed to actually close the handle, rather than leaving it in a semi closed state (call this new function hGetContentsAndClose or something) and then readFileAndClose were implemented based on this, would this solve the problem? > I read recently that other functional languages (ML?) with strict > evaluation semantics can be used to mimic lazy evaluation, but saw no clue > how that would work. I'm wondering if any insight might be gained by > looking at how such mechanisms might interact with functional > state-transformer mechanisms? The basic idea is to do something like: > data Lazy a = > Value a (Lazy a) > Deferred (() -> Lazy a) or something, and then you provide a function: > force (Value a l) = Value a l > force (Deferred f) = force (f ()) You can then force values as you need them; presumably in strict evaluation semantics, 'f ()' would be evaluated only at the point that it's forced. This isn't really relevant, though, I don't think, since it's sort of the opposite of what we want to be doing... - Hal

1 0

RE: getpid() or something similar
by Markus.Schnell＠infineon.com 22 May '03

22 May '03

You can't guarantee that another process didn't happen to write a file with just that name, pid or not. Markus > -----Original Message----- > From: Peter Simons [mailto:simons@cryp.to] > Sent: Thursday, May 22, 2003 12:06 PM > To: haskell-cafe(a)haskell.org > Subject: Re: getpid() or something similar > > > Simon Marlow writes: > > > Even using a ProcessID doesn't guarnatee uniqueness [...] > > Why not? If I use the file only temporarily (it is gone once the > process terminates), something like /tmp/foo.<pid> will be unique, for > all I can tell. > > > > The right way to do this is to try to open it for writing, and try > > a different name if the open fails. > > Unfortunately, this approach features a race condition because POSIX > has no notion of mandatory file locking. I'd really rather avoid this, > if I can. > > Is there no other way? And one that works across different compilers? > > Peter > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

getpid() or something similar
by Peter Simons 22 May '03

22 May '03

Please pardon me if it turns out I'm just blind, but is there any function I can use to get some "unique" information to use for temporary file names and the like? A function that will tell me my process ID, for instance? I looked through Hugs and GHC, yet couldn't find anything but Data.Unique, and that looks like big-time overkill for the purpose. Any pointers are appreciated! Peter

3 3