Neil Mitchell wrote:
I disagree. Data.Maybe.fromJust is how you would write the fully
qualified name in Haskell, and is entirely unambiguous. One of the
design decisions was to make Core and Haskell appear as similar as
possible.
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).
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 = ...
If closeness to Haskell is deemed more important than consistency then
the unambiguous cases could be left as they are. However I think much of
the benefit of having the names close to Haskell will have already been
lost.
It's quite nice being able to say *all* the generated names look like
Haskell identifiers. It's much less nice saying "well some of the names
look like Haskell identifiers, except class instances (and possible some
others) which are different". To my way of looking closeness to Haskell
identifiers is something that should either be wholly kept or wholly
sacrificed; 50-50 satisfies no-one.
Why can't this encoding be applied only to class instances? For a
class you need two module names and a function name,
module1;module2.function should be plenty.
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 = ...
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 ';'.
Is this necessary? We currently have a list of imported modules in the
Core data type. I would have thought you could build the import table
outside of the Core data type, since its not information in the Core
file, more information that is taken from other files.
Well thinking about it it's probably not strictly necessary for my
purposes - it would be possible to instead use the 'String -> Id' map
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.
That said ...
The advantage of not putting this inside the Core data type is that
you can change it freely, and use a Data.Map for faster lookups etc.
It also allows to add extra information like strictness (Yhc.Core
already has a strictness analyser)
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).
I guess either way is fine on this one ...
Cheers
Tom
_______________________________________________
Yhc mailing list
Yhc@haskell.org
http://www.haskell.org/mailman/listinfo/yhc
