Re: FreeBSD/amd64 registerised running
Neil Mitchell wrote: Hi I'm hoping that by the end of this summer, nhc98 will be able to compile the whole of ghc. :-) Also, and alternatively, the yhc chaps have mooted the idea of moving from nhc98's front end to ghc's, which might eventually give you a fully portable bytecode route to bootstrapping ghc on new machines. We half thought about that, but a more direct goal is to be able to convert GHC Core to Yhc Core, then we can use either GHC's front end (via system) or Yhc's (natively). This would mean that we would be able to compile any library with GHC then use it with Yhc. This project will take about three days, once GHC has a non-broken Core library. How do you plan to implement unboxed types? AFAIK, implementing unboxed types requires a typed intermediate language. Maybe you could get away with boxing all the unboxed types, but then Int would have an extra level of boxing. And the other big problem with implementing GHC core is all the primitives... Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Claus Reinke wrote: I'm confused. I thought we copied the configuration from the target to the host as part of the bootstrapping process, but now I can't see how this is supposed to happen for HsBaseConfig.h. It looks like following the instructions in the building guide will result in failure if you try to cross-compile between machines with different word sizes, but I know I've done this in the past :-/ Ian, any idea how this is supposed to work? Anyway, to answer your question, using hsc2hs in System.Posix.Types will cause problems for bootstrapping GHC, yes, because we can't run hsc2hs on the target without GHC, but we can run configure. I suppose we could add a dependency on another Haskell compiler just to run hsc2hs, but that's a pain. how about a repository for platform-specific configuration files? that way you only need the first user on each platform to figure things out, either by installing extra tools or by modifying existing configuration files? The case we're worried about is the first time you port to a new platform, because after that we have a working compiler so there's no problem. The instructions in the GHC building guide describe how to do this (http://hackage.haskell.org/trac/ghc/wiki/Building/Porting). It's not especially well supported by the build system, so the process is a bit fiddly, but we have to be careful to make sure it is at least possible to do it and not too tortuous. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi How do you plan to implement unboxed types? AFAIK, implementing unboxed types requires a typed intermediate language. Maybe you could get away with boxing all the unboxed types, but then Int would have an extra level of boxing. Indeed, we intend to box everything. Plus there were compilers which did unboxing before having unboxed types - as the paper said, it wasn't as neat, but it was possible. I also have a design for a C backend where the Int can be packed into the pointer, which removes the boxes from all evaluated Ints. And the other big problem with implementing GHC core is all the primitives... The Yhc primitives aren't particularly nice, but we have a design in which they could be made much nicer, and also allow implementation of the GHC core primitives easily. This will probably be the larger chunk of work. Thanks Neil ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6.1 Release Candidate
On Thu, Apr 12, 2007 at 01:14:37PM +0200, Bjorn Bringert wrote: > On Apr 11, 2007, at 19:39 , Thorkil Naur wrote: > > >2. On my PPC Mac OS X 10.4, configure reports > > > >checking for DocBook XSL stylesheet directory... no > >configure: WARNING: cannot find DocBook XSL stylesheets, you will > >not be able > >to build the documentation > > > >Some time ago, I installed docbook-xsl from mac/darwinports and > >this complaint > >disappeared from the HEAD, but not from the 6.6 branch. The > >relevant HEAD > >change is this: > > [...] > > > >I suppose it would be useful for this change to be merged to 6.6.1. > > This is the relevant darcs patch: > > Mon Sep 18 16:28:31 PDT 2006 [EMAIL PROTECTED] > * Added Darwinports path to DocBook XSL stylesheets to configure. > > M ./configure.ac -1 +1 Now merged, thanks! Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildng ghc-devel from macports
On Thu, Apr 12, 2007 at 11:07:03AM -0400, Gregory Wright wrote: > > >configure: No cpphs found > >configure: No greencard found > >Setup: Unrecognised flags: > > --with-cc=gcc > >make[1]: *** [stamp/configure.library.build-profiling.base] Error 1 > >make: *** [stage1] Error 2 > > it to me directly (I maintain the macports ghc-devel port) if you'd > like. It sounds like the port needs to be updated to run "sh boot" instead of "autoreconf". Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Neil Mitchell wrote: Hi How do you plan to implement unboxed types? AFAIK, implementing unboxed types requires a typed intermediate language. Maybe you could get away with boxing all the unboxed types, but then Int would have an extra level of boxing. Indeed, we intend to box everything. Plus there were compilers which did unboxing before having unboxed types - as the paper said, it wasn't as neat, but it was possible. Right, but the problem is that if you box all of GHC's unboxed types, you end up with an extra layer of boxing compared to an implementation that just boxes everything. ie. it'll be worse than YHC is currently, so you'll need extra trickery to get back to where YHC is now. I also have a design for a C backend where the Int can be packed into the pointer, which removes the boxes from all evaluated Ints. Presumably you lose one bit of precision though, so GHC's Int# type would be 31 bits. We did at one stage have a GHC->OCaml translator with a 31-bit Int#, so it might be possible, but I think there will be some assumptions in the libraries that break (eg. Int32 will need to be implemented using Int64#). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
Hi > Indeed, we intend to box everything. Plus there were compilers which > did unboxing before having unboxed types - as the paper said, it > wasn't as neat, but it was possible. Right, but the problem is that if you box all of GHC's unboxed types, you end up with an extra layer of boxing compared to an implementation that just boxes everything. ie. it'll be worse than YHC is currently, so you'll need extra trickery to get back to where YHC is now. Possible, I'll have to think about this further. I was thinking along the lines of newtype Box a = Box !a then Int# = Box Int but I'm not sure if that will work or not. Anyway, its only a question of efficiency, and Yhc has a lot more things that will destroy efficiency than this! Presumably you lose one bit of precision though, so GHC's Int# type would be 31 bits. We did at one stage have a GHC->OCaml translator with a 31-bit Int#, so it might be possible, but I think there will be some assumptions in the libraries that break (eg. Int32 will need to be implemented using Int64#). We loose 2 bits, to leave room for enough tag bits. Fortunately this still fills the Haskell specification. We will have some method for implementing Int32, probably as a pointer once again. Thanks Neil ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildng ghc-devel from macports
Hi Ian, On Apr 13, 2007, at 9:19 AM, Ian Lynagh wrote: On Thu, Apr 12, 2007 at 11:07:03AM -0400, Gregory Wright wrote: configure: No cpphs found configure: No greencard found Setup: Unrecognised flags: --with-cc=gcc make[1]: *** [stamp/configure.library.build-profiling.base] Error 1 make: *** [stage1] Error 2 it to me directly (I maintain the macports ghc-devel port) if you'd like. It sounds like the port needs to be updated to run "sh boot" instead of "autoreconf". I can do this, but the previous procedure worked until a couple of weeks ago. Has something changed? Greg ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildng ghc-devel from macports
On Fri, Apr 13, 2007 at 10:27:54AM -0400, Gregory Wright wrote: > > I can do this, but the previous procedure worked until a couple of weeks > ago. Has something changed? Yes; autoreconf and configure no longer recurse into the libraries (as cabal was running configure too, so it was being run twice unnecessarily). Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD/amd64 registerised running
I wrote: > So, should I push my patch for building > System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs)? OK, I have pushed a revised patch, which should not alter the behaviour for ghc at all. I moved the invocation of hsc2hs into the NHC.* hierarchy, and just re-export that module from System.Posix.Types instead. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildng ghc-devel from macports
Hi Ian, On Apr 13, 2007, at 11:56 AM, Ian Lynagh wrote: On Fri, Apr 13, 2007 at 10:27:54AM -0400, Gregory Wright wrote: I can do this, but the previous procedure worked until a couple of weeks ago. Has something changed? Yes; autoreconf and configure no longer recurse into the libraries (as cabal was running configure too, so it was being run twice unnecessarily). The ghc-devel port in macports now uses the "boot" script instead of autoreconf. This fixes the reported problem. It seems as if someone has some work in progress that breaks the build, but that's the risk when building from HEAD. Best Wishes, Greg ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
diagnostics' identifier quoting style
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here's a random message selected from building GHC:
Warning: Defined but not used: `res_ty''
(the identifier is "res_ty{PRIME}", where {PRIME} is the ' mark)
Note that quotes are left:` (grave accent) and right:' (ASCII single
quote). Besides this being theoretically incorrect, identifiers can
include the ' symbol (generally meaning more like "prime" than "single
quote"...), making this look odd. Maybe it should show the
identifier-string so that it just has ordinary double-quotes around it?,
looking like:
Warning: Defined but not used: "res_ty'"
Isaac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGIBIQHgcxvIWYTTURAt5TAKC7Rkbgqr7RsuGEMgyXsMm7kbiIswCdHGs2
lJY8FH7CR8YXwJ47g+0gNWw=
=ptnw
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC's error messages are too verbose?
I've long wondered why GHC issues such prolix error messages when it runs into a problem. Here's a representative example from some hacking I'm currently doing: src/Network/Hackage/CabalPackage/Setup.hs:68:5: Couldn't match expected type `(RpmFlags, [String])' against inferred type `()' Expected type: IO (RpmFlags, [String]) Inferred type: IO () In the expression: (when (not (null unknown))) $ (do hPutStrLn stderr "Unrecognised options:" mapM_ (hPutStrLn stderr) unknown exitWith (ExitFailure 1)) This might not look like a terribly long error, but that's because I've snipped a bunch of context that GHC also prints: In the expression: do let (os, args', unknown, errs) = getOpt' RequireOrder options args opts = foldl (flip ($)) emptyRpmFlags os (when (rpmHelp opts)) $ (do printHelp stdout exitWith ExitSuccess) (when (not (null errs))) $ (do hPutStrLn stderr "Errors:" mapM_ (hPutStrLn stderr) errs exitWith (ExitFailure 1)) (when (not (null unknown))) $ (do hPutStrLn stderr "Unrecognised options:" mapM_ (hPutStrLn stderr) unknown exitWith (ExitFailure 1)) This length is on the modest side for a block of monadic code. With a longer chunk of code, individual error messages can easily stretch to dozens of lines long, due purely to GHC printing context information that amounts to repeating my source code back at me. I don't understand the motivation behind this verbosity. Clearly, a little bit of context is helpful, so I can see which expression GHC is objecting to, but why repeat the entire surrounding chunk of code back at me, when I already have the file name and line number, and the original code that caused the error? Compilers for other languages seem content with as little as one line of output per error (which I am not advocating), or a few lines of source with the problem highlighted, but I rarely see more. Hugs also tends towards the terse side, but I've never found this to be a problem. Cheers, http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Happy bug
[EMAIL PROTECTED]:~/cadt/src$ happy Parser.y
happy: parE
[EMAIL PROTECTED]:~/cadt/src$
A little code examination seems to show that this error cannot occur
for correct grammars. But still - it's not helpful. I would prefer
to see the actual first error rather than none of the errors.
Parser.y is attached.
I tried to send this to the bug report address, but SimonM's email
system rejected it as spam, even with a 25-bit hashcash stamp!
So now all of g-h-u is annoyed.
-- -*- Haskell -*-
{
module Parser where
}
%tokentype { Token }
%error { parse_error }
%token ID { T_Id $$ }
'\n' { T_NL }
'{'{ T_OB }
'}'{ T_CB }
'('{ T_OP }
')'{ T_CP }
'*'{ T_St }
';'{ T_Se }
'|'{ T_Pi }
"::=" { T_Sum }
"==" { T_Prod }
DERIVE { T_Deriv }
%%
spec :: { State -> State }
spec: {- empty -} { id }
| spec line '\n' { $1 >>> $2 }
line :: { State -> State }
line: {- empty -} { id }
| DERIVE derivat { second $2 }
| lhs derivat
{ \(txt, st) -> (txt `cat_st` derive ($2 st) $1, st) }
lhs:: { Type }
lhs : ID "==" fields { Prod_T (Product $1 ($3 [])) }
| ID "::=" cases { Sum_T (Sum $1 ($3 [])) }
cases :: { [Product] -> [Product] } -- difference list
cases : ID fields { (: Product $1 ($2 [])]) }
| cases '|' ID fields { $1 . (: Product $3 ($4 [])) }
fields :: { [Field] -> [Field] }
fields : {- empty -} { id }
| fields field{ $1 . $2 }
field :: { Field }
field : spquals declars ';' { $2 $1 }
-- this comes out reversed which is good - c types are written backward
spquals:: { R_Type }
spquals : ID { R_Tag $1 R_Nil }
| spquals ID { R_Tag $2 $1 }
declars:: { R_Type -> ([Field] -> [Field]) }
declars : declar { (:) . $1 }
| declars ',' declar { \ty -> $1 ty . ($2 ty :) }
declar :: { R_Type -> Field }
declar : '*' declar { $2 . R_Star }
| ID declar { $2 . R_Tag $1 }
| ddeclar { $1 }
ddeclar:: { R_Type -> Field }
ddeclar : ID { Field $1 }
| '(' declar ')' { $2 }
{
data Token = T_Id String | T_NL | T_OB | T_CB | T_OP | T_CP | T_St
| T_Se | T_Pi | T_Sum | T_Prod | T_Deriv
parseError :: [b] -> a
parseError _ = error "Parse error"
lexer [] = []
lexer ('(':xs) = T_OP : lexer xs
lexer (')':xs) = T_CP : lexer xs
lexer ('{':xs) = T_OB : lexer xs
lexer ('}':xs) = T_CB : lexer xs
lexer ('*':xs) = T_St : lexer xs
lexer (';':xs) = T_Se : lexer xs
lexer ('|':xs) = T_Pi : lexer xs
lexer (x:xs) | x `elem` " \t\v\r" = lexer xs
lexer ('\n':x:xs) | isSpace x = lexer (x:xs)
| otherwise = T_NL : lexer (x:xs)
lexer (x:xs) | isID x = lexID (x:xs)
lexID (x:xs) | isID x = T_Id (x:name) : rest
where (name, rest) = case lexID xs of
T_Id nam : res -> (nam, res)
res-> ("", res)
lexID cs = lexer cs
isID x = isAlphaNum x || x == '_'
-- | The type of supported derivations.
data Derivation = forall s. Derivation
{ der_gentext :: Type -> s -> Either String Sect_bag
, der_parse :: Parser Char (s -> s)
, der_initial :: s
}
-- |
-- Types for the sectioned-text output format.
data Section = Decl_Sect | Defn_Sect deriving(Eq,Enum,Bounded)
data Sect_bag = ST (Section -> [Char] -> [Char])
nil_st :: Sect_bag
nil_st = ST $ \_ -> id
cat_st :: Sect_bag -> Sect_bag -> Sect_bag
cat_st (ST f1) (ST f2) = ST $ \s -> f1 s . f2 s
emit :: Section -> [Char] -> Sect_bag
emit sec txt = ST $ \sec' -> if sec == sec' then (txt++) else id
-- |
-- The central data type used by CADT. This type represents one CADT
-- type. The CADT parser generates a set of these from the input.
-- The CADT derivers use this to generate code.
module Type where
-- | Represents one data type.
data Type = Sum_T Sum
| Prod_T Product
-- | A sum type; that is, a type consisting of multiple mutually
-- exclusive cases, each of which is a product, like a discriminated
-- union.
data Sum = Sum { s_name :: String-- ^ The name of the sum type as
-- a whole
, s_cases :: [Product] -- ^ The set of cases (in source
-- order)
}
-- | A product type - a set of fields all of which exist. A C struct.
data Product = Product { p_name :: String
, p_fields :: [Field]
}
-- | A field within a product type.
data Field = Field { f_name :: String
, f_type :: R_Type
}
-- | A referencing type, as used in 'Field' definitions to specify the
-- field type. While a 'Type' specifies how to build a new type, a
-- 'R_Type' gives the method for referencing an /existing/ type; in
-- terms
