quasi-literal strawman

Mark S. Miller erights at google.com
Tue Dec 15 17:17:39 PST 2009

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091215/ed416a7f/attachment.html>

More information about the es-discuss mailing list