- Yhc - Haskell.org

Some suggested changes to Yhc.Core
by Dimitry Golubovsky 07 Aug '07

07 Aug '07

Hi, Malcolm Wallace wrote: > Actually, I think it would be better just to add the single new name > "javascript". It's pretty easy, and allows us to represent the > convention using an enumerated type internally, rather than just a > String. Types are one of the reasons we like Haskell, aren't they? Perhaps there could be an intermediate solution: keep the calling convention field as a string, but add a command-line option, something like --allow-cconv=<comma-separated list> with default being whatever is in the Addendum plus those non-standard nhc98 convention names. For Javascript backend, I'll use --allow-cconv=javascript, etc. --allow-cconv=ANY would turn this check off (thus ANY in capitals being reserved word) This is all advisory to the final code generator, anyway. Thanks -- Dimitry Golubovsky Anywhere on the Web

2 1

Some suggested changes to Yhc.Core
by Dimitry Golubovsky 07 Aug '07

07 Aug '07

Hi, I'd support the idea of extending the primitive definition. My addition is, to extend the meaning of the corePrimConv field, perhaps to carry the information about external language the Core interacts with (as much as it may be associated with calling convention). I'd like to have ability to pass "javascript" into this field, even though this may break the existing FFI convention (or would it? - are we limited to only ccall and stdcall?). I'd also like to be able to have a free syntax form for foreign identifier (corePrimExternal) (thus being able to wrap calls to methods of Javascript objects such as "new Date.getTime()": foreign import javascript "new Date.getTime" getTime :: ... This would help developers of backends to detect which primitives imported from standard libraries (where they would be "ccall") are OK, and which need to be substituted using Overlays, e. g. ycr2js could complain if it encounters any primitive that uses "ccall". Thanks. PS Hopefully, it is not too late to add suggestions... -- Dimitry Golubovsky Anywhere on the Web

4 5

Yhc (and Catch?) bugs
by Isaac Dupree 06 Aug '07

06 Aug '07

