[Yhc] Some more changes to core

[Tom Shackell]

Neil Mitchell wrote:
> I agree its definitely necessary in the case of classes. I don't see
> treating classes like the other functions as being consistent. Classes
> are fundamentally different - most functions have one module name,
> classes have three - this is a built in inconsistency. I can see
> advantages to being able to "spot" class dictionaries and recover
> precisely their original context information, I've wanted it before
> and this desugaring scheme, applied only to classes, would give that.

Of course it's still very easy in the case that it's applied everywhere. 
You split the string based on ';'. If you get two parts its a normal 
name, if you get 3 or 4 parts its a class instance. Three is possible 
because the instance dictionary is generated as

  Foo.Bar;Prelude.Eq;Foo.Bar.Baz = (,) Foo.Bar;Prelude.Eq;Foo.Bar.Baz;==
				      Foo.Bar;Prelude.Eq;Foo.Bar.Baz;/=


> Don't you then pay to create a thunk, then evaluate it later? I
> thought that this was one of the main costs saved by strictness, which
> wouldn't be saved by a case transformation.

Conceptually, no

       case f x of
         _         -> ...

is a perfectly reasonable description to the backend that 'f x' should 
be compiled strictly (i.e. without thunks).

> I would have thought the best encoding would be:
> 
> Foo.Bar;Foo.Bar.Baz;Prelude.Eq.==
> 
> OR
> 
> Prelude.Eq;Foo.Bar.Baz;Foo.Bar.==
> 
> In the first the rule for extracting module names is "up to the first
> ; or last .", in the second its "skip all bits before  ;" - and I'm
> leaning towards the first. I read the first as "hey, I'm located in
> Foo.Bar, I operate over Foo.Bar.Baz and I'm really just a type
> specific version of Prelude.Eq.=="

Yeah that would be fine, don't forget that the class dictionary is

     Foo.Bar;Foo.Bar.Baz;Prelude.Eq

if that has any bearings on trying to understand what things are.

> Whatever scheme we do go with, I suggest a coreFunModule function be
> added which obtains the module from a function name, and assuming
> dictionaries are unambiguous, coreFunDictionary to split up the
> pieces.

or even 'coreModule' which would also work for data types. 
'coreFunInstance' is possibly a better name than 'coreFunDictionary'.


Cheers

Tom