August 2007 - Yhc - Haskell.org

buildbot failure in macosx_ppc_3
by andrewjwilkinsonw＠gmail.com 06 Aug '07

06 Aug '07

The Buildbot has detected a new failure of macosx_ppc_3. Full details are available at: http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/118 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: macosxppc3 Build Reason: Build Source Stamp: HEAD Blamelist: Tom Shackell <shackell(a)cs.york.ac.uk> BUILD FAILED: failed yhc sincerely, -The Buildbot

1 0

buildbot failure in gentoo_x86
by andrewjwilkinsonw＠gmail.com 06 Aug '07

06 Aug '07

The Buildbot has detected a new failure of gentoo_x86. Full details are available at: http://www.indiegigs.co.uk:8010/gentoo_x86/builds/237 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: markus1 Build Reason: Build Source Stamp: HEAD Blamelist: Tom Shackell <shackell(a)cs.york.ac.uk> BUILD FAILED: failed yhc sincerely, -The Buildbot

1 0

Changes to Core/Convert.hs, Shouldn't break anything but be aware :-)
by Tom Shackell 04 Aug '07

04 Aug '07

Dear Yhc Core users, I've pushed changes to Core/Convert.hs, this is the code that converts nhc98 PosLambda into Yhc Core. This was in order to get the transformation to preserve how the internal Id data should be mapped to the names in Yhc Core. This is needed to convert the Yhc bytecode backend to generate from Yhc Core. The Core/Convert.hs code has more or less been rewritten from scratch, since in the end I decided it needed to be made monadic to reasonably accommodate the changes. I've checked the output from the process against the old process (on the whole of Prelude.hs) and the only thing that appears to have changed is how v_fail expressions are given unique numbers. Previously there were given a unique number per function, now they are given a unique number per module. I suspect, if anything, this should make people's lives easier. If however, you suddenly start finding that your core is not of the format you were expecting then please let me know. Thanks Tom

1 0

Some suggested changes to Yhc.Core
by Thomas Shackell 04 Aug '07

04 Aug '07

Hi All, I've been looking at compiling from Yhc.Core to Yhc bytecode (instead of from PosLambda) however there are one or two changes that I would need to make to Core to do this. All the changes (so-far) are limited to CorePrim, which would be changed to: data CoreFunc = CoreFunc ... | CorePrim { coreFuncName :: CoreFuncName, --^ name of the function in -- haskell corePrimArity :: Int, --^ arity of the function corePrimExternal :: Maybe String, --^ name of function in C (or -- Nothing for same as haskell) corePrimConv :: String, --^ calling convention used corePrimImport :: Bool, --^ true for an import, false for -- an export } i.e. this would add 3 constructors to the CorePrim data type. This would obviously break things for anyone who used a complete pattern match but if you only use the selectors it would continue to work fine. Does anyone have any objections (or suggestions for additional ideas) to these changes? Cheers Tom

4 3

Yhc.Core Proposal: Split out CoreLit's from CoreExpr, Add CoreAlt
by Neil Mitchell 03 Aug '07

03 Aug '07

Hi, Following in roughly the same vein as the libraries submission process, here is a submission to change Yhc.Core. Currently we have CoreInt, CoreInteger, CoreFloat, CoreDouble etc, all as members of CoreExpr. For alternatives in a case expression we have just any expression as the left hand side. I propose: data CoreExpr = .... | CoreLit CoreLit data CoreLit = CoreInt Int | CoreInteger Integer | CoreFloat Float The benefits of this change are minimal, but I think it cleans things up a bit. Next we can go from: CoreCase CoreExpr [(CoreExpr,CoreExpr)] to: data CoreAlt = AltCon CoreConName [CoreVarName] | AltLit CoreLit | AltDefault CoreCase CoreExpr [(CoreAlt,CoreExpr)] The advantages of this are many. Currently when matching "[]", it is possible to end up with CoreApp (CoreCon "[]") [], or CoreCon "[]", both of which mean the same thing. Additionally, lots of code looks like: let (CoreCon a,b) = fromCoreApp lhs vs = map fromCoreVar b The fromCoreVar here would crash if any of b's were not variables, something which is not guaranteed by the type system. As a reference point, GHC uses something more similar to what is being proposed. The original reason for allow any arbitrary expression was to permit desugaring of pattern matches after converting to Core, but that doesn't appear possible because of lazy/strict pattern matching, pattern matching in let/where etc. As such there is no benefit to arbitrary patterns in these positions. Any comments or thoughts on these things? Thanks Neil

1 0