Trying my Haskell Integer code I'm working on has triggered four (4) bugs in Yhc, one (1) of which also exists in a similar fashion in Hugs. See attached file. Luckily, I was able to find workarounds (none of which I want to keep) for all of them so that I run Catch on the module and get past the _Yhc_ errors (I had _successfully_ run Catch before with an earlier, buggier version of my code and got no useful information, but I figured I'd try again...). So: ]catch IntegerInTermsOfInt.hs Executing: IntegerInTermsOfInt.hs Compiling Compiling IntegerInTermsOfInt ( IntegerInTermsOfInt.hs ) Loading Core for YHC.Internal Loading Core for YHC.Primitive Loading Core for Data.Ratio Loading Core for Prelude Loading Core for Foreign.C Loading Core for Foreign.C.String Loading Core for Foreign.Util Loading Core for Foreign.C.Error Loading Core for YHC.ErrNo Loading Core for Foreign.C.Types Loading Core for Control.Monad Loading Core for Foreign.Word Loading Core for Numeric Loading Core for Data._CharNumeric Loading Core for Data.Char Loading Core for Data.Array Loading Core for YHC.Exception Loading Core for Data.Ix Loading Core for Foreign.Storable Loading Core for Foreign.Ptr Loading Core for Foreign.Int Loading Core for System.IO Loading Core for System.IO.Unsafe Loading Core for Data.IORef Loading Core for YHC.IORef Loading Core for Foreign Loading Core for Foreign.Marshal Loading Core for Foreign.Marshal.Alloc Loading Core for Foreign.Marshal.Utils Loading Core for Foreign.StablePtr Loading Core for Foreign.ForeignPtr Loading Core for Debug.Trace Loading Core for System.Exit Loading Core for PreludeAux Linking... catch: user error (invalid binary data found) ]catch IntegerInTermsOfInt.hs Executing: IntegerInTermsOfInt.hs Compiling catch: user error (invalid binary data found) In case it makes a difference, I've compiled and installed latest Yhc-darcs, and Catch-0.1.1, to prefix=$HOME, and have $HOME/bin in my PATH (and have neither installed anywhere else on my system). IntegerInTermsOfInt is the only module, in a file of the same name, and it only imports Prelude and Numeric. Isaac module YhcBugs where -- Bug: the "--_" sequence isn't considered to begin a comment by Yhc. -- I had to put a space between them. Try either of these lines and see the -- ridiculous incorrect errors they create: -- --_ `fd` dsjfkl = dfjs -- --_ `fd` dsjfkl = -- Bug: parenthesized patterns break: -- (which I use in order to make monomorphism clear in either -- H98 m-r or mono-pat-binds) {- test :: Eq a => a -> Bool test a = f a where (f) = \a -> (==) a a -} --Bug: removing the default, breaks things: {- default () iente :: Integral a => a -> Int iente = fromIntegral -} --Bug: Always specifying an import list when importing Prelude, --breaks handling of some built-in syntax. However, Hugs also has --this bug so I'll keep my workaround. {- import Prelude ( ) simple :: () simple = () -} --workaround (don't you hate it? :-) : --With Yhc, I could put 'qualified' on the following import too, --but Hugs needs them imported _unqualified_ and without being named. {- --For hugs to import (:) (and 2-tuples? other list bits?) we have to import --Prelude unqualified, and not like import Prelude () -- -- conformant implementations like GHC will not even --accept explicit imports of those things. --Also a June 19 2007 YHC from darcs seems quite broken without this import. --But we don't want to import anything but [](..), ()(..), (,)(..), -- (,,)(..) and so on --so we hide everything that according to Haskell98 would be importable. import Prelude hiding --manually copied down everything from :browse Prelude in ghci ((++),error,foldr,seq,concat,filter,zip,print,fst,snd,otherwise,(&&),(||) ,Bounded(..),Enum(..),Eq(..),Floating(..),Fractional(..),Integral(..) ,Monad(..),Functor(..),Num(..),Ord(..),Read(..),Real(..),RealFloat(..) ,RealFrac(..),Show(..),Bool(..),Char,Double,Float,Int ,Integer,Ordering(..),Rational,IO,Either(..) ,putChar,putStr,putStrLn,getChar,getLine,getContents,interact,readFile ,writeFile,appendFile,readLn,readIO,($!),String,map,not,id,const,(.),flip,($) ,until,asTypeOf,IOError,FilePath,ioError,userError,ReadS,catch,unwords ,unlines,words,lines,minimum,maximum,product,sum,foldl1,either,lex,read ,readParen,reads,ShowS,showParen,showString,showChar,shows,subtract ,realToFrac,fromIntegral,(^^),(^),lcm,gcd,odd,even,unzip3,unzip,zipWith3 ,zipWith,zip3,lookup,notElem,elem,break,span,dropWhile,takeWhile,splitAt ,drop,take,cycle,replicate,repeat,iterate,scanr1,scanr,scanl1,scanl,concatMap ,all,any,or,and,foldr1,foldl,reverse,(!!),length,null,init,tail,last,head ,undefined,uncurry,curry,maybe,(=<<),sequence_,sequence,mapM_,mapM,Maybe(..)) -}

3 6

Some more changes to core
by Tom Shackell 06 Aug '07

06 Aug '07

Hi All, In my quest to get Yhc bytecode compiled from Yhc Core I've discovered that I will need to make (yet more) changes to Core. In short the changes necessary are (from most substantial to least substantial): a) changing the way names are encoded b) adding to Core a list of symbols imported from other modules c) adding yet more things to the CorePrim data type Some of these may break some people's code, but hopefully not too many or too much. This email is quite long so feel free to skip to the relevant sections if you don't want to read it all. --------------------------------------------- BACKGROUND --------------------------------------------- Previously I was looking at converting the names generated by Core back into nhc98's internal Id data type and then using the nhc98 symbol table. I've decided this is a bad idea because it seriously limits what possible transformations could be made to core; anything that would cause a mismatch with the nhc98 symbol table wouldn't work. This is very much against the spirit of converting the backend to generate from Core in the first place. Thus the more ideal solution would be to convert the internal PosLambda to a Core form that contained enough information to do the complete bytecode generation process. Having done the translation the nhc98 symbol table could then simply be forgotten about. However, unfortunately Core at the moment, doesn't quite have all the information needed. --------------------------------------------- CHANGE a) CHANGING THE ENCODING OF NAMES --------------------------------------------- I propose changing the way Core encodes names from Module.Item to Module;Item. For example, the fromJust function would appear as Data.Maybe;fromJust x = ... instead of Data.Maybe.fromJust x = .... -- CONSEQUENCES --------- - Anyone who relies on being able to parse the names will find the name parsing code will break. - Anyone trying to convert the names to valid Haskell identifiers will need to change their code. -- REASON --------------- The reason this change is necessary is to do with class instances and how the interpreter load symbols. Consider the following class instance module Foo.Bar data Baz = Baz instance Eq Baz where a == b = True The Core generated for the '==' function would currently look like: Foo.Bar.Prelude.Eq.Foo.Bar.Baz.== a b = True This encodes: - that the instance is defined in the Foo.Bar module - that it is an instance of the class Prelude.Eq - that the data type being given an instance is Foo.Bar.Baz - that the function being defined is '==' The problem is with the ambiguity in separating these components. Suppose some function defined in another module needs to use the == function for the Baz datatype. It would do this by asking the interpreter to load "Foo.Bar.Prelude.Eq.Foo.Bar.Baz.==" In order to load this the interpreter first needs to work out which module file it should load. Unfortunately from this name alone it has no way of knowing. This name could be (Foo.Bar.Prelude).(Eq.Foo.Bar.Baz.==) Or (Foo).(Bar.Prelude.Eq).(Foo.Bar.Baz.==) Or even (Foo.Bar.Prelude.Eq.Foo.Bar.Baz).(==) The name simply doesn't contain enough information to decide which part is the module name and which part is the item in that module. I thus suggest changing the name Core generates to Foo.Bar;Prelude.Eq.Foo.Bar.Baz.== which makes it clear. Semicolon is a good choice of separator because it is one of the few characters that cannot appear in a valid Haskell identifier. --------------------------------------------- CHANGE b) ADDING AN IMPORT TABLE --------------------------------------------- I propose changing the Core datatype to include a list of symbols that are imported from other modules. So data Core = { ... coreImportSymbols :: [CoreImport] ... } data CoreImport = CoreImportData CoreData | CoreImportFunc { coreImportName :: String, coreImportArity :: Int } -- CONSEQUENCES --------- - Anyone who does a complete pattern match on Core will find their code breaks as it will have gained an extra field. -- REASON --------------- The only information Yhc Core currently provides about symbols defined in other modules is their name. This is not enough information to compile applications to those functions or make cases on those datatypes. For example, in module Foo you make an application to the function 'Bar.bar' such as Foo.foo x = Bar.bar (x+1) To compile this application the compiler needs to know the arity of the bar function. Depending on the arity it will then either make a partial application, a saturated application or a super-saturated application (each of which would generate different bytecodes). Similarly when casing on a datatype Foo.foo x = case x of Bar.Bar y -> ... The compiler needs to know what the tag number for Bar.Bar is, and whether this case statement is complete or partial (again each has different bytecodes). --------------------------------------------- CHANGE c) ADDING FIELDS TO CorePrim --------------------------------------------- I propose changing the CorePrim datatype to: CorePrim { ... corePrimExternal :: String, -- the 'C' name of the function corePrimConv :: String, -- the calling convention corePrimImport :: Bool, -- whether this is import/export corePrimTypes :: [String] -- the types of the arguments/return } Three of these changes were suggested earlier. The types would be a simple encoding of the arguments and return type, so. foreign import malloc :: Int -> Ptr a would have types [ "Prelude.Int", "Data.Foreign.Ptr a" ] -- CONSEQUENCES --------- - Anyone who does a complete pattern match on CorePrim (it's not recommended) will find their code breaks. - Recommendation: from now on people don't do a complete pattern match on CorePrim instead using the field selectors and (CorePrim{}) for pattern matches. This will make it easier to accommodate any further changes to CorePrim (which may well be necessary). -- REASON --------------- The current CorePrim datatype does not contain enough information to compile calls to foreign functions. The above changes would mean that from this bytecode backend's point of view this would no longer be true. --------------------------------------------- CONCLUSION --------------------------------------------- From a detailed look at the code, and a start at implementing the Yhc Core to Yhc bytecode compiler, I believe the changes listed above are everything that's necessary. I could easily be proven wrong on that one though ;-) Cheers Tom

5 19

HEADS UP: Broken Compiler
by Neil Mitchell 06 Aug '07

06 Aug '07

Hi, Due to the proposed changes to the Yhc Core format that have been made in the last week, we are going to have a broken compiler for the next few hours. Me and Tom are currently checking in the Core changes. Please do not pull, we'll update once this is all over. Thanks Neil

1 1

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

06 Aug '07

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

1 0

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