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
_______________________________________________
Yhc mailing list
Yhc@haskell.org
http://www.haskell.org/mailman/listinfo/yhc
