Some suggested changes to Yhc.Core

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

Hello, I use core for a Haskell to flash (SWF) bytecode compiler. As far as I can tell, this change will only make my life easier. j. At Fri, 03 Aug 2007 14:50:33 +0100, Thomas Shackell wrote:
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
_______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org/mailman/listinfo/yhc

Thomas Shackell wrote:
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?
Is it useful to have "name of function in C (or Nothing for same as haskell)" , or would it be more convenient as an always-present string that is filled in with the Haskell-name if necessary? Or to put it another way, should something like `foreign import ccall doSomething :: IO ()` be distinguishable from `foreign import ccall "doSomething" doSomething :: IO ()` ? Isaac

Is it useful to have "name of function in C (or Nothing for same as haskell)" , or would it be more convenient as an always-present string that is filled in with the Haskell-name if necessary?
Or to put it another way, should something like `foreign import ccall doSomething :: IO ()` be distinguishable from `foreign import ccall "doSomething" doSomething :: IO ()`
Interesting question, I opted for the "keep as much information as possible" approach, but having said that I can't think of a single useful example where you'd want to be able to distinguish the above. I'd be equally happy for it to be filled in automatically, What do people think? Tom
participants (4)
-
Isaac Dupree
-
Jeremy Shaw
-
Thomas Shackell
-
Tom Shackell