problems compiling ghc 3.01 for linux
I ran into minor problems compiling GHC 3.01 on my up-to-date Debian Linux machine. I'm pretty sure that the problem is that I'm using Libc 6 (GNU libc 2). Basically, several BSD extensions (in particular, the types caddr_t and u_long, and the tm_zone and tm_gmtoff members of struct tm) are not available when _POSIX_SOURCE is defined; I also had to define _BSD_SOURCE to include them. (One problem is that configure tests for feature availability with no _*_SOURCE defines; defining _POSIX_SOURCE then disables features that configure detected as present.) Here's the patch I made: --- stgdefs.h~ Sun Oct 5 13:34:00 1997 +++ stgdefs.h Sun May 10 15:52:25 1998 @@ -53,10 +53,12 @@ #ifdef NON_POSIX_SOURCE #undef _POSIX_SOURCE #undef _POSIX_C_SOURCE +#define _BSD_SOURCE #else # ifndef aix_TARGET_OS /* already defined on aix */ #define _POSIX_SOURCE 1 +#define _BSD_SOURCE 1 # endif #ifndef irix_TARGET_OS #define _POSIX_C_SOURCE 199301L While this works for me, I wouldn't suggest that you apply it blindly; I don't know if it might break other places. Ideally, it would be conditioned on having GNU libc 2.0 (Linux libc 6); I don't know how to check for that here. Random information about my system: Linux gemini 2.0.29 #4 Thu Oct 23 00:34:55 PDT 1997 i686 unknown gcc version 2.7.2.3 Let me know if you have any questions, or want me to test patches. Carl Witty [EMAIL PROTECTED]
Re: problems compiling ghc 3.01 for linux
"Carl R. Witty" [EMAIL PROTECTED] writes: Here's the patch I made: --- stgdefs.h~ Sun Oct 5 13:34:00 1997 +++ stgdefs.h Sun May 10 15:52:25 1998 @@ -53,10 +53,12 @@ #ifdef NON_POSIX_SOURCE #undef _POSIX_SOURCE #undef _POSIX_C_SOURCE +#define _BSD_SOURCE #else # ifndef aix_TARGET_OS /* already defined on aix */ #define _POSIX_SOURCE 1 +#define _BSD_SOURCE 1 # endif #ifndef irix_TARGET_OS #define _POSIX_C_SOURCE 199301L Thanks Carl. Several people have run into this before (check the list archives), but we still don't have any recent Linux installations here to test out a proper fix on. My suggestion for the time being: add something like this to your build.mk: SRC_CC_OPTS += -optc-D_BSD_SOURCE This avoids patching the source. You may have to add the flag to SRC_HC_OPTS too. Cheers, Simon -- Simon Marlow [EMAIL PROTECTED] University of Glasgow http://www.dcs.gla.ac.uk/~simonm/ finger for PGP public key
Re: problems compiling ghc 3.01 for linux
Simon Marlow [EMAIL PROTECTED] writes: Thanks Carl. Several people have run into this before (check the list archives), but we still don't have any recent Linux installations here to test out a proper fix on. That's why I said: Let me know if you have any questions, or want me to test patches. (I am keeping up with ghc-current, using anonymous CVS, so if you just check in a proposed fix and let me know I can tell you if it compiles.) Carl Witty [EMAIL PROTECTED]
Re: problems compiling ghc 3.01 for linux
8Qxd$QC/sdeK{93/{KA]T@gir{b8(rd5/zL85UcsTGty!z9Nx%Z+0e193YVEXFcWdM.]+uyVYA6
WNNn]tdh-oQ]/#\R;Vts^}W]a%+%VqSEAu
X-URL: http://WWW.CS.Yale.EDU/homes/reid-alastair/
Date: Mon, 11 May 1998 11:03:09 -0300
From: Alastair Reid [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Precedence: bulk
Resent-Date: Mon, 11 May 1998 16:07:11 +0100
Resent-From: [EMAIL PROTECTED]
Resent-To: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
we still don't have any recent Linux installations here
to test out a proper fix on.
Surely someone at Glasgow CS dept can lend you the Redhat CD ROM
and boot disk?
If not, Computer World (I think that's the name) isn't too far away.
Or you could order direct from Redhat. Or save money by ordering
from Cheap Bytes (but better to pay extra to RH to support further
development).
Or you can upgrade by ftp - I'm sure there's a mirror near you.
Upgrading only takes about 15 minutes of work - and a couple of hours
of ignoring the machine while it copies files.
(Time estimate based on my experience of Redhat 5.0. I'm not sure
how good the other distributions are for upgrading.)
Alastair
Re: Pattern Match Success Changes Types
Yes, GHC does some CSE stuff, but not very much. I don't think it has a large performance impact, but (as luck would have it) but I plan to work on it a bit in the newt few months. My advice would be: write clear code, and let the compiler do the CSE. If it doesn't, complain to the compiler writers. You have good reason to believe that it should. The exception is the case you've been discussing. The type of Right is not Right :: b - Either _ b (I don't know what "_" is) but rather Right :: forall a,b. b - Either a b Since GHC keeps the types right through the compiler, it really can't do CSE on two terms of type Either Int Int Either Bool Int even if they are both applications of Right. Actually, GHC does finally discard type information right at the end, so we could do an extra bit of CSE there, but frankly I doubt it would buy very much. But I'm willing to stand corrected. Incidentally, I don't think it would be sensible to change the type system to allow the demo1 :: (a - b) - Either a c - Either b c demo1 f (Left a) = Left (f a) demo1 _ r@(Right c) = r What type does r have? Either a c. What type does the result of the fn have? Either b c. Different types. It would be hard (I believe) to specify crisply when it was legitimate for two terms with different types to be as'd together. Simon
C to Haskell
I am writing CGI scripts in Haskell and would prefer not to pay the process creation overhead of CGI. Apache allows you to compile apache modules directly into the httpd. You just need to make sure that the code exports functions the functions that apache requires. The Netscape Server API has a similar strucutre (but works as a DLL). Greencard allows Haskell to call C (or Corba). Is there a way to give C code access to Haskell functions? -Alex- ___ S. Alexander Jacobson i2x Media 1-212-697-0184 voice1-212-697-1427 fax
Re: Pattern Match Success Changes Types
While on this topic I would like to ask the question: Is CSE very useful for Haskell programs? I would guess 'sometimes'. In some cases of course is it, but in other cases you might increase the scope of an expression and thereby worsen the space behaviour. Have there been any attempts to identify/quantify this? Jon
Re: C to Haskell
"S. Alexander Jacobson" [EMAIL PROTECTED] writes: I am writing CGI scripts in Haskell and would prefer not to pay the process creation overhead of CGI. Apache allows you to compile apache modules directly into the httpd. You just need to make sure that the code exports functions the functions that apache requires. The Netscape Server API has a similar strucutre (but works as a DLL). Greencard allows Haskell to call C (or Corba). Is there a way to give C code access to Haskell functions? Hugs' "server interface" provides a very limited ability for C functions to call Haskell. Have a look at http://haskell.org/hugs/docs/server.html (postscript and dvi versions available in the same directory). The server interface requires a fair bit of programming to call each function (you have to lookup the function, then massage each argument, then call it then check the error code then ...) Needless to say, it'll all be better in the new Hugs-GHC system we're working on. -- Alastair Reid Yale Haskell Project Hacker [EMAIL PROTECTED] http://WWW.CS.Yale.EDU/homes/reid-alastair/
Re: quicksort and compiler optimization
On May 10 (18:58 -0300), Mariano Suarez Alvarez wrote with possible deletions: | [...] | The same idea works in general: if E is some expression, | | E (foldr f1 b1 xs) (foldr f2 b2 xs) | = let (a,b) = (foldr f1 b1 xs,foldr f2 b2 xs) | in E a b | = let (a,b) = (foldr f1 b1 xs,foldr f2 b2 xs) | in E a b | = let (a,b) = foldr (\x - (f1 x # f2 x)) (b1,b2) xs | in E a b | | This is useful, since usually list traversing functions can be writen | using foldr. I remember reading about this somewhere... I don't know if this is the reference you were trying to recall here, but Andrew Gill, John Launchbury, and Simon Peyton-Jones used this technique as a preprocessing step for subsequent deforestation in their "A Shortcut to Deforestation" (FPCA `93) paper. --Teggy -- | Torsten Grust mailto:[EMAIL PROTECTED] | |http://www.informatik.uni-konstanz.de/~grust/ | | Database Research Group, University of Konstanz (Lake Constance/Germany) |
Re: quicksort and compiler optimization
On 10 May 1998, Carl R. Witty wrote: qsort [] = [] qsort (x:xs) = let (a,b) = foldr (\y - (y ?: (x) # y ?: (=x))) ([],[]) xs in qsort a ++ [x] ++ qsort b f # g = \(x,y) - (f x,g y) x ?: p = if p x then (x:) else id qsort' [] = [] qsort' (x:xs) = qsort' [y | y-xs, yx] ++ [x] ++ qsort' [y | y-xs, y=x] the proof is easy. Yes, I think this is sound, but is it an optimization? The paper by Launchbury, Peyton Jones Gill (which is where I got it from) introduces it as such... This is very fallacious as an argumentation, I know... :) This discussion began as a way to keep xs (from the definition of qsort' above) from being live in this situation. The definition of qsort above does this--possibly (if xs were not shared elsewhere) freeing up some cons cells--but only at the cost of introducing some much larger data structures. Note that all the elements of xs are still live in both cases. I don't think that keeping xs from being alive be possible, at least in general, because if = might lead to bottom when doesn't, one has to keep all the elements in xs somewhere. qsort and qsort' are both (at least) linear in space; different constant factor. The much larger data structures needed in the qsort case recall the fact that the list has already been traversed: we are trading space for time... One might write qsort2 [] = [] qsort2 (x:xs) = qsort2 a ++ [x] ++ qsort2 b where (a,b) = partition (x) xs using partition from the List library. But this is cheating, as this depends on and = being one the negation of the other, which we are not assuming, as in the T example (I can't think of *one* meaningful example where and = are as in the Ord T instance) -- m --- Mariano Suarez Alvarez The introduction of Departamento de Matematica numbers as coordinates Universidad Nacional de Rosario [...] is an act of violence Pellegrini 250 A. Weyl 2000 Rosario - Argentina e-mail: [EMAIL PROTECTED] ---
POPL99 Call for Papers
--1EE659728831F92233ED083F Content-Type: text/plain; charset="us-ascii" I apologize if you receive multiple copies of this mass mailing. --1EE659728831F92233ED083F Content-Disposition: inline; filename="sigplan.ascii" Content-Type: text/plain; charset="us-ascii"; name="sigplan.ascii" Call for Papers The 26th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL99) San Antonio, Texas, January 20-22, 1999 The 26th symposium on Principles of Programming Languages (POPL99) will address fundamental principles and important innovations in the design, definition, analysis, and implementation of programming languages, programming systems, and programming interfaces. Both practical and theoretical papers are welcome. Papers on a diversity of topics are encouraged, particularly ones that point out new directions. POPL99 is not limited to topics discussed in previous symposia or to formal approaches. Authors concerned about the appropriateness of a topic may communicate with the program chair prior to submission. A technical summary of 5000 words or less (excluding bibliography and figures) is to be sent to the program chair. Papers will be judged on originality, significance, correctness, and clarity. The summary should clearly express the contribution of the paper, both in general and in technical terms. It is essential to identify what was accomplished, describe its significance, and explain how the paper compares with and advances previous work. Authors should make every effort to make the technical content understandable to a broad audience. Papers must describe work not previously published in refereed venues. Simultaneous submission to another publication outlet (conference or journal) is grounds for rejection. Submissions must be either electronic (encouraged) or postal (discouraged). Note that the procedure for electronic submission is different this year. For electronic submissions: o A mail message with the title and a 100-200 word ASCII abstract must be received by 6:00 AM Pacific Daylight Time, Friday, July 17, 1998. Send the message to [EMAIL PROTECTED] o Papers must be received by 6:00 AM Pacific Daylight Time, Friday, July 24, 1998. Send a single message to [EMAIL PROTECTED] (MIME attachments are allowed). The message should contain both the previously submitted title (in ASCII) and the summary, which must be Postscript that is interpretable by Ghostscript. The Postscript must use standard fonts, or include the necessary fonts, and must be prepared for USLetter (8.5"x11") or A4 page sizes. Authors who cannot meet these requirements should submit hardcopy by post instead. Postal submissions must be sent to the program chair by airmail and postmarked (not metered) on or before Friday, July 10, 1998; 15 copies (printed double-sided if possible) must be provided. All submissions must include a return postal address, a telephone number, and an email address (if available). These are firm constraints; submissions not meeting the criteria described above will not be considered. Notification of the acceptance or rejection of papers will be given by Wednesday, September 30. Further details may be found on the Web at http://http.cs.berkeley.edu/~aiken/popl99/CFP.html. General Chair: Andrew Appel ([EMAIL PROTECTED]) Program Chair: Alex Aiken([EMAIL PROTECTED]) Program Committee: Martin Abadi, Digital Equipment Corporation Alex Aiken, University of California, Berkeley Laurie Hendren, McGill University Urs Hoelzle, University of California, Santa Barbara Trevor Jim, University of Pennsylvania Mark Jones, University of Nottingham Simon Peyton Jones, University of Glasgow Hanne Riis Nielson, University of Aarhus Benjamin Pierce, Indiana University Todd Proebsting, Microsoft Research Didier Remy, INRIA Rocquencourt Jon Riecke, Bell Laboratories, Lucent Technologies Martin Rinard, MIT Scott Smolka, SUNY Stony Brook Mads Tofte, University of Copenhagen --1EE659728831F92233ED083F--
