- Haskell - Haskell.org

Re: Bug in library report
by Jan-Willem Maessen 23 Jul '02

23 Jul '02

Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> guesses: > So I guess that means very few people are using Array and Ratio, > or at least we aren't show'ing and read'ing them, or the particular > enclosing precedence value that triggered this bug is very rare. I'd revise that to "very few people are using Ratio". Recent discussion suggests people are at least tinkering with arrays... [That said, when you need Rationals, nothing else really subsitutes.] As near as I can tell, the precedence of the bounds and indices in an array doesn't matter at all. Simon M's suggested change to Page 24 is therefore good for consistency, but doesn't appear to actually have any effect. Am I missing something? -Jan-Willem Maessen

1 0

RE: unsafePerformIO around FFI calls
by Simon Marlow 23 Jul '02

23 Jul '02

> If this is true, then is it equivalently safe to wrap the following > Haskell action in unsafePerformIO: > > myFunc i = > do arr <- newArray (0,255) 0 > mapM_ (\j -> writeArray arr j (i+j)) [0..255] > foo <- newIORef 0 > mapM_ (\j -> readArray arr j >>= modifyIORef foo (+j)) [0..255] > readIORef foo >>= return > > ? (don't call me on syntax errors -- i haven't checked this > at all, but you should get the idea) Yes, but for this particular case you would use the ST monad instead (with STArray and STRef). That way you get to avoid mentioning anything with 'unsafe' in its name, and the compiler does the safety proof for you. Cheers, Simon

1 0

Re: unsafePerformIO around FFI calls
by C.Reinke 23 Jul '02

23 Jul '02

> > I'm curious exactly what is "safe" and what is "unsafe" to wrap > > unsafePerformIO around when it comes to FFI calls. > > Here's a simple test: > > Could you imagine an alternative implementation of the same API in > pure Haskell? (Don't consider efficiency or effort required to write > the implementation, just whether it can be done.) > > If so, then it is ok to use unsafePerformIO and the ffi to implement > the API instead. That looks simple, but is not unproblematic: - just because I can *imagine* a pure implementation of *the API I want*, that doesn't mean that the foreign implementation in question *is* pure (*the exact API it implements* might have some extra features or assumptions, such as single-threaded use). - so the test implicitly depends on a very strict interpretation of "the same API", including all observable side-effects, and that isn't quite as simple as you make it. > If it fails that test, it is incredibly unlikely that it is ok and a > proof that it is ok is likely to be pretty complex - maybe worth a > PLDI paper or some such. - just because I can't implement something in pure Haskell doesn't mean that it has to be impure, or unsafe (it might fall into the gaps of static typing, for instance). So it seems to boil down to the usual argument about unsafePerformIO, no matter whether the IO action is foreign or not: by casting from "IO a" to "a", you *assert* that the IO part of your computation is not observable, and it is *your obligation to show* that this assertion is correct. You don't have to do a formal proof, but while attempting an informal one, you might find *side-conditions* (on the usage of your function) on which your assertion depends. The most valuable part of the proof attempts is to *identify and document*, *for your particular case*, those side-conditions. In other words, to become aware of "exactly what is `safe' and what is `unsafe' to wrap unsafePerformIO around"!-) Can your implementation defend itself against all attempts to discover that its "a" is really an "IO a"? If so, you're safe (or feel so, at least;-). If not, document the gaps in your defense (they might not arise in typical or intended use). If there are too many or too serious gaps, you're definitely "unsafe". Beware of optimizing compilers or other meaning-preserving program-transformation tools. The more you want your tools to make use of the semantics of your programs, the less you want to cheat on those semantics (is your foreign implementation still pure in a multi-threaded setting?). It's not called unsafePerformIO for nothing - using it means "trust me, I know what I'm doing". Do you? As for FFI-specifics, the problem seems to *find out* what the *precise API* of your foreign function is (including side-effects), and what *extra impurities* the FFI wrapping might impose. Given that the foreign function is imported as "IO a", the FFI wrapping would be permitted to use "IO", e.g., during marshalling. Does it? Cheers, Claus

2 1

RE: functional dependencies
by Simon Peyton-Jones 23 Jul '02

23 Jul '02

