2009/12/15 Tom Van Cutsem <[email protected]>: > 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 <[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
