Re: Haskell's efficiency

[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote, > S.D.Mechveliani <[EMAIL PROTECTED]> pisze: > > So far, no clear progrm example appeared in this list to demonstrate > > Haskell's in-efficiency in comparison to other languages. > > I have not done benchmarking myself yet, but in >

Re: What is a functional language?

On Wed 22 Sep, Claus Reinke wrote: > Such questions are bound to end up in language wars. I'll try a neutral > approach below to stop this sub-thread right here and now, but if anyone > really wants to follow this question any further, may I suggest to take > this general part of the discussion to

Re: Cryptarithm solver - Haskell vs. C++

Manuel M. T. Chakravarty wrote: > > Bart Demoen <[EMAIL PROTECTED]> wrote, > > Speed is not the only issue - feasability is an issue as well. > > I completely agree, but the original poster did not complain > about a slight discrepancy in speed, he was puzzled about an > unacceptable large gap o

Re: Functional languages and efficient implementations (was: Cryptarithm solver - Haskell vs. C++)

On 22-Sep-1999, Claus Reinke <[EMAIL PROTECTED]> wrote: > The idea behind languages such as Sisal or, more recently, SAC is to > start with a minimal subset of "functional" features and to focus on the > efficient implementation of such a "sub"-language. Once an efficient > implementation of the b

Read integer from prompt

hi In the older hugs, i do this to read in integer from standard input: readNum :: IO Integer readNum = do { line <- getLine ; readIO line } However, in hugs98, it failed and the error message is:

Re: Sisal (was: RE: Cryptarithm solver - Haskell vs. C++)

"R.S. Nikhil" <[EMAIL PROTECTED]> wrote, > > From: Manuel M. T. Chakravarty [mailto:[EMAIL PROTECTED]] > > "R.S. Nikhil" <[EMAIL PROTECTED]> wrote, > > > ... > > > But it DID offer an important new feature relative to > > > the original Fortran programs it was trying to > > > displace -- completel

Re: Sisal (was: RE: Cryptarithm solver - Haskell vs. C++)

> Unfortunately, these choices won them no respect in the FP community > (for which, my commentary, shame on the FP community), who chose to > look down their noses at Sisal for what were essentially trivial and > shallow reasons (Pascal syntax, focus on those "dirty" arrays instead > of those "co

Re: Haskell's efficiency

Thu, 23 Sep 1999 14:19:54 +0900, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze: > The fact that the given URL simply produces a "not found" error > message on my machine, I am sorry, I didn't know it was no longer there. I am putting it in http://kki.net.pl/qrczak/bridging.ps.gz > PS: I a

Re: Haskell's efficiency

On Thu, 23 Sep 1999, Manuel M. T. Chakravarty wrote: > [EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote, > > > S.D.Mechveliani <[EMAIL PROTECTED]> pisze: > > > So far, no clear progrm example appeared in this list to demonstrate > > > Haskell's in-efficiency in comparison to other languages.

Re: Sisal (was: RE: Cryptarithm solver - Haskell vs. C++)

Paul Hudak writes: | Being an old fart, I was around when most of this happened, and will | humbly share at least some of the "blame" for this. But in our defense, | this was at the time when there was no "standard" FL and we were trying | to establish Haskell as such a candidate -- and not selfi

Re: Sisal (was: RE: Cryptarithm solver - Haskell vs. C++)

"R.S. Nikhil" <[EMAIL PROTECTED]> wrote, > Sisal researchers [...] deliberatly chose to avoid higher-order functions, > polymorphism, laziness, etc. In a first release, yes, but I believe higher-order functions were included in Sisal 2.0, which was almost ready for shipping when the Sisal proj

PhD Studentship at St Andrews

[Please forward to anyone who might be interested.] A vacancy has arisen for an EPSRC (UK government-funded) PhD studentship in the Division of Computer Science at the University of St Andrews. Current research interests in the functional programming group include: o parallel language design a

benchmark for Haskell, C, Mercury, ...

To my >> Thus, the recent example with the Cryptarithm solver was a very >> in-correct comparison, due to the unknown permutation generating >> order. Ralf Muschall <[EMAIL PROTECTED]> writes > I did not study the problem in detail, but I think giving it > an unsolvable puzzle would force it

efficiency of functional programs

Many times in this list people said that Haskell is in-efficient in comparison to non-functional tools, like C and others. And often refer to the matrix operations, linear algebra tasks, saying how the arrays are useful and how they need to be mutable. Maybe we arrange some simple and clear bench