Hi
Converting all such names to "Foo.200_bar" would indeed fix the problem, though the conversion process might be a bit fiddly ...
Yes, but I think it would be worth it.
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?
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.
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.
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. Thanks Neil