- Yhc - Haskell.org

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

Update on Issue 143 (error in Configure)
by Dimitry Golubovsky 31 Jul '07

31 Jul '07

Hi, I made some research of the problem. I am unable to fix it: my knowledge of Python is extremely low. But the problem seems to have been localized. See http://code.google.com/p/yhc/issues/detail?id=143 - I put a comment with larger details. For those who wants to try - just build yhc alone, then this problem should not occur. That is, run "scons build yhc" Yhi will not be built, and the problem arises only when building Yhi (because it needs GMP runtime). Thanks. PS Hopefully our Python experts read this and fix the problem. -- Dimitry Golubovsky Anywhere on the Web

3 3

buildbot failure in macosx_ppc_3
by andrewjwilkinsonw＠gmail.com 30 Jul '07

30 Jul '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/112 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: macosxppc3 Build Reason: Build Source Stamp: HEAD Blamelist: Neil Mitchell BUILD FAILED: failed yhc sincerely, -The Buildbot

1 0

Running catch on the HughesPJ prettyprinter
by Thorkil Naur 27 Jul '07

27 Jul '07

Hello Neil (cc Yhc), I am trying to run your catch on the HughesPJ prettyprinter. The serious reason for trying this is that I suspect that some parts of the HughesPJ module are actually never used. That is, certain definitions are impossible to reach using the exported definitions. And I guess (but I haven't progressed far enough to tell) that catch can be used for this, simply by modifying some definition that you suspect is never used to head [] or perhaps just error "Something" and then see if catch can find a case where this error is reported. Another reason is, of course, the expected entertainment value of such an experiment. In the latter, I was not disappointed, as I will now describe in some detail: 1. Catch (http://www.cs.york.ac.uk/fp/darcs/catch/catch.htm) requires me to use Yhc, so I decided to upgrade my Yhc installation. That didn't work out particularly well, as reported separately to yhc(a)haskell.org. But as a workaround, I am simply using the Yhc that gets built by the Yhc buildbot slave on my machine regularly. For some reason, this still works, even if I am unable to build an entirely fresh Yhc. 2. Trying the catch Risers example, I got this reaction: > $ catch Risers > Executing: /Users/thorkilnaur/tn/install/catch-0.1/share/catch-0.1/examples/Regress/Risers.hs > Compiling > yhc: Could not parse cmd-line options: unrecognized option `-l' > > > catch: Failed to compile, /Users/thorkilnaur/tn/install/catch-0.1/share/catch-0.1/examples/Regress/Risers.hs > $ To correct this: > src/Prepare/Compile.hs: res <- system $ "yhc --hide --linkcore \"" ++ file ++ "\" " ++ flags (This is the http://hackage.haskell.org/packages/archive/catch/0.1.1/catch-0.1.1.tar.gz package that you recommend using). In addition: > Task: Overlay > yhc: Could not parse cmd-line options: unrecognized option `-o' > > unrecognized option `-r' > > unrecognized option `-e' > > > catch: Failed to compile the overlay was fixed by: > src/Prepare/Overlay.hs: res <- system $ "yhc --hide --core \"" ++ prim ++ "\"" 3. Next on the agenda, we get > $ catch HughesPJ > Executing: HughesPJ.hs > Compiling > Compiling Text.PrettyPrint.HughesPJ ( HughesPJ.hs ) > -- during after type inference/checking > Error: Type error type clash between Prelude.Int and Prelude.Bool > when trying to apply function at 931:26 to its 2nd argument at 931:31-931:33. > > catch: Failed to compile, HughesPJ.hs > $ This is fixed by changing HughesPJ.hs as follows: > 931c931 > < lay1 k _ sl _ | k+sl `seq` False = undefined > --- > > lay1 k _ sl _ | (k+sl) `seq` False = undefined And this is, of course, rather interesting, since this type error (I cannot see it as anything else) is neither detected by Hugs nor GHC. But that is a matter for further work some other time. 4. Then I get this problem: > $ catch HughesPJ > Executing: HughesPJ.hs > Compiling > Compiling Text.PrettyPrint.HughesPJ ( HughesPJ.hs ) > Loading Core for YHC.Internal > ... > Loading Core for PreludeAux > Linking... > catch: ycr/HughesPJ.yca: openBinaryFile: does not exist (No such file or directory) > > $ I have earlier disagreed with yhc as to where it's output files were placed and I also reported a bug about this some time back. This seems to be related, although I must admit that I have not at the time of writing investigated further. The first part of this problem is that bare "yhc HughesPJ" seems to place its output .hi and .hbc files in "../../Text/PrettyPrint/" and this is, of course, somewhat OK if you are already in "$SOMEWHERE/Text/PrettyPrint/". But if you are not, I assure you that this is confusing. So, instead of working with "$SOMEWHERE/HughesPJ.hs", I created "$SOMEWHERE/Text/PrettyPrint/HughesPJ.hs" and started working from there. And thus, I was able to compile with "yhc HughesPJ" and find the output .hi and .hbc files in the same directory as HughesPJ.hs. However, catch HughesPJ still couldn't find its ycr/HughesPJ.yca file. Looking around again, I found the yhc output, as directed by catch, in "$SOMEWHERE/ycr/Text.PrettyPrint.HughesPJ.yca", etc. So because HughesPJ.hs has a module name Text.PrettyPrint.HughesPJ, the --hide option of yhc performs this massaging of the directory and output file name. And, apparently, catch is not able to match yhc in this. This was fixed by changing HughesPJ.hs as follows: > 170c170 > < module Text.PrettyPrint.HughesPJ ( > --- > > module HughesPJ ( 5. And then catch starts to run. It is presently here: > $ catch HughesPJ > Executing: HughesPJ.hs > Compiling > Compiling HughesPJ ( HughesPJ.hs ) > Loading Core for YHC.Internal > ... > Loading Core for PreludeAux > Linking... > Transformations > Task: Overlay > Task: Firstify > Warning: Failed in stage Firstify > Task: LetElim > Task: OneArg > Task: UniqueVars > Task: ShortCtors > Analysing > Checking [1/19]: Data.Ratio.% with zero as the second argument, bad person > Partial: "Data.Ratio.%$142" > Answer: _ > Checking [2/19]: HughesPJ: Pattern match failure in function at 799:5-804:51. > Partial: "HughesPJ.HughesPJ.Prelude.580.get" > Partial: "HughesPJ.best" and it's been there for about an hour, working. But I am sure that you have also noticed the ominous "Warning: Failed in stage Firstify" which may indicate that there is very little chance of getting a useful result anyway. So I will probably just interrupt it before long. I know you are probably busy with other things, so understand that this matter is not particularly critical for me. But if you have any comments to this situation, I would gladly hear about them. Thanks and best regards Thorkil

2 2

pure-Haskell Integer implementation
by Isaac Dupree 26 Jul '07

26 Jul '07

I was working on a re-implementation of the Integer type in pure Haskell earlier this summer, represented by [Int], thinking it might be useful as a less-broken alternative to GMP than using plain Int for Integer. The code turned out around 500-1000 lines. It got pretty much working (in yhc, ghc, and hugs; according to QuickCheck comparing the results with native Integer anyway), though the code's still somewhat messy ...and large Integer division seems to be sometimes slower than expected (maybe a strictness issue, haven't looked into it) ...although, all functions are fast for small values that fit in one Int. Is anyone interested in more details or work on this? (P.S. I wonder if I should ask any other mailing list than yhc's?) Isaac

3 2

Still shrinking YHI for ARM7...question
by Alexis Morris 24 Jul '07

24 Jul '07

Hi all, So far I've been able to build YHI under the ARM7 toolchain (with a target size of 148KB) after making several small changes: In particular I have removed all directory related primitive functions from Sytem.c and WrapPrimitive, commented out threading code for locks, mutexes, and semaphores, removed thread.c, and also removed all expensive printf statements (can't use printf on target). Also Platform.h - #define NO_LIBFFI and NO_LIBGMP have been selected and - #define NO_SHARED has been selected So far this all compiles fine, and will fit into ROM but I have yet to test it...I would like to figure out what else I can skim...I really want to be able to run it from RAM (64KB) eventually. My question at the moment is whether I can remove stuff like pretty.c, and sanity.c (and possibly jonkers) without having a major breakdown of the system. TARGET := yhi_nxt C_VM_SOURCES := \ $(VM_DIR)/main.c \ $(VM_DIR)/basepath.c \ $(VM_DIR)/foreign.c \ $(VM_DIR)/heap.c \ $(VM_DIR)/info.c \ $(VM_DIR)/iofuncs.c \ $(VM_DIR)/mark.c \ $(VM_DIR)/mutator.c \ $(VM_DIR)/primitive.c \ $(VM_DIR)/profile.c \ $(VM_DIR)/stable.c \ $(VM_DIR)/external.c \ $(VM_DIR)/hashtable.c \ $(VM_DIR)/hsffi.c \ $(VM_DIR)/integer.c \ $(VM_DIR)/jonkers.c \ $(VM_DIR)/make.c \ $(VM_DIR)/module.c \ $(VM_DIR)/pretty.c \ $(VM_DIR)/process.c \ $(VM_DIR)/sanity.c \ $(VM_DIR)/stopcopy.c \ $(VM_DIR)/Array.c \ $(VM_DIR)/Concurrent.c \ $(VM_DIR)/FFI.c \ $(VM_DIR)/IO.c \ $(VM_DIR)/IORef.c \ $(VM_DIR)/PackedString.c \ $(VM_DIR)/Prelude.c \ $(VM_DIR)/RuntimeAPI.c \ $(VM_DIR)/WrapPrimitive.c \ $(VM_DIR)/System.c \ Thanks, -- </Alexis>

3 3

buildbot failure in macosx_ppc_3
by andrewjwilkinsonw＠gmail.com 23 Jul '07

23 Jul '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/110 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: macosxppc3 Build Reason: Build Source Stamp: HEAD Blamelist: Neil Mitchell BUILD FAILED: failed yhc sincerely, -The Buildbot

1 0

Issue 143: scons failed on line 109 of configure.py (was: Re: Thorkil, myself, who else?)
by Dimitry Golubovsky 20 Jul '07

20 Jul '07

I have submitted issue 143 -- Dimitry Golubovsky Anywhere on the Web

1 0

Thorkil, myself, who else?
by Dimitry Golubovsky 20 Jul '07

20 Jul '07

Hi, It looks like both Thorkil and myself see very similar problems: Mine: scons: Reading SConscript files ... Building version 0.7.0-20070712053136-custom. Checking for architecture... x86 Checking for operating system... linux2 Checking for Subversion binary... "svn" Checking for Subversion version... Found version 1.4.4. Checking for GHC binary... "ghc" Checking for GHC version 6.4.1 or later... Found version 6.6.1. Checking for C header file gmp.h... yes Checking for mpz_t integ; mpz_init (integ) in C library gmp... yes Checking for libgmp version... 4.2.1 scons: *** File "/home2/dima/repos/yhc/build/configure.py", line 109, in configure See also: http://haskell.org/pipermail/yhc/2007-July/001011.html (full message, also has debug output from scons) Thorkil's (almost identical, even on completely different architecture): scons: Reading SConscript files ... Building version 0.7.0-20070712053136-custom. Checking for architecture... (cached) ppc Checking for operating system... (cached) darwin Checking for Subversion binary... (cached) "svn" Checking for Subversion version... (cached) Found version 1.4.0. Checking for GHC binary... (cached) "ghc" Checking for GHC version 6.4.1 or later... (cached) Found version 6.6.2. Checking for C header file gmp.h... yes Checking for mpz_t integ; mpz_init (integ) in C library gmp... yes Checking for libgmp version... 4.2.1 scons: *** File "/Users/thorkilnaur/tn/YhcDarcsRepository/yhc/build/configure.py", line 109, in configure I'm suspecting gmp as the test fails exactly there. Does anyone have an older gmp (3.x) to try? PS I have gmp 3.x on an older computer. For some reason, I couldn't build Yhc completely after darcs pull (I didn't fullclean, and I am basically migrating my development away from that computer), but at least scons testing of gmp did not fail. I cannot blame on the newer gmp otherwise, as ghc works fine with it. It seems something wrong with scons. Thorkil: when were you able to build Yhc last time, and what was your gmp version then? Thanks. -- Dimitry Golubovsky Anywhere on the Web

2 6

Building fresh Yhc reports: scons: *** File "/Users/thorkilnaur/tn/YhcDarcsRepository/yhc/build/configure.py", line 109, in configure
by Thorkil Naur 20 Jul '07

20 Jul '07

Hello, When I say "scons" to a freshly pulled yhc, this is the response: scons: Reading SConscript files ... Building version 0.7.0-20070712053136-custom. Checking for architecture... (cached) ppc Checking for operating system... (cached) darwin Checking for Subversion binary... (cached) "svn" Checking for Subversion version... (cached) Found version 1.4.0. Checking for GHC binary... (cached) "ghc" Checking for GHC version 6.4.1 or later... (cached) Found version 6.6.2. Checking for C header file gmp.h... yes Checking for mpz_t integ; mpz_init (integ) in C library gmp... yes Checking for libgmp version... 4.2.1 scons: *** File "/Users/thorkilnaur/tn/YhcDarcsRepository/yhc/build/configure.py", line 109, in configure I tried the scons fullclean + depends sequence also, the result is the same. Interestingly, my yhc buildbot slave seems in good shape ... Help would be very much appreciated. Thanks and regards Thorkil

1 0