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