[Yhc] Some more changes to core

[Neil Mitchell]

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.

Agreed, semi-colon is a sensible choice.

> CHANGE b) ADDING AN IMPORT TABLE
>
> I propose changing the Core datatype to include a list of symbols that
> are imported from other modules.

Is this necessary? We currently have a list of imported modules in the
Core data type. I would have thought you could build the import table
outside of the Core data type, since its not information in the Core
file, more information that is taken from other files.

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

>From the import list in a Core file, you can load all the .hi files,
and make a mapping outside of the Core data type. i.e, CorePlusImports
= (Core, CoreImportData).

The advantage of not putting this inside the Core data type is that
you can change it freely, and use a Data.Map for faster lookups etc.
It also allows to add extra information like strictness (Yhc.Core
already has a strictness analyser)


> CHANGE c) ADDING FIELDS TO CorePrim

> Three of these changes were suggested earlier.

All seem sensible.

> - Recommendation: from now on people don't do a complete pattern match
> on CorePrim instead using the field selectors and

Agreed. We also have isCorePrim, and functions like
coreFuncArity/coreFuncName which work on both primitives and
functions.

Thanks

Neil