[Yhc] Some more changes to core

Neil Mitchell ndmitchell at gmail.com
Sat Aug 4 19:49:28 EDT 2007


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


More information about the Yhc mailing list