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 <[email protected]> wrote: > 2009/12/14 Dean Landolt <[email protected]>: > > > > > > On Mon, Dec 14, 2009 at 7:04 PM, Mike Samuel <[email protected]> > wrote: > >> > >> 2009/12/14 Ash Berlin <[email protected]>: > >> > > >> > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
