quasi-literal strawman

Mike Samuel mikesamuel at gmail.com
Tue Dec 15 10:52:23 PST 2009


2009/12/15 Tom Van Cutsem <tomvc at google.com>:
> Hi,
>
> Could you motivate why you chose to append the string "Quasi" to the type
> tag identifier? I.e.:
>
> "The QFN of 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

I'm not sure that it's obvious that there would be a linkage between a
type tag and a function of the same name, but I am worried about
posible collisions due to the dearth of short type-descriptive names
available for use as local variable names. Consider: var html =
html`...`;

> 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
>
>


More information about the es-discuss mailing list