I'm just catching up with some old mail here. Iavor writes: | class C a b | a -> b | class C a b => D a | | vs. | | class C a b | a -> b | class C a b => D a b | | Hugs accepts both of those, while GHC insists on the second. | The first example is a little shorter and one might argue that if we | know "a" we also know "b", because of the functional depency, | so it is not really a parameter. | | On the other hand, i would expect writing "b" in the type | signatures of any of the methods to refer to the particular "b" | determined by the "a", rather than it becomeing universally | quantified, and perhaps this is more explicit in the second form. Dead right! Imagine there was a method in class D: class C a b => D a where op :: a -> b The type of 'op' is op :: D a => a -> b You can't really expect that the 'b' here is determined by 'a'! Still, I suppose that if the methods in class D mention only 'a', then it is strange to require D to be parameterised over 'b'. Thus, this seems more reasonable: class C a b => D a where op :: a -> a Even this seems odd, because we would get the deduction D a |- C a b (i.e. from a (D a) dictionary you can get a (C a b) dictionary) and that's only true for a particular 'b'. My brain is too small to be sure what I'm talking about here, but I'm strongly inclined to be conservative here, which GHC is. Simon

1 0

Job Vacancy at St Andrews: Deadline 12th August 2002
by Kevin Hammond 23 Jul '02

23 Jul '02

We are seeking a three year post-doctoral Research Fellow to work on a research project entitled: "Computational Algebra for Commodity Parallel Machines". The goal of this project is to develop and experiment with flexible and robust parallel implementations of key computational group theory algorithms, using Glasgow Parallel Haskell and to link these to GAP as a high-performance back-end. There is the possibility of closer integration including calls back from Haskell to GAP. Further Particuulars outlining the programme of research can be seen on the World Wide Web at: http://www.dcs.st-and.ac.uk/~kh/paraGAP.pdf The group web pages are http://www-fp.dcs.st-and.ac.uk and http://www-circa.dcs.st-and.ac.uk We are looking for a Research Fellow with the following qualities: A Programming experience: 1. They must be an experienced programmer 2. Preferably, they should have experience of functional languages, preferably Haskell 3. Ideally they would have experience of functional language implementation, preferably the Glasgow Haskell compiler and ideally the GUM parallel runtime B Mathematics 1. They must have taken at least some university level discrete mathematics course (this may however have been taken in e.g. a computer science department) 2. Preferably they should have studied group theory and/or computer algebra 3. Ideally they would have a good knowledge of computational group theory and experience with GAP The post is available from November 2002 (it may be possible to arrange an earlier or later start date to suit individual circumstances), will be paid on the postdoctoral scale subject to age and experience (currently UK pounds 19681 to UK pounds 26491), and is open to applicants of any nationality. The University of St Andrews is an Equal Opportunity employer. Full details of the post, including how to apply, have been posted on the University's web site (http://goliath.st-andrews.ac.uk:28080/HR/VacancyBoard/home) The job reference is ML 226/9380/02 and THE DEADLINE FOR APPLICATIONS IS 12TH AUGUST 2002. Note that faxed or posted applications will be accepted by the university, but email ones will not. We expect to conduct interviews for the post during the second part of August. If you have any questions, please do feel free to contact either of us informally about the post. Kevin Hammond (kh(a)dcs.st-and.ac.uk) Steve Linton (sal(a)dcs.st-and.ac.uk)

1 0

ANNOUNCE: Haddock version 0.4
by Simon Marlow 23 Jul '02

23 Jul '02

I'm pleased to announce version 0.4 of Haddock, a documentation generation tool for Haskell source code. It's available from http://www.haskell.org/haddock/ The changes relative to version 0.3 are listed here: http://www.haskell.org/haddock/CHANGES.txt Cheers, Simon

1 0

comparison of execution speed of array types
by Hal Daume III 23 Jul '02

23 Jul '02

