parsing differences
Hugs will happily accept definitions such as: (f `cross` g) (x, y) = (f x , g y) while ghc gives parse error on input: "cross" It is not that ghc doesn't like any definition with `` on the left, as x `op` y = x + y is fine, it just seems to be cases with brackets. It is not entirely clear from the language spec whether or not this is valid, but it does seem more consistent to allow this. Justin Cormack
Re: parsing differences
Hugs incorrectly allows declarations such as: (f `cross` g) (x, y) = (f x , g y) and (f.g) x = f (g x) because it parses patterns as expressions and then weeds out the things that don't make any sense. GHC does a better job of implementing Haskell 1.4 syntax/semantics in this regard. Alastair Reid (That said, I agree that the Hugs approach makes sense and is nicer - but I don't have the energy to join the Standard Haskell committee and duke it out with the Big Boys who're busy discussing much more weighty matters.)
GHC for IRIX 5.3?
I'm trying to get a version of GHC later than 0.26 up and running on
IRIX 5.3. Has anyone done this? The web material suggests they have
but no binary bundle is available yet.
I decided to have a go at compiling 0.29 with 0.26 (I presume this is
possible) as 0.26 is the only binary bundle available off the web for
IRIX 5.3.
First of all, the ghc script coming with the ghc-0.26 binary bundle
for irix-5.3 contains the following:
# $ENV{'GLASGOW_HASKELL_ROOT'} = '/some/absolute/path/name';
if (! $ENV{'GLASGOW_HASKELL_ROOT'}) { # good -- death to environment variables
$TopPwd = '/project/haskell/ghc-0.26';
$InstLibDirGhc = '/project/haskell/lib/ghc/0.26/mips-sgi-irix';
$InstDataDirGhc = '/project/haskell/lib/ghc/0.26';
} else {
$TopPwd = $ENV{'GLASGOW_HASKELL_ROOT'};
if ( '/project/haskell/lib/ghc/0.26/mips-sgi-irix' =~ /^\/(local\/fp|usr\/lo
cal)(\/.*)/ ) {
$InstLibDirGhc = $ENV{'GLASGOW_HASKELL_ROOT'} . $2;
} else {
print STDERR "GLASGOW_HASKELL_ROOT environment variable is set;\nBut can
't untangle /project/haskell/lib/ghc/0.26/mips-sgi-irix.\n(Installation error)\n
";
exit(1);
}
Halfway down this section, '/project/' is compared with some
regexp. This will always fail, moving on to the error report... I'm
sure this is how I downloaded it. Commenting out the above (and the
bit following it) and setting the paths by hand works fine. How odd.
Also, I had to change ${As} to use GNU Assembler (well-known problems
with IRIX). This change seemed to make ghc-0.26 work fine (I compiled
and ran the "Hello, World!" program at least).
Next, the following errors occur when compiling ghc-0.29 with
ghc-0.26:
1) qp2ap.pl depends on itself in the Makefile made in
ghc/utils/parallel/ and I can't see where it's supposed to be made
from (others are made from .bash files). My make program simply
deletes this circular dependency and tries to build it anyhow, making
${MSUB} diverge. I left this one for the moment. What does qp2ap do?
I didn't ask for parallel bizniz and the default is disabled for
parallel so why is it building in the parallel dir?
2) On compiling some of the .lhs files, a few programs complain and
stop with an error in a .hi file that was made by compiling a .lhs
file earlier. Eg. the first one to crop up is:
"basicTypes/SrcLoc.hi", line 12: undefined value: SrcLoc.SrcLoc2
on compiling yaccParser/UgenUtil.lhs. SrcLoc2 is a data constructor
not exported by SrcLoc. mkSrcLoc2 is exported however and is the
only entity imported from SrcLoc by UgenUtil.
This is as far as I've got. I've also noticed a lot of diff output
along the lines of:
*** basicTypes/OrdList.hi Wed Jan 24 07:45:11 1996
--- /usr/tmp/ghc18787.hiThu Jul 31 20:28:50 1997
***
*** 1,2
! {-# GHC_PRAGMA INTERFACE VERSION 6 #-}
interface OrdList where
--- 1,2
! {-# GHC_PRAGMA INTERFACE VERSION 5 #-}
interface OrdList where
I presume this is to do with the difference between 0.26 and 0.29 and
is nothing to worry about? (It seems to be comparing the .hi files I
produce now with the .hi files it was downloaded with.)
I hope someone can make sense of this and perhaps point me in a
fruitful direction (either via fixed relating to the above or via a
different route to obtain a recent version of ghc).
Cheers,
Graeme.
2.05: make boot problems
I've been trying to compile 2.05 with 2.02 on solaris2, but `make boot' fails when reaching ghc/compiler. It prints out this huge command line, and then only says "make: *** [depend] Error" and stops. I cut out the command line and inserted a -v: ghc -v -M -optdep-f -optdep.depend -optdep-o -optdepo-cpp -fhaskell-1.3 -fglasgow-exts -DCOMPILING_GHC -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -ideSugar -icoreSyn -ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -iabsCSyn -imain -ireader -iprofiling -iparser -inativeGen -recomp -DOMIT_DEFORESTER -lc -L/usr/ucblib -lucb parser/U_binding.hs ... And this prints (shorted): Haskell dependencies: /home/petli/fptools/bin/sparc-sun-solaris2/ghc-2.02/mkdependHS -f .depend -o o -- -v -M -optdep-f -optdep.depend -optdep-o -optdepo -cpp -fhaskell-1.3 -fglasgow-exts -DCOMPILING_GHC -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -ideSugar -icoreSyn -ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -iabsCSyn -imain -ireader -iprofiling -iparser -inativeGen -recomp -DOMIT_DEFORESTER -lc -L/usr/ucblib -lucb -- parser/U_binding.hs ... Arg list too long: /home/petli/fptools/bin/sparc-sun-solaris2/ghc-2.02/mkdependHS I cut out _this_ command line and executed it and then it didn't make any fuss. However, then `make all' says this: ghc -cpp -fhaskell-1.3 -fglasgow-exts -DCOMPILING_GHC -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -ideSugar -icoreSyn -ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -iabsCSyn -imain -ireader -iprofiling -iparser -inativeGen -recomp -DOMIT_DEFORESTER -lc -L/usr/ucblib -lucb -fvia-C '-#include"hspincl.h"' -c parser/U_binding.hs -o parser/U_binding.o -osuf o parser/U_binding.hs:6: Could not find valid interface file for `FastString' parser/U_binding.hs:7: Could not find valid interface file for `UgenUtil' parser/U_binding.hs:9: Could not find valid interface file for `U_constr' parser/U_binding.hs:10: Could not find valid interface file for `U_list' parser/U_binding.hs:11: Could not find valid interface file for `U_maybe' parser/U_binding.hs:12: Could not find valid interface file for `U_qid' parser/U_binding.hs:13: Could not find valid interface file for `U_ttype' Compilation had errors make: *** [parser/U_binding.o] Error 1 I have absolutely no idea of what to try next... Good wishes, Peter Liljenberg
Re: I just can't stand it any more
The compatability problem with Hugs using lazy ST and GHC using strict ST will be resolved as follows: Hugs will provide a strict ST monad by default. The lazy ST monad might be available for import from another module for compatability reasons. Alastair Reid
Re: Striving for compatibility
It would be wonderful if both GHC and Hugs would use the same module structure (for ST) and the same names. Make sure both use lazy state threads! Erik
Re: I just can't stand it any more
that would be fine but the word "might" makes me nervous. Lazy State is really really handy. I can send you some examples if your curious So if both ghc and hugs provided another monad LazyST in a module LazyST then that would be quite cool. cheers byron On Thu, 31 Jul 1997, Alastair Reid wrote: The compatability problem with Hugs using lazy ST and GHC using strict ST will be resolved as follows: Hugs will provide a strict ST monad by default. The lazy ST monad might be available for import from another module for compatability reasons. Alastair Reid
Re: Striving for compatibility
Hi Ralf, now that 2.05 is finally out, I'm going to copy as much of the GHC interface as possible. My first attempt (hugs/lib/glaExts/*.lhs) was based on a poorly remembered conversation with Sigbjorn a month or so ago. Alastair
