RE: Forthcoming 4.06
After a monstrous fight against the versionitis of jadetex and the DocBook tools, I've finally managed to build the installation guide and the user's guide. But there were tons of warnings like: jade:/var/lib/sgml/CATALOG.docbk31:24:0:W: DTDDECL catalog entries are not supported Should they simply be ignored? Yeah, you can probably ignore that, if that's the only kind of warning you get. The purpose of it is to read in a particular SGML declaration when it sees a certain DTD so, in particular, if jade gets passed the declaration explicitly like this: jade -c /var/lib/sgml/CATALOG.docbk31 /var/lib/sgml/docbook.dcl other stuff there is no problem. Or you can use OpenJade 1.3 (http://peano.mathematik.uni-freiburg.de/jade-cvs/), which I think supports DTDDECL. --FAC
RE: Forthcoming 4.06
Or you can use OpenJade 1.3 (http://peano.mathematik.uni-freiburg.de/jade-cvs/), which I think supports DTDDECL. Oops, I take it back. The OpenSP 1.4 prerelease supports DTDDECL, but not 1.3, and OpenJade 1.4 hasn't been released in any form yet (except CVS). --FAC
RE: Happy v1.6.
Since ghc-4.04 confuguration insists one has Happy v1.6, has this actually been released? I see no link to it from the usually suspect sites. If it's Imminent, can a make the modest suggestion that it have a standalone makefile in it? Having to slot it into a ghc source build tree has always struck me as both inconvemient, and overkill. It looks like the Happy page is out of date. The version in CVS is 1.6 or better. If you need Linux or Solaris binaries, you can try Michael Weber's page: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/ --FC
RE: Santa's error correction
Please, do *not* put error correction into ghc! I think error correction is one of the Classic Bad Ideas for a compiler. It's much better to focus on providing understandable error messages: when the user knows what the compiler thinks is wrong, it's usually not so hard to fix the error. One error message at a time is sensible, too. Once I've fixed the first error, I don't want to waste time studying further error messages on the dubious assumption that they are unconnected to the first one. Let the computer do the grind work! I would hate it if a program that I'm trying to prove theorems about behaves strangely, because, in the face of an error, the compiler took a wild guess about what was intended and produced a program that I never wrote. I'm not unsympathetic to this sentiment. It would not be so bad, though, if the compiler/parser could guarantee that reported errors are orthogonal, i.e, there is no dependency between them. I imagine that this is already a consideration for error reporting in GHC, though. --FC
RE: downloading Haskell
[This question more properly belongs on glasgow-haskell-users, so I cc'd there.] Rory Leigh wrote: Could you help me please; I'm looking to possibly be able to download a Haskell compiler in as simple a way as possible (preferably without zip files -- if possible -- or if so,together with instrucs on how to use zip files as I'm not very experienced in using it) --- preferably to be able to download to floppy disk initially and then to be able to transfer to my home computer. I did have a look at the Installation instrucs for the Glasgow Haskell compiler homepage but still seemed to be rather complicated. BE most grateful if you could possibly assist. It will be easier to answer your question if you can tell us what operating system you are using at home. Is it Windows? By the way, if you are an inexperienced Haskeller, you will almost certainly be better off just getting Hugs 98, which is a Haskell interpreter. It is much smaller, and easier to both use and install, especially on Windows. http://www.haskell.org/hugs/ To handle zip files, you will need to download and install WinZip. You can get an evaluation copy from http://www.winzip.com --FC
RE: Enjoy the silence
IIRC, this has already been discussed quickly some time ago, but anyway: To conform more with the rest of the *nix world and decrease the confusion of my students, I'd like GHC to be less verbose by default. IMHO the following messages should not be issued without any commandline flags: ghc: module version unchanged at 1 ghc: module version changed to 1; reason: no old .hi file ghc: ignoring heap-size-setting option (-H30M)...not the largest seen NOTE: Simplifier still going after 4 iterations; bailing out. Out of date: Foo.lvl12 Compilation IS required ... I second that motion. I was going to raise this issue myself. Simple rationale: If nothing goes wrong during compilation, there's no output at all (well, apart from the object files and the like :-). I propose the following: The current messages should be enabled by -v and the current -v messages should be enable by -vv (or something similar). No, because gcc gives the same kind of output with -v that GHC currently does with -v; I don't think that should change. Enable the above stuff with something like -fnoisy. P.S. And now for something completely different... What the heck is that green creature in the upper left-hand corner of the top panel of the GHC home page? It looks like a sock puppet. :) --FC
Xlib IDL for H/Direct?
Has anyone created an IDL file for Xlib? Alternatively, has anyone created one for H/Direct? I know that someone is working on GTK, but I'm interested in Xlib specifically. Also, I'm aware of Sigbjorn's Xlib interface in Haggis, but that one's reportedly still for GHC 0.29. :( BTW, it's not urgent---I don't have any experience with either Xlib or H/Direct yet; I just want to play around with them. Having unsuccessfully checked the net for a suitable IDL description, I'm taking a shot at writing one myself, and I have a couple questions. (If I ever get this into a usable form, I'll notify you all.) First, judging from the DCE grammar it looks like you can't specify attributes for constants. In a constant definition like const char *XNCursor = "cursor"; will H/Direct figure out the right interpretation for char *? Do I need to specify an attribute (ref, ptr, unique, ..) for every occurrence of a * type in a struct field, or is there a default? The user manual seems to imply that translation of char * types default to [string], but I didn't see any mention of this in my perusal of the DCE spec. The technical report on H/Direct mentions a "pointer default" in connection with the internal translation into core IDL; the DCE spec mentions that you can set a pointer default by setting it on an interface. What about at top level? Is the default just [ptr] for non-char * cases? There is a function which takes an argument that is a pointer to an allocated struct, and deallocates it. What is the correct annotation for this behavior? xlib.h has a macro: #define Bool int Is it safe to translate this as typedef boolean Bool; ? Apparently the "recommended" C-translation for boolean is char... Finally, any ideas on how to handle callbacks...? Any other special provisos or advice on dealing with Xlib? --FC
Request for arrow syntax
Would it be asking too much to have Ross Paterson's syntax (or something close) for John Hughes' arrows implemented in GHC 4.02? I'm dying to fool around with it. --FC
Re: 2 questions: CVS Win32
I wrote: First, a CVS question. I am a real CVS novice so bear with me. I finally managed to use CVS to get the current 4.02 GHC distribution (and to compile it! :). Now, I understand how one can create recursive diffs between versions, but if I understand correctly, not every change counts as a "release version change", i.e., for the whole tree, not just a file. Is it possible to create a diff between my local tree and the current state of the tree in the repository? (I copied the tree elsewhere, somewhere I can't use CVS, and so I want to make a diff so that I don't have to copy the whole thing every time there is a change.) Simon Marlow wrote: Sure. 'cvs diff' from the top of the tree gives you all the changes made to your local tree versus the copy you checked out. Is this what you wanted? (I don't understand the first part of your question). I tried "cvs diff" from the fptools/ghc, but it doesn't seem to work for me. I get a series of messages: cvs server: Diffing . cvs server: Diffing compiler cvs server: Diffing compiler/absCSyn ... but no diffs. Having done that, I wondered if maybe there had been no recent changes, but when I do "cvs update" I see a few changes: cvs server: Updating . cvs server: Updating compiler ... cvs server: Updating compiler/prelude P compiler/prelude/PrimOp.lhs ... What am I doing wrong? Sigbjorn Finne wrote: Assuming you know the date at which you checked out a copy, something like the following should do the trick: cvs diff -D 01/30/99 -r HEAD This requires you to have two copies of your CVS tree though, the off-line one and one you can use to invoke 'cvs diff's from. Hm, OK, but what happens if there were multiple updates to the tree at Glasgow on that date, and my copy of it was not the last one? (Say there were updates at 4pm and 7pm, and I checked out my tree at 5pm.) And I don't understand why there need to be two copies of the tree... I don't need to be able to make patches between arbitrary versions of the tree, just between my working copy (to which I've made no changes) and the current one at Glasgow. In fact, I don't see why I need a local copy of the tree at all. If I haven't changed the tree, then it should be equal to an old version of the one at Glasgow, so shouldn't I be able to generate a patch file just by supplying two version identifiers, and having the CVS server compute the differences locally at Glasgow? The thing I don't understand, I guess, is how to determine the version identifier for my tree. (Here's my situation: I have a GHC snapshot on my computer at home, but I typically access the Glasgow CVS server from work. I want to generate a patch file every few days so that I can fit the changes onto a floppy, carry it home and apply them manually to keep the tree up to date.) --FC
2 questions: CVS Win32
First, a CVS question. I am a real CVS novice so bear with me. I finally managed to use CVS to get the current 4.02 GHC distribution (and to compile it! :). Now, I understand how one can create recursive diffs between versions, but if I understand correctly, not every change counts as a "release version change", i.e., for the whole tree, not just a file. Is it possible to create a diff between my local tree and the current state of the tree in the repository? (I copied the tree elsewhere, somewhere I can't use CVS, and so I want to make a diff so that I don't have to copy the whole thing every time there is a change.) Second, I know that you need the Cygnus distribution to run GHC on Win32. My question is, do you also need it to run GHC-produced executables? --FC
RE: -O,(NO)INLINE
Simon Marlow wrote: You should either compile the whole lot with -O, or not at all. Really? What are the consequences if you don't? It doesn't lead to incorrectly linked code, does it? I can see that, even if you compiled module A with -O, and then tried to call some functions of A from module B, B being compiled without -O , then the lack of inlining, etc. would render some of the optimization useless. But suppose I have a collection of modules which form a library A, which I'm using from some larger application B, and A is optimized with -O since it's stable, but B is in development so I'm not using -O. Then the calls to the library interface functions won't be optimized, but I would still get good performance from the calls that the the library makes to itself internally, right? Should -O be specified when linking code? --FC
RE: 4.02 and Haskell 98
When will 4.02 (by which I mean the next stable release) be released? and Will it be Haskell 98-compliant, or is that going to be in a future release? We'll try to put out a source release before Xmas. Why are you interested? Scoped tyvars? No, I just want a reliable compiler with well-defined functionality. :) --FC
Unicode support
What is the status of the lastest release (3.01) with respect to Unicode support? Is it possible to write source in Unicode? How wide are characters? Do the I/O library functions support it? etc. --FC
3.00 is a minor release?
Under the "Getting GHC" heading on the GHC web page, version 3.00 is listed as the most recent minor release whereas 2.10 is listed as the most recent major release. Is this an error, or is there something to the definition of minor/major which I haven't caught on to? --FC