Hi all, I was curious about how fast the different array implementations were so I decided to test it. I wrote five programs all of which take an array containing 50001 elements, reverse it a couple of times then sum (modulo) them finally printing the sum. The programs are as follows: NormalArray -- uses the standard Array package for everything NormalArrayReplace -- same as NormalArray but builds a new array every time it is reversed UnboxedArray -- uses UArray UnboxedArrayReplace -- obvious IOMutArray -- uses the IOArray from IOExts and everything is in the IO monad I've stuck the code for these at the bottom of this message, but here are the timing results: NormalArray 1.65u 0.20s 0:01.89 97.8% NormalArrayReplace 2.40u 0.08s 0:02.56 96.8% UnboxedArray 0.80u 0.04s 0:00.87 96.5% UnboxedArrayReplace 1.83u 0.07s 0:01.99 95.4% IOMutArray 0.60u 0.03s 0:01.09 57.7% clearly IOMutArray is the best, even outperforming the UnboxedArray. Unfortunately, writing code in the IOMutArray format is much uglier than writing it in the UnboxedArray or NormalArray formats, even though I know that I'm never going to refer to an old version of the array, so inplace updates are a-okay. So my question is: how can I get better performance without wrapping everything in the IO (or some other) monad? - Hal Source code: -- NormalArray: module Main where import Data.Array testArray :: Array Int Int testArray = array (0,50000) [(i, (19*i+23) `mod` 911) | i <- [0..50000]] reverseArray :: Array Int Int -> Array Int Int reverseArray arr = arr // [(50000-i, arr!i) | i <- [0..50000]] sumArrayMod :: Array Int Int -> Int sumArrayMod arr = sumArrayMod' low 0 where sumArrayMod' pos sum | pos > high = sum | otherwise = sumArrayMod' (pos+1) ((sum + arr!pos) `mod` 911) (low,high) = bounds arr main = print $ sumArrayMod $ reverseArray $ reverseArray $ reverseArray $ reverseArray $ reverseArray $ reverseArray testArray -- NormalArrayReplace: module Main where import Data.Array testArray :: Array Int Int testArray = array (0,50000) [(i, (19*i+23) `mod` 911) | i <- [0..50000]] reverseArray :: Array Int Int -> Array Int Int reverseArray arr = array (0,50000) [(50000-i, arr!i) | i <- [0..50000]] sumArrayMod :: Array Int Int -> Int sumArrayMod arr = sumArrayMod' low 0 where sumArrayMod' pos sum | pos > high = sum | otherwise = sumArrayMod' (pos+1) ((sum + arr!pos) `mod` 911) (low,high) = bounds arr main = print $ sumArrayMod $ reverseArray $ reverseArray $ reverseArray $ reverseArray $ reverseArray $ reverseArray testArray -- UnboxedArray: module Main where import Data.Array.IArray import Data.Array.Unboxed testArray :: UArray Int Int testArray = array (0,50000) [(i, (19*i+23) `mod` 911) | i <- [0..50000]] reverseArray :: UArray Int Int -> UArray Int Int reverseArray arr = arr // [(50000-i, arr!i) | i <- [0..50000]] sumArrayMod :: UArray Int Int -> Int sumArrayMod arr = sumArrayMod' low 0 where sumArrayMod' pos sum | pos > high = sum | otherwise = sumArrayMod' (pos+1) ((sum + arr!pos) `mod` 911) (low,high) = bounds arr main = print $ sumArrayMod $ reverseArray $ reverseArray $ reverseArray $ reverseArray $ reverseArray $ reverseArray testArray -- UnboxedArrayReplace module Main where import Data.Array.IArray import Data.Array.Unboxed testArray :: UArray Int Int testArray = array (0,50000) [(i, (19*i+23) `mod` 911) | i <- [0..50000]] reverseArray :: UArray Int Int -> UArray Int Int reverseArray arr = array (0,50000) [(50000-i, arr!i) | i <- [0..50000]] sumArrayMod :: UArray Int Int -> Int sumArrayMod arr = sumArrayMod' low 0 where sumArrayMod' pos sum | pos > high = sum | otherwise = sumArrayMod' (pos+1) ((sum + arr!pos) `mod` 911) (low,high) = bounds arr main = print $ sumArrayMod $ reverseArray $ reverseArray $ reverseArray $ reverseArray $ reverseArray $ reverseArray testArray -- IOMutArray: module Main where import IOExts import Monad testArray :: IO (IOArray Int Int) testArray = newIOArray (0,50000) 0 >>= \arr -> mapM_ (uncurry (writeIOArray arr)) [(i, (19*i+23) `mod` 911) | i <- [0..50000]] >> return arr reverseArray :: IOArray Int Int -> IO () reverseArray arr = mapM_ (\i -> readIOArray arr i >>= \oldi -> readIOArray arr (50000-i) >>= \oldj -> writeIOArray arr i oldj >> writeIOArray arr (50000-i) oldi) [0..25000] sumArrayMod :: IOArray Int Int -> IO Int sumArrayMod arr = foldM (\s p -> readIOArray arr p >>= return . (`mod` 911) . (s+)) 0 [0..50000] main = testArray >>= \a -> reverseArray a >> reverseArray a >> reverseArray a >> reverseArray a >> reverseArray a >> reverseArray a >> sumArrayMod a >>= print -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

KBCS-2002 Call for Papers - Deadline Extended to Aug. 31, 2002
by Sumant Martin D. 23 Jul '02

