[Yhc] Some more changes to core

Isaac Dupree isaacdupree at charter.net
Mon Aug 6 11:08:05 EDT 2007


Tom Shackell wrote:
> 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 = ...

Actually, you can. As long as "the module name with which you're 
qualifying the symbol you're defining", is the same name as "the name of 
the module you are in".

200_bar --A. starts with a number
200_+.+ --B. part varid, part varsym
instance names --C. very complicated

(A) might be changed with a prefix; (b) and (c) would require more 
mangling to make them reasonable names, so it may not be worth it.  The 
semicolon seems good - it's not even part of "[]", "(,,,,)", etc. (which 
is why the comma on second thought seems like a bad idea to me)  Of 
course it is quite contradictory to the way the semicolon is used in 
Haskell syntax.


Foo.Bar;Prelude.Eq;Foo.Bar.Baz;==
ok

Foo.Bar;Foo.Bar.Baz;Prelude.Eq.==
I don't think this one makes much sense, since Prelude is the module and 
Prelude.Eq is in it.

Prelude.Eq;Foo.Bar.Baz;Foo.Bar.==
not unreasonable, although do consider that it's possible to define 
several Foo.Bar.=='s each part of different classes defined in different 
modules.

All of these however, don't put semicolons between
Prelude.Eq  (why not Prelude;Eq ?)
Foo.Bar.Baz (why not Foo.Bar;Baz ?)
.  Since qualification is required,
Foo.Bar;Prelude;Eq;Foo.Bar;Baz;==
would be perfectly unambiguous, containing the three relevant modules, 
the class name, the type name, (and the member name when it's not the 
whole dictionary being referred to).  Prelude.Eq and Foo.Bar.Baz are 
tightly tied together, though, and it would be nice for them to use a 
different separator symbol. such as
Foo.Bar#Prelude;Eq#Foo.Bar;Baz#==
if we can only come up with a good '#' (two semicolons?? some curly 
bracket(s)?? the "`" symbol used in haskell to make functions infix??)
Anyway, code that uses it should have an abstraction (data type or just 
functions) for dealing with them in a comprehensible way.
So we are free to choose any simple unambiguous form we want.


BTW. good work on Core, I hope to be compiling to it some day soon 
(don't get your hopes up, I have more unfinished plans than time ;)

Isaac



More information about the Yhc mailing list