Hi
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).
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.
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 = ...
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.
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 = ...
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.
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 ';'.
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.
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.
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.
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).
As said, we need to generalise .hi once we support this. Thanks Neil