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