[Yhc] Some more changes to core

[Tom Shackell]

Neil Mitchell wrote:
> 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.

Yes I think "Data.Maybe.fromJust" is a lot better than 
"Data.Maybe._417", but I think the difference between 
"Data.Maybe.fromJust" and "Data.Maybe;fromJust" is fairly small ...

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

fair enough.

> I find this case much more compelling than the class one. However, it
> seems in this case that 200 is a "unique" bit, so why not Foo.200_bar,
> which is still unique, and entirely unambiguous. The Prelude, and the
> duplication of Foo, both seem really random.

That's interesting since I can see absolutely no way to make the class 
case unambiguous except by adding a different separator, in that way it 
would seem the more compelling case :-)

Converting all such names to "Foo.200_bar" would indeed fix the problem, 
though the conversion process might be a bit fiddly ...

> I am still unconvinced. I agree that the rule for extracting module
> names should be simple and unambiguous, but still think introducing ;
> is probably unnecessary.

Well I think it's definitely necessary in the case of classes, and if 
you're going to do it for classes why not be consistent and do it 
everywhere? It would definitely be useful to know what other people 
think on this question ...

As a little side note for the same reasons the current system doesn't 
guarantee unique names for class instances.

   (ModA.ModB).(ModC.ClassD).(ModE.DataF).g

and

   (ModA).(ModB.ModC.ClassD).(ModE.DataF).g

are different instances, but they have the same unique Core name. Pretty 
unlikely to occur in practice but possible none the less.

> Anyone wanting to do separate compilation in Core will need some sort
> of .hi file, and is likely to need custom information from each .hi
> file. At the moment that would be awfully painful, once its needed
> we'll generalise the .hi file mechanism.

Well ... possibly though I think you could do a lot just knowing the 
arity and data constructors. Of course for strictness information the 
core strictness analyser could even transform the core to an 
appropriately strict version (through the use of cases) in which case no 
strictness information needs to be passed to the back-end at all. In 
many ways this is the cleaner solution.

As I say, I'm happy enough to leave that change out, I just imagined it 
might be useful to people.


Cheers

Tom