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