RE: GHC 4.01: Problems Using Existential Types
exist.hs:73: My brain just exploded. I can't handle pattern bindings for existentially-quantified constructors. It was my brain. (Though I discussed it with Mark, and I think Hugs may have a similar restriction.) data GenPic = forall pot. (PictureObject pot) = MkGenPic pot main :: IO () main = do putStr $ getPictureName obj where MkGenPic obj = item item = head obj_list The problem is the pattern binding for MkGenPic. Try main = case item of MkGenPic obj - do putStr (getPictureName item) where item = head obj_list I'll be interested to see if this happens a lot. Simon
RE: RTS flags, at compile time?
Thanks Simon, though I'm still a tad at sea...
Of course you can! Take a look at the User Guide, section 2.12:
http://www.dcs.gla.ac.uk/fp/software/ghc/4.01/users_guide/user
s_guide-2.html
#ss2.12
(under "RTS options for hackers...")
That says it all, I have a nasty feeling... For a kick off, I can
find neither RtsFlags.lh or rtsdefs.h files in the 4.01 distribution.
Some scouting around reveals a RtsFlags.h: does that fit both bills?
Looks like the docs are a tad out of date, sorry about that. Patch follows
(you want ghc/rts/RtsFlags.h and ghc/includes/Rts.h respectively).
*** runtime_control.vsgml 1998/01/30 17:02:54 1.1
--- runtime_control.vsgml 1998/12/14 14:48:13
***
*** 244,250
example, to set @-H8m -K1m@:
tscreenverb
! #include "rtsdefs.h"
void defaultsHook (void) {
RTSflags.GcFlags.stksSize = 102 / sizeof(W_);
RTSflags.GcFlags.heapSize = 802 / sizeof(W_);
--- 244,250
example, to set @-H8m -K1m@:
tscreenverb
! #include "Rts.h"
void defaultsHook (void) {
RTSflags.GcFlags.stksSize = 102 / sizeof(W_);
RTSflags.GcFlags.heapSize = 802 / sizeof(W_);
***
*** 253,259
Don't use powers of two for heap/stack sizes: these are more likely to
interact badly with direct-mapped caches. The full set of flags is
! defined in @ghc/includes/RtsFlags.lh@ the the GHC source tree.
You can also change the messages printed when the runtime system
``blows up,'' e.g., on stack overflow. The hooks for these are as
--- 253,259
Don't use powers of two for heap/stack sizes: these are more likely to
interact badly with direct-mapped caches. The full set of flags is
! defined in @ghc/rts/RtsFlags.h@ the the GHC source tree.
You can also change the messages printed when the runtime system
``blows up,'' e.g., on stack overflow. The hooks for these are as
--
Simon Marlow
Microsoft Research Ltd., Cambridge, U.K.
RE: GHC 4.01: Problems Using Existential Types
Simon Peyton-Jones writes: data GenPic = forall pot. (PictureObject pot) = MkGenPic pot main :: IO () main = do putStr $ getPictureName obj where MkGenPic obj = item item = head obj_list The problem is the pattern binding for MkGenPic. Try main = case item of MkGenPic obj - do putStr (getPictureName item) where item = head obj_list I'll be interested to see if this happens a lot. Simon Should be: MkGenPic obj - do putStr (getPictureName obj) I had tried this, it compiles OK but I get a segmentation fault when I run the resultant executable. The same thing run on Solaris gives a "Bus error, core dumped". So I guess this is hitting the same bug that the "DUMPCORE" define is tickling. Glad to know that I *should* be able to do this! Hugs disallows the declaration of GenPic: data GenPic = forall pot. (PictureObject pot) = MkGenPic pot regards k
Q: Eval class
Hi, I have a problem with the Eval class. Maybe its just that a compiler flag or import declaration is missing. I compiled with ghc-4.01/bin/ghc -c -fvia-C -syslib exts and got the error message: No instance for `Eval Int' OK, let's try instance Eval Int where seq x y = y -- because ints are already evaluated Then I got the error message: Class `Eval' does not have a method `seq' However, in the hugs standard prelude one can find the following definition: class Eval a where strict :: (a - b) - a - b seq:: a - b - b It's *not* a special problem of ghc-4.01. Has somebody an idea what to do or can give me a hint on a report for the Eval class? Thanks in advance --- Christoph Herrmann E-mail: [EMAIL PROTECTED] WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html
RE: RTS flags, at compile time?
Thanks Simon, though I'm still a tad at sea... Of course you can! Take a look at the User Guide, section 2.12: http://www.dcs.gla.ac.uk/fp/software/ghc/4.01/users_guide/users_guide-2.html #ss2.12 (under "RTS options for hackers...") That says it all, I have a nasty feeling... For a kick off, I can find neither RtsFlags.lh or rtsdefs.h files in the 4.01 distribution. Some scouting around reveals a RtsFlags.h: does that fit both bills?
RE: RTS flags, at compile time?
Looks like the docs are a tad out of date, sorry about that. Patch follows
(you want ghc/rts/RtsFlags.h and ghc/includes/Rts.h respectively).
Ah-hah! So I should just be able to write, in rts.c:
#include "Rts.h"
void defaultsHook (void) {
RTSflags.GcFlags.stksSize = 102 / sizeof(W_);
RTSflags.GcFlags.heapSize = 802 / sizeof(W_);
}
then: ghc rts.c? But, no:
swift.ucc.ie:~/check2: ghc rts.c
rts.c:3: `RTSflags' undeclared (first use this function)
rts.c:3: (Each undeclared identifier is reported only once
rts.c:3: for each function it appears in.)
What momumentally obvious blunder have I just committed? (I shouldn't
have to declare RTSflags, I thought, as it was already "stubbed"?)
Slan,
Alex.
LOPSTR'99: call-for-papers
___ Our apologies if you receive multiple copies. ___ CALL FOR PAPERS LOPSTR'99 9th International Workshop on Logic-based Program Synthesis and Transformation http://www.dsi.unive.it/~bossi/LOPSTR99.html Venezia, Italia, 22 - 24 September 1999 LOPSTR'99 is the ninth in a series of international workshops on logic-based program synthesis and transformation. In 1999, it will be held in parallel to the Symposium on Static Analysis (SAS'99). OBJECTIVES LOPSTR'99 will continue the tradition of being a lively and friendly forum for presenting recent and current research as well as discussing future trends in the synthesis and transformation of programs. The scope includes any computational-logic-based techniques, languages, and tools for the interactive or automated development of programs, with no preference for a specific language. Also, papers discussing programming-in-the-large issues, or presenting practical applications, or convincingly arguing for the practical applicability of given theoretical results are encouraged. PROCEEDINGS AND EDITING POLICY The _mode_of_operation_ is as follows. Based upon submitted extended abstracts, the programme committee will invite authors to present their research at the workshop. Pre-proceedings with the accepted extended abstracts will be available at the workshop as a technical report. Shortly after the workshop, the programme committee will invite the authors of the most promising abstracts and presentations to submit full papers. After another round of refereeing, the best full papers will be included in the post-workshop proceedings. At this point, extended abstracts of at most eight pages are thus solicited about, but not limited to, the following topics: specification analysis synthesis verification compositionreuse transformation schemas specialization industrial applications Every submission must clearly exhibit the relationship to the scope of the workshop, and must really be an extended abstract. It must thus be a miniature research paper with the key motivations and ideas, with outlines of the proofs of the key theorems, with references and comparisons to related work, but without full details of proofs or implemented systems, without the description of future work, without ramifications that are irrelevant to the key ideas. IMPORTANT DATES Submission of extended abstracts 1 May 1999 Notification to authors10 June 1999 Submission of full papers 31 October 1999 Notification to authors20 December 1999 PROGRAM COMMITTEE Annalisa Bossi, University of Venice, Italy (programme chair) Yves Deville, Universite' Catholique de Louvain, Belgium Mireille Ducasse, IRISA, Rennes, France Sandro Etalle, Universiteit Maastricht, The Netherlands Pierre Flener, Uppsala University, Sweden Patricia Hill, University of Leeds, UK Kung-Kiu Lau, University of Manchester, UK Baudouin Le Charlier, University of Namur, Belgium Michael Leuschel, Universityof Southampton, UK Michael Lowry, NASA Ames, USA Ali Mili, Institute for Software Research, USA, and University of Tunis II, Tunisia Lee Naish, Melbourne University, Australia Alberto Pettorossi, University of Roma Tor Vergata, Italy Dave Robertson, University of Edinburgh, UK SUBMISSIONS Electronic submissions are strongly encouraged. Address all correspondence (email preferred: uuencoded, compressed, postscript file) to: [EMAIL PROTECTED] Annalisa Bossi Dipartimento di Matematica Applicata e Informatica Universita' "Ca' Foscari" di Venezia Via Torino 155, 30173 Venezia Mestre, Italy Tel: (39) 41 2908421 Fax: (39) 41 2908419 email: [EMAIL PROTECTED]
Re: Why change the monomorphism rules?
I can't speak for Hugs 1.3c, but Hugs 1.4 and prior systems use the proposed monomorphism rule, not the Haskell 1.4 rule. John
