Re: core dumps when making use of IORefs
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 be IORef (forall a.[a]).
So you should be able to put into it only values of type
forall a.[a], nothing more or less specific.
I.e. you should be able to store (and retrieve) any lists of
the form {bot:}[] or {bot:}bot, where {} means zero or more of
that, and bot means anything bottom valued (as bottom is the only
value in forall a.a, from a type theoretic point of view).
Regards, Hannah.
`forall' subtelties (was: Re: core dumps when making use of IORefs)
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
print (bang :: [Char])
Hmmm. The type of test should be IORef (forall a.[a]).
So you should be able to put into it only values of type
forall a.[a], nothing more or less specific.
GHC doesn't accept the type `IORef (forall a.[a])':
ghc-test.hs:6: Unexpected forall type: forall a. [a]
Compilation had errors
I also tried `IORef [forall a.a]', which gives:
ghc-test.hs:6: parse error on input `forall'
Compilation had errors
and `IORef [(forall a.a)]', which gives:
ghc-test.hs:6: Unexpected forall type: forall a. a
Compilation had errors
At least, the latter two cases should IMHO be treated equal, so this seems
to be a bug in the parser.
Finally, I tried `forall a.IORef [a]' (as only change), but this is just a
more verbose writing of `IORef [a]' according to Haskell Report#4.1.2 and
GHC-users-guide#5.6. Naturally, the program compiles and dumps core as
before.
Cheers,
Michael
--
The First Commandment for Technicians:
Beware the lightening that lurketh in the undischarged capacitor,
lest it cause thee to bounce upon thy buttocks in a most untechnician-like
manner. -- fortune cookie
Staying alive
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 makes callbacks to Haskell-land where a GC occurs. Now the subtle question: Is it *guaranteed* that ba is considered alive until bar returns or not? Either way, this should be clarified in the FFI documentation. Background: A lot of APIs (e.g. GTK+ and OpenGL :-) have functions expecting a pointer to some data. One possible way to use them from Haskell is * malloc area * fill area with data * call API function with pointer to area * explicitly free malloced area Using (Mutable)ByteArrays would simplify thing here, especially the last step would not be needed. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
RE: GHC 4.04 patchlevel 1 released
- 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 when the version number does NOT change, so the version feature checks are inaccurate -- which has bitten me more than once). So, I should look if I can backport the ghc 2.95 compatibility easily, or if I have to change my procedure somewhat, as OpenBSD-current has changed from 2.81 (which works fine with ghc on i386) to 2.95.1. 3.02 should work fine with gcc 2.95 on i386. The only affected released version of GHC is 4.04pl0. Sparc support will need backporting: take a look at the changes to ghc/driver/ghc-asm.lprl between 4.04pl0 and 4.04pl1. The issue on i386 was a fragment of inline assembler that had incorrect constraints, causing gcc 2.95 to mis-optimised around it. Cheers, Simon
RE: Patches for GHC 4.04pl1?
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 only load the diffs to newer versions. And: isn't there a risk to update the local sources to a `unstable' revision? Or do you use symbolic tags for official releases, such as `ghc4.04pl1'? I'll use cvs to get the latest ghc, but nevertheless I suggest to publish patch files for future releases of ghc. This shouldn't be too difficult: cvs co -r lastRel -d ghc.old ghc cvs co -D now ghc cd ghc diff -rNu ../ghc.old . ../ghc.diffs cvs tag -F lastRel cd .. cvs -q rel -d ghc.old cvs -q rel -d ghc Bye, Kili -- de: Signaturen erzeugen Krebs. en: Signatures cause cancer. Please send other translations.
Re: GHC 4.04 patchlevel 1 released
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 ghc with a *slightly* older ghc (when some functions change at a time when the version number does NOT change, so the version feature checks are inaccurate -- which has bitten me more than once). So, I should look if I can backport the ghc 2.95 compatibility easily, or if I have to change my procedure somewhat, as OpenBSD-current has changed from 2.81 (which works fine with ghc on i386) to 2.95.1. [...] Regards, Hannah.
Re: Bug Tracking Systems?
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 any of these, or thoughts in general? Yes. Please no bug trackers that are *only* accessible via the WWW. WWW via EMail is very cumbersome, and there are still UUCP and other offline users. I'm leaning towards Debian at the moment, since it seems about the right level of complexity for the number of bugs we expect to maintain on it (i.e. not many :-). Seems good. Gnats is uncomfortable to set up and keep running, as I've experienced with a small play installation thereof. Regards, Hannah.
Re: Licenses and Libraries
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 implementations?). Sure Corba, but you need an ORB and I am thinking of using ORBit - thus, GNOME. I prefer to say GNOME (in a non-marketing context), as GNOME implies more than Corba. For example, there is the name service in libGNORBA and the new document component model called Bonobo (where MS uses OLE2 and ActiveX). Frankly, I'd like it to use Corba from Haskell with ORBit alone rather to have to install much additional Gnome stuff I'm probably not using elsewhere anyway. [...] Regards, Hannah.
Haskell's efficiency
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 Use a functional language and buy a faster computer with the saved P money/time. Marcin Qrczak Kowalczyk [EMAIL PROTECTED] responded K I have to care how fast my programs run. I like writing in Haskell K very much, it's my favorite general-purpose language, but one of the K biggest weak points of Haskell for me is poor efficiency (at least K with ghc, I don't know how fast are other compilers). K [..] So far, no clear progrm example appeared in this list to demonstrate Haskell's in-efficiency in comparison to other languages. Do i mistake? Thus, the recent example with the Cryptarithm solver was a very in-correct comparison, due to the unknown permutation generating order. K "Only 10 times slower than C" may be unacceptable. Most usually, people write programs that are 1000 times slower or faster - depending on the algorithm details, not on the language or system. I would say, 10 times difference in the compiler efficiency costs nothing relatively to the cost of "occasional" algorithmic details. P Use a functional language and buy a faster computer with the saved P money/time. I would rather propose to skip the "money, computer" part, and instead to spend this won time in thinking over the algorithm. This would increase the performance much more. -- Sergey Mechveliani [EMAIL PROTECTED]
Re: Cryptarithm solver - Haskell vs. C++
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 meeting specific criteria, searching for ones that maximize certain formulae etc. ... Maybe it's simply not possible to compile Haskell more efficiently? It is possible to improve the efficiency of lazy functional languages on matrices considerably. The first thing to be done is to create an efficient representation. As far as I know, to main reason why Clean is faster with matrices than Haskell is due to the different representation. Also in a lazy language many optimisations can be done. We can take a look at the things done in implementations of C (sorry), SISAL, SAC, etc. The high level of abstraction in modern lazy functional languages posses both opportunities and challenges to the compiler builders. We cannot expect the compiler to cope with each situation as good as a cleaver low-level programmer who knows what he is doing, but it should be possible to reduce the price (in execution time) to use a language like Haskell for matrix manipulations. A similar argument holds for C and assembly. Pieter Koopman
Re: Cryptarithm solver - Haskell vs. C++
[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 other compilers). I wonder whether this is the issue of Haskell itself or the compilers, I wonder if I can expect things to go better in future. I don't know what the future holds but, at least with GHC, you already have a range of options, to try to go faster. * You can profile your code and write better "standard" Haskell; * You can drop down to non-standard Haskell, and express your code with (e.g.) unboxed values, bytePrimArray#s, -- i.e. direct access to the machinery that GHC's libraries use; * You can code selected hot spots in C/whatever, and call out from Haskell to do those; if you do enough of this, you end up with the non-Haskell program you would've had to write anyway :-) * You can give your code to the GHC people for benchmarking purposes; be sure to mention, "By the way, this code runs N times faster when compiled by HBC" -- it works wonders. I think it is Very Cool that users have it within their power to claw back arbitrary "performance loss", if they want/need to. Will
Re: Cryptarithm solver - Haskell vs. C++
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 I remember it, a main argument for Sisal was that the freedom of side effects would simplify the automatic parallelisation. So one important percieved incentive was to actually get better performance than from automatically parallelised Fortran. But, as far as I know, there was never an implementation that actually demonstrated that benefit. IIRC, some programs were a little faster on some Cray vector machines, but that was about it. Manuel
RE: Cryptarithm solver - Haskell vs. C++
-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 programs is maybe not enough of an incentive. But it DID offer an important new feature relative to the original Fortran programs it was trying to displace -- completely automatic parallelization for the Cray vector machines that were the main workhorses at Livermore and similar labs. Nikhil
Re: Cryptarithm solver - Haskell vs. C++
"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 that the freedom of side effects would simplify the automatic parallelisation. So one important percieved incentive was to actually get better performance than from automatically parallelised Fortran. Björn Lisper
Functional languages and efficient implementations (was: Cryptarithm solver - Haskell vs. C++)
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 (here: for Haskell) will ever be efficient enough to
compete with C, etc. for computation intensive computations. After the
standard (?-) arguments, we have reached a point where the questions
seem to be:
- how efficient can computation intensive algorithms be implemented
in Haskell (with/without extensions, now/ever)?
- if the best efficiency for Haskell isn't good enough for a particular
application, do we need to go back to coding it in C/Fortran?
- Sisal, SAC, .. have efficiency as a major design goal, and claim
to be functional. How does this help the Haskell programmer, and why
can't we have everything?
-}
Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote:
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 language?
Replace "necessary" with "useful", "attractive", "nice to have"..
Manuel did already mention SAC, which also does not (yet) have
higher-order functions. That doesn't mean that Sisal or SAC are not
functional languages.
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. The better a language supports the subset of
features that you need, the better the language is suited for your
current problem.
From the perspective of numerical programmers, you could also ask: Isn't
compilation of high-level array operations into efficient code a
necessary part of every useful (FP) language?
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 basic set of features is available, more and more
of the nice functional features can be added, provided they do not
compromise the efficiency of the base language.
This bottom-up approach to functional language design and implementation
was chosen for SAC exactly because of the difficulties of the standard,
top-down approach: If you start with the complete feature set of a
modern general-purpose functional language such as Haskell, it is very
hard to do the program analyses on which good optimizations are based.
Likewise, it is difficult to isolate the language subsets for which such
analyses would be possible.
The hope was that a bottom-up approach would deliver good performance
for a sub-language soon (see recent performance results for SAC), and
that the performance/expressiveness trade-offs for additional features
would be examined before these features are added to the language.
Languages such as Haskell and SAC show some of the variety of functional
language designs and implementations - currently, there is still a huge
gap: Haskell provides more of the general-purpose features, but lacks
implementations with good performance for numerical computations, while
SAC offers excellent performance on some numerical benchmarks, but lacks
many of the nice general-purpose features (it does offer nice
array-specific features, though). Other functional languages offer
compromises in between, whereas extensions to Haskell try to improve
performance without giving away expressiveness..
While we are waiting for this gap to close, it seems we have to choose
from the range of (functional) languages between the extremes to find the
best language for each problem.
Claus
PS. An interim workaround could be a way to call SAC from Haskell,
allowing computation- and array- intensive program parts to be
implemented in SAC, and the rest in Haskell.
Note that most SAC optimizations depend on the ability to do precise
static program analyses, and that many optimizations span blocks of
operations, so a SAC array library for Haskell would find it
difficult to achieve even some of the impressive performance of SAC
alone. Still, I am sure that the SAC and Haskell teams (and users)
would welcome anyone who would be willing to take up this particular
challenge!-)
Re: What is a functional language? (Was: Re: Functional languages and ... (was: Cryptarithm solver ...))
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. higher-order functions] Well then, it appears that I have a mistaken idea of what functional programming is. Can you give me, to cure my ignorance, a few examples of languages (preferably ones that are in use nowadays) that are *not* functional and the reasons why this is so. Is C functional, since it is possible to program with functions in it? Firstly let me check that we mean the same thing by _higher order functions, namely they are functions which return functions. This is different from the idea that functions are _pure_, namely that the value returned by a function depends _only_ on its arguments (and not on some state, as represented by either local `static' variables or global varables in C). To my understanding, most people would call a language functional if the natural way of using it leads to a very large percentage of the computation being done with pure functions, and it's not if it's natural to use a significant percentage of comptation which involves state, either locally or globally. (Note that repeated assignment is clearly stateful, so any language where this is a natural way of doing things is not functional) So there's no sharp dividing line :-S Haskell is functional, although it has facilities for dealing with state via monads. ML is also functional language, even though it has references which allow it to deal with state. Emacs-Lisp is not really a functional language because so much of it involves manipulating state; however it incorporates some of the ideas from functional programming as it existed in the late seventies. C is not functional because the most natural way of coding many algorithms involves using subroutines (misleadingly named functions!) with either internal state (even if this is only assignment within loops!) or global state. Neither are Pascal, Modula-x, Oberon, perl,... This is despite the fact that you could write C/... programs that made sure that the subroutines were all functions and that you only ever used single assignment because it's not natural to do it that way. (In some ways it's like asking `what characterises an alcoholic?': you need to note that some people who aren't occasionally drink to excess and that alcoholics can go without a drink for short periods.) ___cheers,_dave__ email: [EMAIL PROTECTED] "He'd stay up all night inventing an www.cs.bris.ac.uk/~tweed/pi.htm alarm clock to ensure he woke early work tel: (0117) 954-5253 the next morning"-- Terry Pratchett
Re: What is a functional language?
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, 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 have a mistaken idea of what functional programming is. Can you give me, to cure my ignorance, a few examples of languages (preferably ones that are in use nowadays) that are *not* functional and the reasons why this is so. Is C functional, since it is possible to program with functions in it? There have been attempts to define functional languages in various ways and with different goals, and with my naive definition of functional programming I tried (unsuccessfully) to avoid starting these discussions again. Most of the time, I find the following sufficient (opinions will differ;-): - A functional language is a language that supports functional programming. - A purely functional language is a language that only supports functional programming. - A pure (functional/logic/..) language is a language that supports (functional/logic/..) programming and is free of features that would be considered impure, i.e., destroy some desirable property. In the context of declarative programming languages, uncontrolled side-effects are an example of an impure feature as they destroy referential transparency. So, if you want, you can call C a functional language, but its support for functional programming isn't very good, so it is not a good functional language (let alone a pure or purely functional one). Support for functional programming in ML is much better, so ML is a much better functional language. ML is neither purely functional (it supports imperative programming) nor pure (it allows uncontrolled side-effects) according to these definitions. Haskell tries to be pure, but as it also aims to support imperative programming, it is no longer purely functional. From the perspective of numerical programmers, you could also ask: Isn't compilation of high-level array operations into efficient code a necessary part of every useful (FP) language? I would definitely agree with that question if you didn't refer to FP in it. You don't define FP as "useful", do you? No, parentheses were used to indicate optional attributes. Numerical programmers need efficient high-level array operations in any language. If functional languages are to be useful there, they have to follow suit. Claus
Re: Haskell's efficiency
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
http://www.brookes.ac.uk/~p0071749/papers/bridging.ps.gz
they describe an algorithm for text formatting.
| lines | chars | size(KB) | time(s) | memory(KB) |
--+---+---+--+-++
Haskell | 163 | 4640 | 410 |45.2 | 4505 |
Modula-2 | 551 | 10005 | 74 |18.6 |356 |
C++ | 389 | 5832 | 328 | 3.9 |368 |
It is not quite fair because in Modula-2 and C++ all data structures
were of fixed size, but...
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://kki.net.pl/qrczak/
\__/ GCS/M d- s+:-- a22 C++$ UL++$ P+++ L++$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP-+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
Re: Cryptarithm solver - Haskell vs. C++
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 language? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% "" (John Cage)
Re: What is a functional language? (Was: Re: Functional languages and ... (was: Cryptarithm solver ...))
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 % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% "" (John Cage)
new version of: Fast, Error Correcting Parser Combinators
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 http://www.cs.uu.nl/groups/ST/Software/Parse/ I also fixed a couple of small bugs in the scanner module and added some "Unsafe and Dirty Combinators" that allow you to interfere with the correction process. You should probably not use these if you do not understand the correction process underlying the combinators. Doaitse Swierstra __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University (Prof. Dr)P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __
Re: Haskell's efficiency
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 eliminating the order problem. Ralf
What is a functional language? (Was: Re: Functional languages and ... (was: Cryptarithm solver ...))
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 have a mistaken idea of what functional programming is. Can you give me, to cure my ignorance, a few examples of languages (preferably ones that are in use nowadays) that are *not* functional and the reasons why this is so. Is C functional, since it is possible to program with functions in it? From the perspective of numerical programmers, you could also ask: Isn't compilation of high-level array operations into efficient code a necessary part of every useful (FP) language? I would definitely agree with that question if you didn't refer to FP in it. You don't define FP as "useful", do you? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% "" (John Cage)
