- Haskell-Cafe - Haskell.org

I am just starting out
by Andy Schmidt 27 May '03

27 May '03

Hi, my name is Andy Schmidt and I stumbled across this website as I started my quest for the best programming language. I am only in college and I am trying to learn as many languages as I can. I hope haskell will be the one I stick with. -Andy _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

11 16

Re:For All Educational Personnel
by epcinquire＠epcparts.com 26 May '03

26 May '03

For all Educational Personnel Re: 50% Off Electronic Parts Company is offering a limited supply of top of the line brand new Laptop and Desktop computers to all Educational personnel at 50% off MSRP. All Computers are brand-new packed in their original boxes and come with a full manufacturer's warranty plus ePC's 100% satisfaction guarantee. These computers are fully equipped with the latest 2003 technology to make these the best performing computers money can buy. ePC is offering these computers with the latest Intel technology at a remarkable price to those who call: 1.888.399.3744 by Wednesday May 28th, 2003 by 6 p.m. All desktops come with minimum:(Upgrades are available) * 1.3 Intel Processor * 128 MB SDRAM * 52x CD-ROM Drive * 20 GB UDMA Hard drive * Intel 3D Graphics * Sound Blaster 64v Sound * Floppy disk Drive * Keyboard, Speakers, Mouse * Motorola 56.6 V90 Fax Modem * Windows XP * Internet ready * Award winning tech support and customer service Retail..........$798.00 Your Cost............. $399.00 All laptops come with minimum:(Upgrades are available) * 1.0 GigaPro CPU, 512KB L2 cache * 128 MB SDRAM * CD-ROM * 10 GB UDMA Hard drive * Sound Card and Video Card * 14.1 XGA TFT Liquid Screen * Soft touch keyboard * 56.6 V90 Fax Modem * Windows XP * Internet ready * Bundled PC essentials software package * Award winning tech support and customer service Retail..........$1394.00 Your Cost............. $697.00 How to qualify 1. All computers will be available on a first-come first-served basis. 2. You must call 1.888.399.3744 by 6 P.M. Wednesday May 28th. and we will hold the computers you request on will call. 3. You are not obligated in any way 100% Satisfaction Guarantee. To take advantage of this offer please call 1.888.399.3744 To order online visit http://www.epcparts.com use promo code ENS4592

1 0

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 24 May '03

24 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