quasi-literal strawman

Tom Van Cutsem tomvc at google.com
Tue Dec 15 10:11:30 PST 2009


Hi,

Could you motivate why you chose to append the string "Quasi" to the type
tag identifier? I.e.:

"The QFN of *QuasiTypeTag*<http://wiki.ecmascript.org/lib/exe/fetch.php?id=strawman%3Aquasis&cache=cache&media=strawman:quasi-strawman.html#pr-QuasiTypeTag>::
*Identifier* is the concatenation of *Identifier* and the string "Quasi".
The result is a valid *Identifier*. "

I know E employs a similar mechanism, but I don't know if it's worth having
it for Javascript.
Essentially, this is a form of name-mangling, which is fine if you're doing
macros/translation/compilation where the programmer is shielded from the
mangled name, but is weird when the programmer has to work with both mangled
and non-mangled names. If the type tag Identifier is going to be resolved
lexically anyway, and not in some separate namespace, wouldn't it be simpler
if one could write:

var html = ...;
...
html`...`

It is immediately apparent, even to someone not familiar with the language
feature's details, that 'html' will somehow refer to the quasi-function
defined above. The other way around, if you do introduce name mangling, then
it would probably be considered bad programming style to introduce a
variable named 'html' in a scope where 'htmlQuasi' is also visible, as it
would needlessly confuse programmers.

I understand you want to use short, descriptive names for type tags. I just
don't understand why you would want to give a longer name to the
corresponding quasi-function.

Other than that, I like your proposal.

Cheers,
Tom

On Mon, Dec 14, 2009 at 5:15 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

> 2009/12/14 Dean Landolt <dean at deanlandolt.com>:
> >
> >
> > On Mon, Dec 14, 2009 at 7:04 PM, Mike Samuel <mikesamuel at gmail.com>
> wrote:
> >>
> >> 2009/12/14 Ash Berlin <ash_js at firemirror.com>:
> >> >
> >> > On 14 Dec 2009, at 22:44, Mike Samuel wrote:
> >> >
> >> >> http://wiki.ecmascript.org/doku.php?id=strawman:quasis
> >> >> is a strawman for a concrete syntax that enables string interpolation
> >> >> as described in
> >> >> http://wiki.ecmascript.org/doku.php?id=strawman:string_interpolation.
> >> >>
> >> >> So far it's just an uploaded HTML file but I plan to make it more
> wiki
> >> >> friendly.
> >> >> If people want to edit it, let me know and I'll put out a wiki form
> >> >> pronto.
> >> >
> >> > First things first: the string interpolation strawman[1] is not string
> >> > interpolation. It's LINQ (Language Integrated Query) or very similar,
> which
> >> > dare I say it, is what E4X is (or attempts to be, spec bug not
> withstanding)
> >> > Which isn't to say I don't think the idea has merit, it is just more
> than
> >> > simply string interpolation. (When i say its LINQ - it feels very much
> like
> >> > the query syntax front end for it.)
> >>
> >> I'll look into LINQ.  I think it's more general purpose than E4X, but
> >> I've never read the E4X spec so take that with a grain of salt.
> >>
> >>
> >> > The pessimist in my would like to point out that you could (and people
> >> > inevitably will) still say `UPDATE foo SET x=$x`. Unless i've missed
> >> > something crucial this doesn't protect against that (as its not  a
> >> > sql`UPDATE ...`. Also which 'sql' - there are many variants)
> >>
> >> Please see the late binding arguments in
> >>
> >>
> http://google-caja.googlecode.com/svn/changes/mikesamuel/string-interpolation-29-Jan-2008/trunk/src/js/com/google/caja/interp/index.html
> >> for an explanation of why the sql prefix is unnecessary, and as you
> >> describe, often damaging.
> >>
> >>
> >> > backticks In perl, ruby and php is all the system execute command
> (which
> >> > I suspect you know) but the "where it allows interpolation though with
> a
> >> > more specific meaning than macro expansion" wording isn't quite
> correct --
> >> > it does more than just interpolattion.
> >>
> >> Yes, you're right.  It interpolates first and then executes it as a
> >> shell command in perl and PHP, and I believe ruby.
> >>
> >> > I really like the idea of being able to do things like |var my regexp
> =
> >> > re`(?i:\w+$foo\w+)`;|
> >> >
> >> > quasi-strawman.html says:
> >> >>> It would be convenient for some DSL use cases to allow
> LineTerminators
> >> >>> inside code, but it is unclear how this will interact with revision
> control
> >> >>> systems that rewrite newlines on checkout
> >> >
> >> >
> >> > If you want to use a certain form of a new line for what ever reason,
> it
> >> > would probably be best to use \n. Line continuations are rather
> annoying to
> >> > use in practice - if you want the literal to be split over multiple
> lines,
> >> > and to have new lines in the source you end up ending every line with
> \n\
> >> > which is just ugly. Since we are already talking about new syntax, I
> would
> >> > vote for allowing multi-line literals.
> >>
> >> So to keep score:  (for multi-line 1, against: 0, unspecified, ~6B :)
> >
> >
> > Just to update the scoreboard, I could tick off at least a few dozen
> people
> > that I've heard gripe about a lack of multiline literals. So ~6B -
> > ~30...that enough? No? Damn.
> >
> > But seriously, I do believe that this type of proposal is a huge
> opportunity
> > to bring multiline strings to js syntax. It would be a shame it didn't
> > include some mechanism for it.
> >
> > [snip]
> >
> >>
> >> > I can understand not having printf style formatting codes, but how
> would
> >> > you suggest you format a number to 2 decimal places?
> >>
> >> `Avg. Rainfall: ${n.ToFixed(2)}cm`
> >
> > Touché. I could live with that.
>
> Sorry, I didn't mean that to sound as flip as it did.
> I think formatting specifiers are important, and I hope the sprintf
> example shows how those can be embedded in literal portions in a
> fairly natural readable way, and meta data can always be packaged with
> data as in
>   `...${{ value: n, nDigits: 3 }}...`
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091215/df0e6b5a/attachment-0001.html>


More information about the es-discuss mailing list