[Yhc] Some more changes to core

[Tom Shackell]

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,
> module1;module2.function should be plenty.

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

generates

    Foo.Foo.Prelude.200.bar v217 v218 = ...

this is just about decidable, but it's awfully hard work. There may also 
be other things that I'm not aware of that do this too. In my opinion 
the cleanest resolution is to say that the module name is always 
separated with a ';'.

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

Well thinking about it it's probably not strictly necessary for my 
purposes - it would be possible to instead use the 'String -> Id' map 
now generated by the conversion process. However anyone else wanting to 
compile Core who wants to retain the ability to do separate compilation 
is likely to need the information and they probably wont have that 
mapping available.

That said ...

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

These are both good points, of course I was simply going to use the list 
to build a Data.Map and then use that for the compilation process. But 
the strictness information is a reasonable issue. That said the .hi 
files don't contain strictness information either so adding strictness 
would already involve a .hi file change (which is not a minor thing).

I guess either way is fine on this one ...

Cheers


Tom