[Yhc] Some more changes to core

Neil Mitchell ndmitchell at gmail.com
Sun Aug 5 04:29:41 EDT 2007


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


More information about the Yhc mailing list