2009/12/15 Mark S. Miller <[email protected]>: > On Tue, Dec 15, 2009 at 12:40 PM, Mike Samuel <[email protected]> wrote: >> >> > One possibility is to make the tags uppercase by convention: >> > >> > HTML`...`; >> > XML`...`; >> > SQL`...`; >> > >> > Since language names are very often acronyms, this looks perfectly >> > natural (and I think it looks fine even when the name is not an >> > acronym). >> > > Yeah, despite the E precedent, Tom has convinced me too. (I meant to raise > this at lunch today but forgot.) I was still a bit queasy though. With > David-Sarah's UPPER_CASE suggestion, I am no longer queasy. > >> >> The UCASE_UNDERSCORED namespace is often used for things that are >> supposed to be constant in keeping with java style ( >> http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367 >> ), so unlikely to be used for locals and formals. > > > When these identifiers name a specific language (i.e., name the quasi-parser > for a specific language), then they will be constant. When one doesn't > statically know what quasi-parser one needs -- i.e., it comes from a local > or formal parameter -- then both the definition and use appears in the same > scope and need to look obviously connected. In that case, both should be > lower case, but these local names would chosen locally by the programmer so > there'd be no more than the normal chance of confusion. > In E, one of the constraints was that quasiliterals using the E quasi parser > would look like e`...`, where the E quasi parser being named here was > generally available. I wanted to avoid collisions on common single letters. > None of the language names I expect to be commonly used as quasi-parsers > need to have single letter names. Even for JS`...`, to have that refer to > whatever unmangled JS variable is in scope would, I think, be fine. > OTOH, if someone ever does build a C or E quasi-parser for use from > JavaScript, without mangling they should find some longer name to use for > their quasi parser. In JavaScript, I think this price is worth paying to > avoid mangling.
There are some languages with longer names that are not acronyms. From http://www.lua.org/about.html#name : Please do not write it as "LUA", which is both ugly and confusing... Ok, so the recommendation is to change the proposal to: (1) Change the mangling in "The QFN of QuasiTypeTag :: Identifier is" to be the identity function. No change is needed in the grammar because QuasiTypeTag already disallows reserved keywords. (2) Change all examples in the proposal to use the UCASE_UNDERSCORED naming convention. (3) Add a section recommending that naming scheme and explaining what we are trying to avoid. If that looks good, there is still one open question -- what to do with "The QFN of QuasiTypeTag :: ε is the identifier defaultQuasi." > -- > Cheers, > --MarkM > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
