quasi-literal strawman

Mike Samuel mikesamuel at gmail.com
Tue Dec 15 17:35:36 PST 2009

2009/12/15 Mark S. Miller <erights at google.com>:
> On Tue, Dec 15, 2009 at 12:40 PM, Mike Samuel <mikesamuel at gmail.com> 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.

More information about the es-discuss mailing list