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

Yhc.Core Proposal: Split out CoreLit's from CoreExpr, Add CoreAlt

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

Re: Some suggested changes to Yhc.Core

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
>    }

Re: Some suggested changes to Yhc.Core

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)"

Re: Some suggested changes to Yhc.Core

> 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

Subject: Changes to Core/Convert.hs, Shouldn't break anything but be aware

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

Some more changes to core

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 

Re: Some more changes to core

Hi

> 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 = ....

I disagree. Data.Maybe.fromJust is how you would write the fully
qualified name in Haskell, and is entirely unambiguous. One of the
design decisions was to make Core and Haskell appear as similar as
possible.

> The reason this change is necessary is to do with class instances and
> how the interpreter load symbols. Consider the following class instance
>
>      Foo.Bar;Prelude.Eq.Foo.Bar.Baz.==

Why can't this encoding be applied only to class instances? For a
class you need two module names and a function name,
module1;module2.function should be plenty.

> 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.

Re: Some more changes to core

Neil Mitchell wrote:
> I disagree. Data.Maybe.fromJust is how you would write the fully
> qualified name in Haskell, and is entirely unambiguous. One of the
> design decisions was to make Core and Haskell appear as similar as
> possible.

Well in the case of Data.Maybe.fromJust it is unambiguous however in my 
opinion consistency is more important than closeness to Haskell 
identifiers (perhaps others differ on this).

Of course closeness to Haskell for identifiers is a bit of a moot point 
anyway since if you want to generate Haskell you need to mangle the 
names in any case. You can't generate a Haskell file containing

    Data.Maybe.fromJust x = ...

If closeness to Haskell is deemed more important than consistency then 
the unambiguous cases could be left as they are. However I think much of 
the benefit of having the names close to Haskell will have already been 
lost.

It's quite nice being able to say *all* the generated names look like 
Haskell identifiers. It's much less nice saying "well some of the names 
look like Haskell identifiers, except class instances (and possible some 
others) which are different". To my way of looking closeness to Haskell 
identifiers is something that should either be wholly kept or wholly 
sacrificed; 50-50 satisfies no-one.

> Why can't this encoding be applied only to class instances? For a
> class you need two module names and a function name,

Re: Some more changes to core

Hi

> Well in the case of Data.Maybe.fromJust it is unambiguous however in my
> opinion consistency is more important than closeness to Haskell
> identifiers (perhaps others differ on this).

Closeness to Haskell reduces the learning curve, and also makes it
easier to follow when debugging. ; vs . is not massive, so probably
isn't massively different. The other thing that directs me slightly
further towards ; is the (.) function - Prelude.. feels ugly,
Prelude;. feels less so.

> Of course closeness to Haskell for identifiers is a bit of a moot point
> anyway since if you want to generate Haskell you need to mangle the
> names in any case. You can't generate a Haskell file containing
>
>     Data.Maybe.fromJust x = ...

Generating resultant Haskell is a rare case, so this shouldn't have
any bearing on our choice. We also need to encode much more than just
this.

> Sadly whilst class instances are the major culprit they are not the only
> one, local functions get the same kind of problems. For example
>
>     module Foo
>
>     foo x = bar x
>       where
>       bar x = ...