23 Jul '02

Dear Colleague, I am Sumant Martin D., a Staff Scientist at the National Center for Software Technology (NCST), Mumbai, India (http://www.ncst.ernet.in) We, at NCST, are organizing an international conference on Artificial Intelligence, called: Knowledge Based Computer Systems (KBCS-2002). (http://www.ncst.ernet.in/kbcs2002/ I am sending you the details about this conference announcement. If you've received this email, please note that the *DEADLINE* for paper submission *has been EXTENDED*. I seek your apologies if you have already seen this announcement. regards, Sumant Martin D. KBCS-2002 INTERNATIONAL CONFERENCE ON KNOWLEDGE BASED COMPUTER SYSTEMS Mumbai, India, December 18 - 21, 2002 http://www.ncst.ernet.in/kbcs2002 Call for Papers: Deadline Extended to August 31 +++++++++++++++++++++++++++++++++++++++++++++++ Note: ================================================================ The deadline for paper submission to KBCS2002 has been extended to August 31, 2002. International authors, please note that the travel advisory for India by the US Department of State and the UK Foreign and Commonwealth Office has been relaxed. http://timesofindia.indiatimes.com/articleshow.asp?artid=16779990 http://www.rediff.com/news/2002/jul/23war.htm KBCS is the premium International AI Conference held in India. Don't miss out on it! ================================================================ The KBCS series of conferences, held every two years, is intended to act as a forum for promoting interaction among researchers in the field of Artificial Intelligence in India and abroad. The schedule includes a three-day conference on KBCS from Dec 19-21, and one day of tutorials, on the 18th. Papers are invited on substantial, original and unpublished research on all aspects of Artificial Intelligence, including, but not limited to those given below. This year, ICON-2002, International Conference on Natural Language Processing, will be held concurrently with KBCS-2002. Authors may, therefore, choose to submit papers focusing on Natural Language Processing (NLP) to ICON-2002. KBCS-2002 will also consider NLP papers provided they have substantial AI content. The programme committee may shift some papers between these two conferences based on content and suitability. Topics for the Conference: -------------------------- Case Based Reasoning Cognitive Modelling Data Mining Expert Systems Foundations of AI Fuzzy Logic Genetic Algorithms Intelligent Agents Intelligent Tutoring Systems Knowledge Acquisition Knowledge Representation Knowledge Management Intelligent Information Retrieval * Machine Learning Machine Translation * Natural Language Processing * Neural Networks Planning and Scheduling Reasoning Robotics Search Techniques Soft Computing Speech Processing Theorem Proving Uncertainty Handling Vision * overlapping areas with ICON Format of Submission: --------------------- Papers should be in English, not exceeding 5000 words (including figures and references). Papers should include an abstract of about 100-200 words. Papers outside the specified length are subject to rejection without review. Since reviewing will be "blind", the authors' names and affiliations along with the main area of the paper should be given only on a separate cover sheet. Authors should also exercise care to see that there are no indirect clues to the identity of the author or the institution (e.g. self-citations reading 'in our earlier work cited below' ... etc) Submissions should be in electronic form and can be in any of the following formats: PDF, Latex or Microsoft Word (RTF format). Papers may be submitted by E-mail or via the web at the URL given. Those who are unable to make electronic submissions may send four hard copies of the paper. Papers selected for the conference will be published in the proceedings. Call for Tutorials: ------------------- Proposals are invited for conference tutorials. Tutorials can be of half-day or full-day duration. The proposal should be presented in the form of a 200-word abstract, one page topical outline of the content and bio-data of the speakers, including their qualifications relating to the tutorial content. Submission Deadlines: --------------------- Papers Due: August 31, 2002 Acceptance Notification: October 10, 2002 Camera Ready Copy Due: November 5, 2002 Tutorial Proposals Due: August 31, 2002 Acceptance Notification: September 15, 2002 Materials Due: November 25, 2002 Address: -------- KBCS-2002 Secretariat National Centre for Software Technology Gulmohar Cross Rd No. 9 Juhu, Mumbai 400 049, India Phone: +91-22-6201606 Fax: +91-22-6210139 E-mail: kbcs(a)ncst.ernet.in For ICON-2002: http://www.iiit.net/conferences/icon2002.html E-mail: icon2002(a)iiit.net Advisory Committee: ------------------- Nick Cercone, University of Waterloo, Canada J.R. Isaac,Professor Emeritus, IIT Mumbai Aravind K. Joshi, U of Pennsylvania, USA H.N. Mahabala, Indian Inst. of IT, Bangalore R. Narasimhan, CMC, Bangalore P.V.S. Rao, Tata Infotech Ltd., Mumbai Programme Committee: -------------------- K.S.R. Anjaneyulu, ESN Tech Ltd., Hyderabad Vivek Balaraman, TRDDC, Pune Pushpak Bhattacharya, IIT Mumbai PP Chakraborti, IIT Kharagpur B.B. Chaudhuri, ISI, Calcutta R. Chandrasekar, Microsoft, USA S. Kambhampati, Arizona State Univ, USA M. Narasimha Murty, IISc, Bangalore Bernd Neumann, Univ Hamburg, Germany Arun K Pujari, Univ of Hyderabad, Hyderabad S. Ramani, HP India, Bangalore P.V.S. Rao, TataInfotech, Mumbai (Chair) Durgesh D. Rao, NCST, Mumbai P. Saint-Dizier, U of Paul Sabatier, France K. Samudravijaya, TIFR, Mumbai R. Sangal, IIIT, Hyderabad M. Sasikumar, NCST, Mumbai (Co-chair) S. Sen Gupta, Tata Infotech, Mumbai R. Uthurusamy, GMR Labs, USA (Co-chair)

1 0

RE: comparison of execution speed of array types
by Simon Marlow 22 Jul '02

22 Jul '02

> I was curious about how fast the different array > implementations were so I > decided to test it. I wrote five programs all of which take an array > containing 50001 elements, reverse it a couple of times then sum > (modulo) them finally printing the sum. The programs are as follows: > > NormalArray -- uses the standard Array package for everything > NormalArrayReplace -- same as NormalArray but builds a new array > every time it is reversed > UnboxedArray -- uses UArray > UnboxedArrayReplace -- obvious > IOMutArray -- uses the IOArray from IOExts and everything is in the IO > monad Could you try IOUArray for completeness too? (An IOUArray is the unboxed version of IOArray, it can be found in Data.Array.IO). > I've stuck the code for these at the bottom of this message, > but here are the timing results: > > NormalArray 1.65u 0.20s 0:01.89 97.8% > NormalArrayReplace 2.40u 0.08s 0:02.56 96.8% > UnboxedArray 0.80u 0.04s 0:00.87 96.5% > UnboxedArrayReplace 1.83u 0.07s 0:01.99 95.4% > IOMutArray 0.60u 0.03s 0:01.09 57.7% GHC doesn't do any analysis to detect when a pure array can be updated in place, so I'm surprised that the Replace versions of the test performed much differently from the originals - I'd have expected them to be about the same, because in both cases a new array is being built for each reverse. I suspect the difference is due to more deforestation happening in the replace case; we know there are some issues with deforestation of the array operations at the moment. > clearly IOMutArray is the best, even outperforming the > UnboxedArray. Unfortunately, writing code in the IOMutArray format is > much uglier than writing it in the UnboxedArray or > NormalArray formats, > even though I know that I'm never going to refer to an old > version of the array, so inplace updates are a-okay. You could try testing DiffArray (Data.Array.Diff) which is optimised for in-place updates, and should show a bigger difference between the normal and 'replace' versions. It might be nearly as fast as IOArray (I don't think we've ever benchmarked it), and it doesn't need to be in the IO monad. Cheers, Simon

2 1

RE: another minor fault in the Haskell Report
by Simon Peyton-Jones 22 Jul '02

22 Jul '02

Thanks. Fixed. Incidentally, the cement is set just about solid. I've had no substantive bug reports since the June release, so I'm on the point of declaring the H98 Report finished. I'm just waiting for a few hours spare to do some cosmetics. (This message is a genuine bug, but I'm not resetting the clock!) Simon | -----Original Message----- | From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk] | Sent: 17 July 2002 17:39 | To: haskell(a)haskell.org | Subject: another minor fault in the Haskell Report | | | I have just discovered another minor fault in the revised | Haskell'98 Report. | | In the definition of the Standard Prelude, (page 115) | | instance Read Float where | readsPrec p = readFloat | instance Read Double where | readsPrec p = readFloat | | are incorrect because they do not deal with a leading minus | sign. The correct versions are: | | instance Read Float where | readsPrec p = readSigned readFloat | instance Read Double where | readsPrec p = readSigned readFloat | | Funnily enough, all the implementations seem to have this fix | already, it is just the Report that gets it wrong! | | Regards, | Malcolm | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0