Re: core dumps when making use of IORefs

1999-09-22 Thread Hannah Schroeter
Hello! On Tue, Sep 14, 1999 at 12:43:11AM -0700, Simon Peyton-Jones wrote: {-# notInline test #-} test :: IORef [a] test = unsafePerformIO $ newIORef [] main = do writeIORef test [42] bang - readIORef test print (bang :: [Char]) [...] Hmmm. The type of test should

`forall' subtelties (was: Re: core dumps when making use of IORefs)

1999-09-22 Thread Michael Weber
On Wed, Sep 22, 1999 at 00:36:27 +0200, Hannah Schroeter wrote: On Tue, Sep 14, 1999 at 12:43:11AM -0700, Simon Peyton-Jones wrote: {-# notInline test #-} test :: IORef [a] test = unsafePerformIO $ newIORef [] main = do writeIORef test [42] bang - readIORef test

Staying alive

1999-09-22 Thread Sven Panne
In a recent discussion with Manuel Chakravarty the following question arose. Given the following code: foo = do ba - newMutableByteArray ... ... bar ba -- ba not used here anymore foreign import ... bar :: MutableByteArray ... - IO () Let's further assume that bar

RE: GHC 4.04 patchlevel 1 released

1999-09-22 Thread Simon Marlow
- gcc 2.95 compatibility What's that specifically? I ask, because I'm using OpenBSD, and am usually bootstrapping new versions with an old 3.02 installation, because of the occasional problems with compiling ghc with a *slightly* older ghc (when some functions change at a time

RE: Patches for GHC 4.04pl1?

1999-09-22 Thread Matthias Kilian
The best thing to do is use the anoncvs repository, and just 'cvs update' to get the latest patches. If you're running over a phone line then it might help to make ssh do some compression. Yes, but this requires at least one complete checkout. Of course, after this is done, cvs update will

Re: GHC 4.04 patchlevel 1 released

1999-09-22 Thread Hannah Schroeter
Hello! On Wed, Sep 15, 1999 at 05:48:30AM -0700, Simon Marlow wrote: [...] - gcc 2.95 compatibility What's that specifically? I ask, because I'm using OpenBSD, and am usually bootstrapping new versions with an old 3.02 installation, because of the occasional problems with compiling

Re: Bug Tracking Systems?

1999-09-22 Thread Hannah Schroeter
Hello! On Tue, Sep 14, 1999 at 03:55:39AM -0700, Simon Marlow wrote: [...] - BugZilla (the Mozilla bug tracker). Web/CGI based, uses an SQL database. Does just about everything under the sun, probably a bit heavyweight for us. Does anyone have any experience with

Re: Licenses and Libraries

1999-09-22 Thread Hannah Schroeter
Hello! On Fri, Aug 27, 1999 at 09:41:22PM +0900, Manuel M. T. Chakravarty wrote: [...] Better make it work with Corba, which is the basement of the IPC used for Gnome, but not only that. For a first touch, one could use the standard C mapping via the GHC FFI (is that implemented in other

Haskell's efficiency

1999-09-22 Thread S.D.Mechveliani
Juergen Pfitzenmaier [EMAIL PROTECTED] wrote P I dont't care very much how fast a program runs. I care about how P long it takes me to write it. If you take a programming task of P reasonable complexity you will finish *months* earlier using a P --good-- functional language instead of C++. P P

Re: Cryptarithm solver - Haskell vs. C++

1999-09-22 Thread Pieter Koopman
At 10:41 21/09/99 GMT, Marcin 'Qrczak' Kowalczyk wrote: ... I have to care how fast my programs run. ... I had to write and maintain a boring program calculating lots of numbers from matrices, trying various permutations of rows and columns, joining rows and columns, generating random matrices

Re: Cryptarithm solver - Haskell vs. C++

1999-09-22 Thread Will Partain
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) writes: I have to care how fast my programs run. I like writing in Haskell very much, it's my favorite general-purpose language, but one of the biggest weak points of Haskell for me is poor efficiency (at least with ghc, I don't know how fast are

Re: Cryptarithm solver - Haskell vs. C++

1999-09-22 Thread Manuel M. T. Chakravarty
Bjorn Lisper [EMAIL PROTECTED] wrote, "Manuel M. T. Chakravarty" [EMAIL PROTECTED]: * While Sisal is arguably nice than Fortran, it doesn't really provide a new killer feature - rewriting all this Fortran code, just for getting nice programs is maybe not enough of an incentive. As

RE: Cryptarithm solver - Haskell vs. C++

1999-09-22 Thread R.S. Nikhil
-Original Message- From: Manuel M. T. Chakravarty [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 22, 1999 4:35 AM ... * While Sisal is arguably nice than Fortran, it doesn't really provide a new killer feature - rewriting all this Fortran code, just for getting nice

Re: Cryptarithm solver - Haskell vs. C++

1999-09-22 Thread Bjorn Lisper
"Manuel M. T. Chakravarty" [EMAIL PROTECTED]: * While Sisal is arguably nice than Fortran, it doesn't really provide a new killer feature - rewriting all this Fortran code, just for getting nice programs is maybe not enough of an incentive. As I remember it, a main argument for Sisal was

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

1999-09-22 Thread Claus Reinke
Crossposted to the SAC mailing list because I'm curious to learn whether there is any chance to get the best of both worlds.. {- Summary for the readers of sac-list: this is from a thread on the Haskell mailing-list, discussing the old problem of whether functional language implementations

Re: What is a functional language? (Was: Re: Functional languages and ... (was: Cryptarithm solver ...))

1999-09-22 Thread D. Tweed
On Wed, 22 Sep 1999, Antti-Juhani Kaijanaho wrote: On Wed, Sep 22, 1999 at 02:53:03PM +0100, Claus Reinke wrote: Functional programming, i.e., programming with functions, is possible in languages that do not support all features that have become common in many functional languages. [eg.

Re: What is a functional language?

1999-09-22 Thread Claus Reinke
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 comp.lang.functional? On Wed, Sep 22,

Re: Haskell's efficiency

1999-09-22 Thread Marcin 'Qrczak' Kowalczyk
Wed, 22 Sep 1999 14:26:03 +0400 (MSD), 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: Cryptarithm solver - Haskell vs. C++

1999-09-22 Thread Antti-Juhani Kaijanaho
On Wed, Sep 22, 1999 at 09:44:34AM +0200, Bjorn Lisper wrote: Sisal was an attempt to define precisely such a functional language. ... no higher order functions Uhh... have I misunderstood what functional programming is? Isn't higher-order function support a necessary part of every FP

Re: What is a functional language? (Was: Re: Functional languages and ... (was: Cryptarithm solver ...))

1999-09-22 Thread Antti-Juhani Kaijanaho
On Wed, Sep 22, 1999 at 04:57:58PM +0100, D. Tweed wrote: Firstly let me check that we mean the same thing by _higher order functions, namely they are functions which return functions ... or take functions as parameters. Such as map, foldr, iterate, etc. -- %%% Antti-Juhani Kaijanaho %

new version of: Fast, Error Correcting Parser Combinators

1999-09-22 Thread Doaitse Swierstra
I have been polishing the colorparam,,/param"Fast, Error Correcting Parser Combinators"/color, and as a result they are now so much faster (for some applications more than three times) that you may consider downloading the newest version from

Re: Haskell's efficiency

1999-09-22 Thread Ralf Muschall
S.D.Mechveliani wrote: Thus, the recent example with the Cryptarithm solver was a very in-correct comparison, due to the unknown permutation generating order. I did not study the problem in detail, but I think giving it an unsolvable puzzle would force it to try *all* permutations, thus

What is a functional language? (Was: Re: Functional languages and ... (was: Cryptarithm solver ...))

1999-09-22 Thread Antti-Juhani Kaijanaho
On Wed, Sep 22, 1999 at 02:53:03PM +0100, Claus Reinke wrote: Functional programming, i.e., programming with functions, is possible in languages that do not support all features that have become common in many functional languages. [eg. higher-order functions] Well then, it appears that I