Re: quasi-literal strawman

[Mike Samuel]

2010/4/1 Ash Berlin ash...@firemirror.com:
 On 29 Dec 2009, at 16:36, Mike Samuel wrote:
 2009/12/28 Waldemar Horwat walde...@google.com:
 Mike Samuel wrote:

 That's the case right now, except that to escape a backtick one does
 $\`  instead of \`.

 Having `\`` not do what I'd expect escaping to do truly surprised me.  I
 thought that this was just a bug in the grammar when I read the wiki page.

 The grammar has other bugs having to do with \ characters inside identifiers
 and QuasiLiteralBodyParts.

 Are you referring to problems with something like like
  `$foo\u0061\u0020`
 where the Identifier production consumes both escape sequences but the
 second makes the identifier illegal?

 So an dentifier production that would limit the UnicodeEscapeSequence
 to matching classes (L*, Mc, Mb, Nd, Nl, Pc) and the single codepoints
 (_, $, ZWNJ, ZWJ).



 Has there been any feedback on quasi-literal at any of the TC39 meeting(s)?

Ash, I presented on this at the meeting at Apple last week.  You can
find my slides at
file:///home/msamuel/svn-changes/clean/google-caja/doc/html/es-macros.html
.  Those are the slides I presented with one exception -- I changed
terminology from macros to quasis for reasons explaned below.

Below are some of the major threads of discussion.  I apologize if
I've missed anything, and I can't remember who said what so I've just
left everything unattributed.  My responses are inline, and if anyone
feels I've miscaptured the discussion, please respond inline.


== It is not a macro system

Quite right.  An earlier version of the proposal was a macros proposal
with JIT expansion, but the version I presented had the same goals but
was not a macro system and I caused a lot of confusion by billing it
as such.  My apologies.


== Arguments on performance are weak.

It was pointed out that hand coded code often works better than macro
expansion in practice.

I agree though with the overall criticism that performance might not
be the best selling point.

I agree that a human who understands the compiler can do better than a
macro expander.

I disagree that this is the case for code under maintenance, and think
that an idiom implemented as a macro can benefit greatly from a
library author who understands the compiler, whereas in the non-macro
case, the understanding of the compiler has to be in a much larger
group of application authors.


== The calling conventions are profligate with object creation and
function calls.

This is a valid criticism.  The object creation, and function overhead
can be entirely eliminated by inlining as described in the performance
section.  And we discussed a few ways of tweaking the calling
conventions to avoid unnecessary object creation.


== Proposed performance optimizations are untenable

It was argued that the proposed performance optimizations are
untenable because they require global analysis.  This is false --
function inlining does not require global analysis.

It was suggested that implementing these optimizations in browsers is
difficult.  I think this is false, but can only handwave.  Pre-browser
code optimization tools like Google's closure compiler can do
inlining.  Browsers have good reason not to do complicated
optimizations when code is loaded, but could always use slow times to
do similar rewriting optimization on hot JS files in the browser
cache, so there is no need to accept a load time hit to benefit from
inlining.


== Grammar

There was a missing production in the grammar and the grammar,
especially escaping conventions, are going to require some time to
hammer out.


== Conclusion

There was no consensus on the goals, proposed semantics, or grammar.
As such it's premature to take it out of strawman status.
Knowing what library developers want would help target discussions.
I am going to canvas library developers so that I can present a more
compelling proposal.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[P T Withington]

On 2010-04-05, at 17:37, Mike Samuel wrote:

 You can
 find my slides at
 file:///home/msamuel/svn-changes/clean/google-caja/doc/html/es-macros.html
 . 

I'd love to see your presentation, but I can't seem to reach your home dir from 
my LAN.  Any chance there is a more public copy somewhere?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Ash Berlin]

On 29 Dec 2009, at 16:36, Mike Samuel wrote:
 2009/12/28 Waldemar Horwat walde...@google.com:
 Mike Samuel wrote:
 
 That's the case right now, except that to escape a backtick one does
 $\`  instead of \`.
 
 Having `\`` not do what I'd expect escaping to do truly surprised me.  I
 thought that this was just a bug in the grammar when I read the wiki page.
 
 The grammar has other bugs having to do with \ characters inside identifiers
 and QuasiLiteralBodyParts.
 
 Are you referring to problems with something like like
  `$foo\u0061\u0020`
 where the Identifier production consumes both escape sequences but the
 second makes the identifier illegal?
 
 So an dentifier production that would limit the UnicodeEscapeSequence
 to matching classes (L*, Mc, Mb, Nd, Nl, Pc) and the single codepoints
 (_, $, ZWNJ, ZWJ).
 


Has there been any feedback on quasi-literal at any of the TC39 meeting(s)?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Waldemar Horwat]

Mike Samuel wrote:

That's the case right now, except that to escape a backtick one does
$\`  instead of \`.


Having `\`` not do what I'd expect escaping to do truly surprised me.  I 
thought that this was just a bug in the grammar when I read the wiki page.

The grammar has other bugs having to do with \ characters inside identifiers 
and QuasiLiteralBodyParts.

   Waldemar
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mike Samuel]

CC [+es-discuss]

2009/12/23 Kevin Curtis kevinc1...@googlemail.com:
 On Wed, Dec 23, 2009 at 2:57 PM, Mike Samuel mikesam...@gmail.com wrote:
 Re quasi-literal and error handling - if the function called by the
 quasi throws an error how is it reported? Can the specific character
 position in the quasi that caused the error be reported?
 re`\s+$$$baz\s+`
        ^

 This is a good point.  To determine the location of a given character,
 a quasi function needs to know the width of the preceding
 substitutions and positions of any $\ escapes, which it does not
 currently know.


 Also, to report the error position in terms of the script overall
 would it be necessary for the character pos/line number of the Error
 object to be set. This would be possible if quasi's at compile time
 had:
 - access to the ast tree to set the pos value directly
 - access to pragmas to pass the pos through to the ast. See:
 https://mail.mozilla.org/pipermail/es-discuss/2009-November/010105.html

Funny.  I was actually just writing up an alternative implementation
based on JSON ASTs to send to some macro-loving schemers.
That might address the error reporting problem, and allows quasis to
specify new flow control constructs by allowing deferred execution,
without breaking the static analyzability or backwards portability.

Possible alternative:

Transform
foo`baz${bar}`

using JSON ASTs to a hygienic macro as in:

eval(
verifyHygienic(
foo('baz', ''),
[
Object.freeze(['Reference', { identifier: 'bar' }])
],
[]
)
)

where the lists are capabilities.  The use of an expression in a
substitution grants authority to use that in an AST produced by the
quasi function.  The AST produced by the quasi function is not allowed
to have any free variables besides those in substitutions, and (still
TODO) a reference to the quasi function itself which provides access
to supporting code defined with the quasi function.

The verifier looks like,

function freeNamesExcluding(
ast,  // The AST whose free names are put on out.
exclusions,   // Subtrees to exclude, compared by identity (===).
outNames, // Receives free names.
outLabels) {  // Receives free labels.
  if (exclusions.indexOf(ast) = 0) { return; }  // Compared by identity.
  ...
}

// Returns an AST that is reference identical unless a name needs to
// be rewritten.
function alphaRenameExcluding(
ast,
scope,
readContext,  // True if ast is read, e.g. not the left operand of =
writeContext,  // True if ast is a LeftHandSideExpression.
identGenerator,
readExclusions,
writeExclusions) {
  if ((readContext  readExclusions.indexOf(ast) = 0)
  || (writeContext  writeExclusions.indexOf(ast) = 0)) {
return ast;  // Preserve capabilities
  }
  // Sample each property from ast exactly once.  See Lying objects
  // below.

  // If introduces a scope, create a new scope and recurse to find all
  // declarations, and use identGenerator to assign new identifiers for
  // names and labels.

  // Recurse and build a list of renamed children.
  // Only writeContext should be true for the first child of '=' ops, and
  // for(in) loops, and declaration names.
  // Set both readContext and writeContext for the first child of '+=' et al.
  // The second child of '.' op should have neither read nor write context set.
  // For all others, set readContext but not writeContext.

  // Return a new AST node using renamed children.
  // If (readContext || writeContext), rename using name and label
  // values from scope.
}

function verifyHygienic(astMaker, astReadCaps, astWriteCaps) {
  Object.freeze(astReadCaps);
  Object.freeze(astWriteCaps);
  // Compute set of free names in astCaps
  var freeNamesInCaps = {};
  var freeLabelsInCaps = {};
  var allAstCaps = union(astReadCaps, astWriteCaps);
  each(
  allAstCaps,
  function (ast) {
freeNames(ast, freeNamesInCaps, freeLabelsInCaps);
  });
  var allCapIdents = union(freeNamesInCaps, freeLabelsInCaps);
  // Produces distinct identifiers that do not conflict with language
  // keywords (reserved or otherwise) or with any identifier free
  // in the input ASTs.
  var namer = function nameGenerator() {
var counter = 0;
return function () {
  var name;
  do {
name = '$' + counter;  // Disjoint from keyword namespace.
  } while (name in allCapIdents);
  return name;
};
  }();
  // Delegate to the untrusted astMaker function to produce an AST.
  var outAst = astMaker(astReadCaps, astWriteCaps);
  // Make sure outAst is hygienic.
  // This has the side effect of copying the AST nodes created by astMaker,
  // which insulates against lying objects like:
  // return [
  //   'binary',
  //   { get operator() { return (++counter  1) ? '-' : '-='; } },
  //   ... ]
  outAst = alphaRenameExluding(
  outAst, {}, true, false, namer, astReadCaps, astWriteCaps);
  // Compute the set of 

Re: quasi-literal strawman

[Kevin Curtis]

The JsonML AST was a half-baked go at 'scheme by the backdoor'.
(Though I muddied the water with the idea of using JsonML as a
transport protocol. Doh.).

The strawman has been updated with an 'ast' entry:
http://wiki.ecmascript.org/doku.php?id=strawman:ast

Re: In order for this to be practical, most of the current ECMAScript
utilities that currently take program text as a string would need to
be extended to accept an AST as well.

Is this something like the Python ast module:
ast.parse() would parse ECMAScript source to an AST of ECMAScript
objects. Could be pure ES.
eval() would take an AST tree of ECMAScript objects. The
implementation would walk the tree of ES objects to build the native
C++ AST (which is then used to generate and execute code). This is how
the Python ast module works.

Could this revised eval(|AST of ES Objects|) be an be a
efficient/realistic target for alt-JS's/DSL's/rewriters/LINQ? It
should be straightforward to implement. The native C++ AST remains an
unconstrained 'artefact of the implementation' given that ast.parse()
is pure ES.

Regards.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[ihab . awad]

On Wed, Dec 23, 2009 at 10:45 AM, Kevin Curtis
kevinc1...@googlemail.com wrote:
 The strawman has been updated with an 'ast' entry:
 http://wiki.ecmascript.org/doku.php?id=strawman:ast

I did that. I needed something to point to when I said, in a separate
(as of yet unpublished) proposal, that ${that} would be a nice thing
to have.

 Is this something like the Python ast module:
 ast.parse() would parse ECMAScript source to an AST of ECMAScript
 objects. Could be pure ES.
 eval() would take an AST tree of ECMAScript objects. The
 implementation would walk the tree of ES objects to build the native
 C++ AST (which is then used to generate and execute code). This is how
 the Python ast module works.

Yes, that's what I was thinking.

 Could this revised eval(|AST of ES Objects|) be an be a
 efficient/realistic target for alt-JS's/DSL's/rewriters/LINQ? It
 should be straightforward to implement. The native C++ AST remains an
 unconstrained 'artefact of the implementation' given that ast.parse()
 is pure ES.

Yep.

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Kevin Curtis]

Ihab - thanks for that info.

My basic first cut of evaluating JsonML was implemented in C++ by
treewalking the ES objects and building the AST. (Not sure why i went
down the string parsing road). I could put the code into
ecmascript-ast which people could experiment with on V8 (and then
JSC).

ES-Harmony - or it's prototype - could be pure ES - if the translation
from the AST in ES Objects to the native AST is fast enough.
Maybe ES6 could focus on the core semantics that dev's want: lexical
vars, 'hermetic eval' etc. (And maybe syntax cleanup - eg mandatory ;
and ideas from JSLint). Then the sugar is build on the 'good bits'
'kernel' ES language/semantics.


On Wed, Dec 23, 2009 at 6:48 PM,  ihab.a...@gmail.com wrote:
 On Wed, Dec 23, 2009 at 10:45 AM, Kevin Curtis
 kevinc1...@googlemail.com wrote:
 The strawman has been updated with an 'ast' entry:
 http://wiki.ecmascript.org/doku.php?id=strawman:ast

 I did that. I needed something to point to when I said, in a separate
 (as of yet unpublished) proposal, that ${that} would be a nice thing
 to have.

 Is this something like the Python ast module:
 ast.parse() would parse ECMAScript source to an AST of ECMAScript
 objects. Could be pure ES.
 eval() would take an AST tree of ECMAScript objects. The
 implementation would walk the tree of ES objects to build the native
 C++ AST (which is then used to generate and execute code). This is how
 the Python ast module works.

 Yes, that's what I was thinking.

 Could this revised eval(|AST of ES Objects|) be an be a
 efficient/realistic target for alt-JS's/DSL's/rewriters/LINQ? It
 should be straightforward to implement. The native C++ AST remains an
 unconstrained 'artefact of the implementation' given that ast.parse()
 is pure ES.

 Yep.

 Ihab

 --
 Ihab A.B. Awad, Palo Alto, CA

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mike Samuel]

Perhaps I was using the wrong term.  The alternate expansion that uses ASTs
contains no source of non-determinism, so if the quasi handler can be proven
deterministic, then the result could be inclined during parse.

On Dec 23, 2009 2:06 PM, Kevin Curtis kevinc1...@googlemail.com wrote:

Ihab - thanks for that info.

My basic first cut of evaluating JsonML was implemented in C++ by
treewalking the ES objects and building the AST. (Not sure why i went
down the string parsing road). I could put the code into
ecmascript-ast which people could experiment with on V8 (and then
JSC).

ES-Harmony - or it's prototype - could be pure ES - if the translation
from the AST in ES Objects to the native AST is fast enough.
Maybe ES6 could focus on the core semantics that dev's want: lexical
vars, 'hermetic eval' etc. (And maybe syntax cleanup - eg mandatory ;
and ideas from JSLint). Then the sugar is build on the 'good bits'
'kernel' ES language/semantics.

On Wed, Dec 23, 2009 at 6:48 PM, ihab.a...@gmail.com wrote:  On Wed, Dec
23, 2009 at 10:45 AM,...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Kevin Curtis]

How about if the developer wants the entire script to be a DSL or an
Alt-JS (compiled in the browser)? (I appreciate this is a different
use-case).

Maybe a way for the alt-JS scanning/parsing code to be automatically
'hooked up' to an alt-JS script? For example - an alt-JS with 'classes
as sugar':

script 
type=application/ecmascript;version=6;dsl=http://www.acme.com/mydsl.js;
class Point {
var x_ = 0;
var y_ = 0;
function Point(x,y) {
x_ = x;
y_ = y;
}
... //  getters/setters etc.
}
var pt = new Point(1,1);
processPt(pt);
...
/script

mydsl.js is a 'pure module' which provides an object with scan() and
parse() functions. The compiled mydsl.js is cached for reuse by by
other pages.
Maybe a secure environment could use a similar mechanism. e.g.
env=http://www.acme.com/ses.js;. Meta tags to set DSL/env for the
whole page?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mark Seaborn]

On Tue, Dec 15, 2009 at 12:04 AM, Mike Samuel mikesam...@gmail.com wrote:
 2009/12/14 Ash Berlin ash...@firemirror.com:

  If you haven't yet read http://www.python.org/dev/peps/pep-3101/ (Advanced 
  String Formatting) I
  suggest you do - its well worth a read and feels like a possible very 
  javascripty solution.

 I have not read it.  Thanks for the link.  It has a good summary of
 alternate syntaxes and establishes a point partway between positional
 and inline syntax.  It does include a bunch of format specifiers that
 I think incompatible with DSL schemes.

Python 2.6/3.0's new format() method lets you put attribute accesses
inline in the format string, e.g.
  em{0.text}/em.format(obj)
This is problematic for secure subsets of Python such as CapPython
that try to restrict attribute access [1].  There might be similar
problems for secure subsets of ES if something like Python 3.0's
scheme were adopted in ES.

Apparently the Python developers weren't aware of quasi-literals -- or
at least quasi-literals weren't proposed -- so they weren't
considered.

It seems to me that if you really want attribute accesses inline in
the format string, it's better to have these attribute accesses as
real expressions -- as quasi-literals allow -- rather than inventing a
new mini-language for them as Python 3.0 format strings did.

Cheers,
Mark

[1] 
http://lackingrhoticity.blogspot.com/2008/09/attribute-access-in-format-strings-in.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mike Samuel]

2009/12/21 Mark Seaborn mseab...@google.com:
 On Tue, Dec 15, 2009 at 12:04 AM, Mike Samuel mikesam...@gmail.com wrote:
 2009/12/14 Ash Berlin ash...@firemirror.com:

  If you haven't yet read http://www.python.org/dev/peps/pep-3101/ (Advanced 
  String Formatting) I
  suggest you do - its well worth a read and feels like a possible very 
  javascripty solution.

 I have not read it.  Thanks for the link.  It has a good summary of
 alternate syntaxes and establishes a point partway between positional
 and inline syntax.  It does include a bunch of format specifiers that
 I think incompatible with DSL schemes.

 Python 2.6/3.0's new format() method lets you put attribute accesses
 inline in the format string, e.g.
  em{0.text}/em.format(obj)
 This is problematic for secure subsets of Python such as CapPython
 that try to restrict attribute access [1].  There might be similar
 problems for secure subsets of ES if something like Python 3.0's
 scheme were adopted in ES.

So python's format() method is not statically analyzable since it
turns strings into code, though in a more limited way than either
python's or ecmascript's eval.


 Apparently the Python developers weren't aware of quasi-literals -- or
 at least quasi-literals weren't proposed -- so they weren't
 considered.

 It seems to me that if you really want attribute accesses inline in
 the format string, it's better to have these attribute accesses as
 real expressions -- as quasi-literals allow -- rather than inventing a
 new mini-language for them as Python 3.0 format strings did.

For the quasi proposal, since the semantics are specified in terms of
a desugaring, any kind of security by analysis that holds on the
desugared form should also hold with syntactic sugar.

So any analysis that holds for
  foo('', '')(bar.baz)
should also hold for
  foo`${bar.baz}`

and the quasi proposal does not suffer from the third-party format
string problem that python suffers from.

Do the assertions about static analysis under security
considerations make sense to you?


 Cheers,
 Mark

 [1] 
 http://lackingrhoticity.blogspot.com/2008/09/attribute-access-in-format-strings-in.html
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mike Samuel]

2009/12/18 Andy Chu a...@chubot.org:
 So then my question is why it needs to specify a desugaring.  Why is a
 quasi-literal not a string?

 I still don't understand the question?

 Why `foo$bar` and not foo$bar?  Well, the latter doesn't do anything
 useful with the expression (bar).

 OK, so to back up a bit, the point of quasi-literals is to shift the
 burden of escaping from the application developer to the library
 author (e.g. authors of the DOM API).  Is that an accurate and
 reasonably complete summary?  (If it is I might suggest making safe
 string interpolation the feature name)

Safe String Interpolation is the name of a quasi scheme that I would
also like to propose.  And its goal is as you describe.


 My question is why the entire quasi-literal scheme can't be in a
 library.  In your doc you have something like:

It can be done in a library but some syntactic sugar will make it much
more usable.


 new StringInterpolation([SELECT * FROM TABLE WHERE name=', name, '
 AND modified  , new Date(d)])

 Does this variation express all of what quasi-literals can do?

Since new StringInterpolation could be defined to do anything that a
single user call can do, yes.


 var sqlStatement = new StringInterpolation(SELECT * FROM TABLE WHERE
 name=$name AND modified  $date, {name: name, date: new Date(d)})

 sqlLibrary.execute(sqlStatement)  // does autoescaping of name and date

 The syntax of the first string argument is the quasi-literal syntax in
 your doc, with $, {}, etc.

 Reasons why I ask:
 - People could use this scheme *now* if it were a library, and start
 changing their APIs to autoescape.

That's one reason to use desugaring.  People could use it now, and use
a tool that does the desugaring, as long as the library is written in
the intersection of ES5 strict and ES3.

 - Quasi-literals have a bit of a meta-problem.  You're lamenting the
 complex escaping rules of HTML (rightly), but then this proposal adds
 a third escaping mode to JS, which is probably the most
 programmatically-generated language on the planet (since it must go
 over the network).  Certainly I'm already confused by the discussions
 of escaping quasi-literals on this thread.

This shouldn't affect existing correct code generators since, if they
generate code with backquoted strings, they can't be correct.


 PHP and JSP were the gold standard when I built it, and Django and
 others have addressed that to some degree.
 Do you know of any statistics on how much PHP code is running versus
 Django code?

 I don't know, but certainly tons more PHP code.  BTW Smarty also does
 this and I think this is the most common PHP templating language now:
 http://www.smarty.net/manual/en/language.modifier.escape.php
 (I don't understand why a templating language needs a templating
 language, but I'll never understand PHP I suppose)

I think it's partly because people want to piece-wise migrate away
from PHP's easy-to-write-almost-correct-code,
very-hard-to-write-correct-code string interpolation scheme.

 I think the quasi-literals are a cool idea -- but they're also a
 pretty large innovation.  This scheme is not used by production
 library or language that I know of.  The point being that innovation
 in standards has the problems that Douglas Crockford has spoken about.

I absolutely agree and I'm not proposing we innovate in the standard.
That's why I hoped to standardize on a simple desugaring that is
syntactically familiar to users of existing languages, and that will
allow experimentation by library authors who, as you point out, have
the best track record of successful innovation.

 This would shift the boundaries between JavaScript and the DOM, and
 make them an anomaly among literally hundreds of other
 libraries/languages.  Template languages are a well known commodity by
 now.

I don't understand what you mean by shifting the boundaries.  Strings
are not the de facto standard for moving data across module
boundaries.  There are many languages that pass around structured
content.

 I would also say that the biggest boundary is actually getting people
 to write auto-escaping.

I'm not sure I understand.  I never said I wanted a bunch of people
writing auto-escaping code.  It needs to be done by at least one
library.
As for clients, many people write templates using a variety of
syntaxes.  The auto in auto-escaping means they just have to do in
JS what they now do in other languages.

 It's not the lack of syntax in the JS language.

I disagree.  I find it much easier to knock out code in perl or PHP
that is almost right.


 I didn't study the end of your doc, but it certainly isn't
 a simple problem for someone to write HTML autoescaping.  Considering
 how much HTML is malformed out there, I don't see how there won't be
 holes 0.1% or 0.01% of the time due to heuristics.

I believe I can demonstrate that it is that simple, but that is out of
scope for this thread.
If we can reduce XSS, the single largest source of vulnerabilities in

Re: quasi-literal strawman

[Mike Samuel]

Oh, and on the integration with document.write and innerHTML and the
like, I was not going to ask the W3C to recognize a particular library
or object type, the proposal was going to look like:

Currently document.write coerces its arguments to strings.  Change
that so that if the input is non-primitive, invoke toString passing
the name of the current insertion mode as defined in
http://www.w3.org/TR/html5/syntax.html#insertion-mode and similarly
for innerHTML.

So
   tabletrscript
   document.write(foo);
   /script/tr/table
would end up calling foo.toString(in row) and coercing the result to
a string, and
   myTextArea.innerHTML = bar
would end up calling bar.toString(in RAWTEXT/RCDATA) and coercing
the result to a string to get the actual innerHTML.

So I think the separation between library logic and standards is
pretty well-defined for both proposals.

I still have to write that up though.





2009/12/19 Mike Samuel mikesam...@gmail.com:
 2009/12/18 Andy Chu a...@chubot.org:
 So then my question is why it needs to specify a desugaring.  Why is a
 quasi-literal not a string?

 I still don't understand the question?

 Why `foo$bar` and not foo$bar?  Well, the latter doesn't do anything
 useful with the expression (bar).

 OK, so to back up a bit, the point of quasi-literals is to shift the
 burden of escaping from the application developer to the library
 author (e.g. authors of the DOM API).  Is that an accurate and
 reasonably complete summary?  (If it is I might suggest making safe
 string interpolation the feature name)

 Safe String Interpolation is the name of a quasi scheme that I would
 also like to propose.  And its goal is as you describe.


 My question is why the entire quasi-literal scheme can't be in a
 library.  In your doc you have something like:

 It can be done in a library but some syntactic sugar will make it much
 more usable.


 new StringInterpolation([SELECT * FROM TABLE WHERE name=', name, '
 AND modified  , new Date(d)])

 Does this variation express all of what quasi-literals can do?

 Since new StringInterpolation could be defined to do anything that a
 single user call can do, yes.


 var sqlStatement = new StringInterpolation(SELECT * FROM TABLE WHERE
 name=$name AND modified  $date, {name: name, date: new Date(d)})

 sqlLibrary.execute(sqlStatement)  // does autoescaping of name and date

 The syntax of the first string argument is the quasi-literal syntax in
 your doc, with $, {}, etc.

 Reasons why I ask:
 - People could use this scheme *now* if it were a library, and start
 changing their APIs to autoescape.

 That's one reason to use desugaring.  People could use it now, and use
 a tool that does the desugaring, as long as the library is written in
 the intersection of ES5 strict and ES3.

 - Quasi-literals have a bit of a meta-problem.  You're lamenting the
 complex escaping rules of HTML (rightly), but then this proposal adds
 a third escaping mode to JS, which is probably the most
 programmatically-generated language on the planet (since it must go
 over the network).  Certainly I'm already confused by the discussions
 of escaping quasi-literals on this thread.

 This shouldn't affect existing correct code generators since, if they
 generate code with backquoted strings, they can't be correct.


 PHP and JSP were the gold standard when I built it, and Django and
 others have addressed that to some degree.
 Do you know of any statistics on how much PHP code is running versus
 Django code?

 I don't know, but certainly tons more PHP code.  BTW Smarty also does
 this and I think this is the most common PHP templating language now:
 http://www.smarty.net/manual/en/language.modifier.escape.php
 (I don't understand why a templating language needs a templating
 language, but I'll never understand PHP I suppose)

 I think it's partly because people want to piece-wise migrate away
 from PHP's easy-to-write-almost-correct-code,
 very-hard-to-write-correct-code string interpolation scheme.

 I think the quasi-literals are a cool idea -- but they're also a
 pretty large innovation.  This scheme is not used by production
 library or language that I know of.  The point being that innovation
 in standards has the problems that Douglas Crockford has spoken about.

 I absolutely agree and I'm not proposing we innovate in the standard.
 That's why I hoped to standardize on a simple desugaring that is
 syntactically familiar to users of existing languages, and that will
 allow experimentation by library authors who, as you point out, have
 the best track record of successful innovation.

 This would shift the boundaries between JavaScript and the DOM, and
 make them an anomaly among literally hundreds of other
 libraries/languages.  Template languages are a well known commodity by
 now.

 I don't understand what you mean by shifting the boundaries.  Strings
 are not the de facto standard for moving data across module
 boundaries.  There are many languages that pass around structured
 

Re: quasi-literal strawman

[Mike Samuel]

2009/12/14 Mike Samuel mikesam...@gmail.com:
 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.

http://wiki.ecmascript.org/doku.php?id=strawman:quasis is now a proper
wiki page.

 cheers,
 mike

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mike Samuel]

2009/12/17 Brendan Eich bren...@mozilla.com:
 On Dec 17, 2009, at 8:15 PM, Mike Samuel wrote:

 That's the case right now, except that to escape a backtick one does
 $\`  instead of \`.

 How about just $` instead?

The idea was to have raw strings *and* a way to include arbitrary
codepoints without having to put non-ascii text in a file.
So $\EscapeSequence is interpreted as the CV of the EscapeSequence.

The sequence $` does not have a meaning right now though so that could
be done either in-addition to or instead of $\ style escapes.
Though, the sequence $\$` encodes the two character string $`.


 /be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mark S. Miller]

On Fri, Dec 18, 2009 at 2:29 PM, Mike Samuel mikesam...@gmail.com wrote:

 2009/12/17 Brendan Eich bren...@mozilla.com:
  On Dec 17, 2009, at 8:15 PM, Mike Samuel wrote:
 
  That's the case right now, except that to escape a backtick one does
  $\`  instead of \`.
 
  How about just $` instead?

 The idea was to have raw strings *and* a way to include arbitrary
 codepoints without having to put non-ascii text in a file.
 So $\EscapeSequence is interpreted as the CV of the EscapeSequence.

 The sequence $` does not have a meaning right now though so that could
 be done either in-addition to or instead of $\ style escapes.
 Though, the sequence $\$` encodes the two character string $`.


What? I was following the rest, but I don't get the last line. Since the
second $ is $\-escaped, it is simply a literal $, so the following ` is not
escaped and should end the quasiliteral. Am I confused?



  /be
 




-- 
   Cheers,
   --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Andy Chu]

 So then my question is why it needs to specify a desugaring.  Why is a
 quasi-literal not a string?

 I still don't understand the question?

 Why `foo$bar` and not foo$bar?  Well, the latter doesn't do anything
 useful with the expression (bar).

OK, so to back up a bit, the point of quasi-literals is to shift the
burden of escaping from the application developer to the library
author (e.g. authors of the DOM API).  Is that an accurate and
reasonably complete summary?  (If it is I might suggest making safe
string interpolation the feature name)

My question is why the entire quasi-literal scheme can't be in a
library.  In your doc you have something like:

new StringInterpolation([SELECT * FROM TABLE WHERE name=', name, '
AND modified  , new Date(d)])

Does this variation express all of what quasi-literals can do?

var sqlStatement = new StringInterpolation(SELECT * FROM TABLE WHERE
name=$name AND modified  $date, {name: name, date: new Date(d)})

sqlLibrary.execute(sqlStatement)  // does autoescaping of name and date

The syntax of the first string argument is the quasi-literal syntax in
your doc, with $, {}, etc.

Reasons why I ask:
- People could use this scheme *now* if it were a library, and start
changing their APIs to autoescape.
- Quasi-literals have a bit of a meta-problem.  You're lamenting the
complex escaping rules of HTML (rightly), but then this proposal adds
a third escaping mode to JS, which is probably the most
programmatically-generated language on the planet (since it must go
over the network).  Certainly I'm already confused by the discussions
of escaping quasi-literals on this thread.

 PHP and JSP were the gold standard when I built it, and Django and
 others have addressed that to some degree.
 Do you know of any statistics on how much PHP code is running versus
 Django code?

I don't know, but certainly tons more PHP code.  BTW Smarty also does
this and I think this is the most common PHP templating language now:
http://www.smarty.net/manual/en/language.modifier.escape.php
(I don't understand why a templating language needs a templating
language, but I'll never understand PHP I suppose)

I think the quasi-literals are a cool idea -- but they're also a
pretty large innovation.  This scheme is not used by production
library or language that I know of.  The point being that innovation
in standards has the problems that Douglas Crockford has spoken about.

This would shift the boundaries between JavaScript and the DOM, and
make them an anomaly among literally hundreds of other
libraries/languages.  Template languages are a well known commodity by
now.

I would also say that the biggest boundary is actually getting people
to write auto-escaping.  It's not the lack of syntax in the JS
language.  I didn't study the end of your doc, but it certainly isn't
a simple problem for someone to write HTML autoescaping.  Considering
how much HTML is malformed out there, I don't see how there won't be
holes 0.1% or 0.01% of the time due to heuristics.  I would rather use
my templating language and the equivalent of auto-escaping via static
analysis to get it 100% right (since a static analysis tool can issue
warnings where there is ambiguity and a human applies their judgement,
to fix their code before it has to run).

JSON Template is trivially tokenizable for this reason: \{.*?\} (or
e.g. \[.*?\] depending on the delimiter) splits it into literals and
substitutions.  Then you can put the work into autoescaping rather
than parsing the template language (which always sucks because of
escaping!).

 What is locals()?  Why does expandTemplate need access to all locals
 to do its job instead of just the specified ones?
 Does this suffer from the formatting string from untrusted source
 problem that python suffers from, and the substitution value from
 untrusted source problem?

That was just a shorthand to get around the verbosity of passing in
{name: name, date: date}, and also specifying name and date in the
quasi-literal string.  It's not strictly necessary.

Not saying that quasi-literals won't work, but things to consider.
It's an ambitious solution and it would be cool if we can forget about
escaping as application developers, but I see more than a few
obstacles.

I think an existing library would help firm it up... I was thinking of
writing a mini-template.js that implements almost exactly what Python
3k string formatting does.  This is a hole in the feature set of
JavaScript, irrespective of security and escaping.  I think a default
.format() method on strings would go a long way, rather than the
current foo  + var +  bar idiom.  Perhaps there could be a hook
for autoescaping, but it may be tricky.

Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Andy Chu]

 That a lot of formatting can be done in-library is a great point.

 Hopefully, by providing a desugaring that can easily be back-ported to
 older code by things like rewriting minifiers, and implementing most
 of the feature in library code that will run on older versions of JS;
 we can allow people to use and experiment with
 formatting/interpolation schemes even in code that needs to run on
 legacy interpreters.

Right, I like the idea of being able to run in ES3.1/5 implementations
(at the cost of speed).

 The quasi-literal proposal specifies only a desugaring, and the safe
 interpolation scheme that I want to do is not part of this proposal
 and would be done in a library.  I hope to convince W3C that this
 library is something worth standardizing on and that innerHTML,
 document.write, cssText, and other language encoding entry points into
 the DOM internals should be aware of it.

So then my question is why it needs to specify a desugaring.  Why is a
quasi-literal not a string?  What is typeof html`foo`?  Is it
function?

Can you elaborate on the relationship to the DOM?  I didn't see it in
the doc.  So you're saying that innerHTML can be set to a
quasi-literal now, in addition to a string?  I don't see the situation
where you can't just expand the quasi-literal to a string and then set
innerHTML.

I think some more example applications in the doc would help.  Right
now I don't see much difference between quasi-literals and a template
language as a library, but I may be missing something.


 This scheme could be built on top of quasis with a minor syntactic change.

 jsont`{$name:html}: a
 href={$url|html-attr-value}{$anchor|html}/a{default=html}`

 function jsont(var_args) {
  var literalPortions = Array.prototype.slice.call(arguments, 0);
  var escapingModes = [];

Interesting, this API is not that unlike JSON Template's API.  I'm not
sure I see a big difference in functionality or safety either way.

I would argue with this statement from your doc: First, full blown
templating languages, with a few exceptions, do next to nothing to
solve escaping problems.

This is probably true of PHP and JSP, but more modern template
languages have formatters/filters built in.  Django,
google-ctemplate, and JSON Template have this.  When combined with an
option for a default filter, this solves escaping AFAICT.  Do
quasi-literals do it better?  You are making a early/late binding
argument, but I don't see when this becomes necessary.

If it is because variables come from the calling scope rather than the
scope receiving the quasi-literal, then let me propose just using
something like locals() in Python.

def foo():
  a = 1
  s = expandTemplate({a}, locals())

Now expandTemplate receives the argument {a: 1} and can return the string 1.


 I like the idea of enabling DSLs, but I feel like this proposal is a
 DSL itself, rather than enabling them, since it has a fairly
 particular syntax, and you have defined the parse tree very
 specifically.

 I'm not sure I follow.  Are you referring to the `...` syntax with
 embedded $foo and ${expression} chunks?

Yes, I don't see why this should be hard-coded in the language.  It's
a third set of escaping rules to learn (strings and regexes being the
first 2, and actually regexes have a fourth set -- inside character
classes [^$] and outside).

I also think the syntax is complicated ( \${}` are special, as opposed
to strings where \ are special, and regexes where / is special).  I
wouldn't be at all surprised if it needs to grow based on some new use
cases.

For substitution, let me plug the JSON Template scheme: {foo} is a
substituion.  If the string contains {}, then choose [] as the
metacharacters: Template([foo], meta=[]).  So the default
meta={}.

That's it.  IMHO this is the simplest possible scheme that covers all
applications.  Any character you pick will be suboptimal for some DSL
-- in particular quasi-literals themselves.  How do you write a
quasi-literal for quasi-literals?  My guess is it will look pretty
nasty.

I don't see why the metadata needs to be inside the quasi-literal, as
opposed to just being another argument to a function that takes a
quasi-literal.

 Another Python analogy is that they chose not to embed regex's in the
 language, unlike JavaScript/Perl/Ruby.  Instead there is a very
 minimal syntactic accomodation -- raw strings which don't have
 backslash escaping.  The Go language takes this same approach with
 backticks I believe (e.g. `\s+` and not \\s+).

 This proposal gets you raw strings easily :)

 new RegExp(r`\s+foo\s+`, 'i')

 function r(string) {
  if (arguments.length != 1) { throw new Error(); }
  return function () { return string; };  // Trivially inlinable
 }

I view the /\s+/ syntax for regexes as superfluous and overly
specific, so if this mechanism can somehow generalize that and retire
the old syntax, that's a plus.

 I do think JavaScript really needs better string interpolation than
 foo  + var +  bar, which unfortunately a 

Re: quasi-literal strawman

[Mike Samuel]

2009/12/17 Andy Chu a...@chubot.org:
 That a lot of formatting can be done in-library is a great point.

 Hopefully, by providing a desugaring that can easily be back-ported to
 older code by things like rewriting minifiers, and implementing most
 of the feature in library code that will run on older versions of JS;
 we can allow people to use and experiment with
 formatting/interpolation schemes even in code that needs to run on
 legacy interpreters.

 Right, I like the idea of being able to run in ES3.1/5 implementations
 (at the cost of speed).

 The quasi-literal proposal specifies only a desugaring, and the safe
 interpolation scheme that I want to do is not part of this proposal
 and would be done in a library.  I hope to convince W3C that this
 library is something worth standardizing on and that innerHTML,
 document.write, cssText, and other language encoding entry points into
 the DOM internals should be aware of it.

 So then my question is why it needs to specify a desugaring.  Why is a
 quasi-literal not a string?

I still don't understand the question?

Why `foo$bar` and not foo$bar?  Well, the latter doesn't do anything
useful with the expression (bar).


 What is typeof html`foo`?  Is it function?

html hasn't been defined.
In 
http://google-caja.googlecode.com/svn/changes/mikesamuel/string-interpolation-29-Jan-2008/trunk/src/js/com/google/caja/interp/index.html
the result of the interpolation is an Interpolation object instance.
So it's typeof would be object.


 Can you elaborate on the relationship to the DOM?  I didn't see it in
 the doc.  So you're saying that innerHTML can be set to a
 quasi-literal now, in addition to a string?  I don't see the situation
 where you can't just expand the quasi-literal to a string and then set
 innerHTML.

Please see the arguments in
http://google-caja.googlecode.com/svn/changes/mikesamuel/string-interpolation-29-Jan-2008/trunk/src/js/com/google/caja/interp/index.html
as to why.  The short answer is that you do not know at the time the
interpolation happens what context it will be used in -- you don't
know whether it is going to be used as HTML, CSS, or SQL.

a_STYLE_element.innerHTML = ...;
would behave very differently from
a_DIV_element.innerHTML = ...;
which would behave still differently from
a_TEXTAREA_element.innerHTML = ...;

 I think some more example applications in the doc would help.  Right
 now I don't see much difference between quasi-literals and a template
 language as a library, but I may be missing something.

The details of HTML escaping are largely orthogonal to this doc.  That
string interpolation doc I linked to above could probably use more
examples.  It does address competing use cases for template languages
and string interpolation a bit though.


 This scheme could be built on top of quasis with a minor syntactic change.

 jsont`{$name:html}: a
 href={$url|html-attr-value}{$anchor|html}/a{default=html}`

 function jsont(var_args) {
  var literalPortions = Array.prototype.slice.call(arguments, 0);
  var escapingModes = [];

 Interesting, this API is not that unlike JSON Template's API.  I'm not
 sure I see a big difference in functionality or safety either way.

 I would argue with this statement from your doc: First, full blown
 templating languages, with a few exceptions, do next to nothing to
 solve escaping problems.

 This is probably true of PHP and JSP, but more modern template
 languages have formatters/filters built in.  Django,
 google-ctemplate, and JSON Template have this.  When combined with an
 option for a default filter, this solves escaping AFAICT.  Do
 quasi-literals do it better?  You are making a early/late binding
 argument, but I don't see when this becomes necessary.

PHP and JSP were the gold standard when I built it, and Django and
others have addressed that to some degree.
Do you know of any statistics on how much PHP code is running versus
Django code?

PHP has perfectly good escaping functions.  People just don't use them
consistently.  Django et al are a bit nicer in that they make it more
convenient than PHP does to do the right thing.  But I'm still
skeptical of manually chosen escaping convention because I think
they're error prone, and impose a large maintenance burden -- if I
have b{foo}/b and foo changes from being a plain text string to
a bit of markup generated elsewhere in the code, the system will now
overescape.  Overescaping is much more quickly visible during testing
than underescaping, so these manual schemes for specifying escaping
conventions tend to grow holes over time.  Developers will remove
escaping because they were trying to fix a bug that was actually the
result of something else.  And it fundamentally does the wrong thing
with heterogenous inputs ; what is the appropriate convention in (foo
= someCondition ? wellFormedHtmlFromTrustedSource :
plainTextFromUntrustedSource, b{foo}/b)?  Manual escaping
syntactic sugar does not solve this problem, and late binding does.

See the 

Re: quasi-literal strawman

[Kris Kowal]

I am also in favor of the quasi-literal type name not being mangled.
I would, in fact, consider making the quasi-literal type any
expression returning a function, even if this necessitates a
parenthetical expression.

You might consider refining the escaping rules to resemble rraw
strings as in Python.  That would afford a greater degree of
flexibility in escaping rules within the quasi-literal.  The only
difference is that in a raw string, only backslash before the same
quote character as the enclosing quotes and a backslash are treated as
escape characters and all others are preserved.  Then, the
quasi-literal function would be entirely in control of the meaning of
other escaped characters.

There's also a trade-off between using back-ticks and plain
double-quotes.  Using back-ticks affords us an opportunity to have a
default quasi-literal.  On the other hand, I don't miss having to
distinguish front and back ticks in Perl.  Also, it might be
undesirable to have to claim a variable name for the default case,
unless your intention is that the default quasi-literal have a
consistent behavior in any scope.

In one of my former language projects, I considered something similar
for numbers, in suffix.  For example: 3ce for thrice or 1mm for one
millimeter, where ce and mm were constructors in scope.

Kris Kowal
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mike Samuel]

2009/12/17 Kris Kowal kris.ko...@cixar.com:
 I am also in favor of the quasi-literal type name not being mangled.
 I would, in fact, consider making the quasi-literal type any
 expression returning a function, even if this necessitates a
 parenthetical expression.

Cool.

 You might consider refining the escaping rules to resemble rraw
 strings as in Python.  That would afford a greater degree of
 flexibility in escaping rules within the quasi-literal.  The only
 difference is that in a raw string, only backslash before the same
 quote character as the enclosing quotes and a backslash are treated as
 escape characters and all others are preserved.  Then, the
 quasi-literal function would be entirely in control of the meaning of
 other escaped characters.

That's the case right now, except that to escape a backtick one does
$\`  instead of \`.


 There's also a trade-off between using back-ticks and plain
 double-quotes.  Using back-ticks affords us an opportunity to have a
 default quasi-literal.  On the other hand, I don't miss having to
 distinguish front and back ticks in Perl.  Also, it might be
 undesirable to have to claim a variable name for the default case,
 unless your intention is that the default quasi-literal have a
 consistent behavior in any scope.

So is this a vote for a mandatory type tag followed by normal quote
syntax (the second alternative under Quoting Characters), so
   foobar   is a quasi string

   baris not a quasi string

   foo\
   baris a quasi string

   foo
   baris not a quasi string


If there is a default quasi function, do you have any preference re its name?



 In one of my former language projects, I considered something similar
 for numbers, in suffix.  For example: 3ce for thrice or 1mm for one
 millimeter, where ce and mm were constructors in scope.

I think C++0x has something along those lines:
http://en.wikipedia.org/wiki/C%2B%2B0x#User-defined_literals


 Kris Kowal

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Brendan Eich]

On Dec 17, 2009, at 8:15 PM, Mike Samuel wrote:


That's the case right now, except that to escape a backtick one does
$\`  instead of \`.


How about just $` instead?

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Ash Berlin]

On 16 Dec 2009, at 20:21, Mike Samuel wrote:

 jsont`{$name:html}: a
 href={$url|html-attr-value}{$anchor|html}/a{default=html}`
 
 function jsont(var_args) {
  var literalPortions = Array.prototype.slice.call(arguments, 0);


So if i remember correctly:

foo`a${b}c` - foo(a, c')(b);

How then are these treated:

foo`a${b}${d}c`
foo`a${b}c${d}`


-ash
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mark S. Miller]

On Wed, Dec 16, 2009 at 12:43 PM, Ash Berlin ash...@firemirror.com wrote:


 On 16 Dec 2009, at 20:21, Mike Samuel wrote:

  jsont`{$name:html}: a
  href={$url|html-attr-value}{$anchor|html}/a{default=html}`
 
  function jsont(var_args) {
   var literalPortions = Array.prototype.slice.call(arguments, 0);


 So if i remember correctly:

 foo`a${b}c` - foo(a, c')(b);

 How then are these treated:

 foo`a${b}${d}c`


foo(a,,c)(b,d)


 foo`a${b}c${d}`


foo(a,c,)(b,d)



 -ash
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




-- 
   Cheers,
   --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Brendan Eich]

On Dec 14, 2009, at 3:34 PM, Ash Berlin wrote:


On 14 Dec 2009, at 22:44, Mike Samuel wrote:

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.


+∞

The solution is to canonicalize platform-dependent CRLF or CR into LF  
only. See


http://wiki.ecmascript.org/doku.php?id=proposals:line_terminator_normalization

(from ES4, but still relevant and reusable AFAICT).

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Tom Van Cutsem]

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%3Aquasiscache=cachemedia=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 mikesam...@gmail.com wrote:

 2009/12/14 Dean Landolt d...@deanlandolt.com:
 
 
  On Mon, Dec 14, 2009 at 7:04 PM, Mike Samuel mikesam...@gmail.com
 wrote:
 
  2009/12/14 Ash Berlin ash...@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]
 

Re: quasi-literal strawman

[Mike Samuel]

2009/12/15 Brendan Eich bren...@mozilla.com:
 On Dec 14, 2009, at 3:34 PM, Ash Berlin wrote:

 On 14 Dec 2009, at 22:44, Mike Samuel wrote:

 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.

 +∞

Ok, current count is (for: ∞ + 1, against 0, not voted: ~6B).

 The solution is to canonicalize platform-dependent CRLF or CR into LF only.
 See

 http://wiki.ecmascript.org/doku.php?id=proposals:line_terminator_normalization

 (from ES4, but still relevant and reusable AFAICT).

This proposal is compatible with that:
* The LPA of LiteralCharacter :: LineTerminatorSequence is
  the single character string containing a LF (\n).


 /be
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mike Samuel]

2009/12/15 Tom Van Cutsem to...@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 mikesam...@gmail.com wrote:

 2009/12/14 Dean Landolt d...@deanlandolt.com:
 
 
  On Mon, Dec 14, 2009 at 7:04 PM, Mike Samuel mikesam...@gmail.com
  wrote:
 
  2009/12/14 Ash Berlin ash...@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 

Re: quasi-literal strawman

[David-Sarah Hopwood]

Mike Samuel wrote:
 2009/12/15 Tom Van Cutsem to...@google.com:
 Hi,

 Could you motivate why you chose to append the string Quasi to the type
 tag 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 with Tom on this. I've always thought E's mangling of the tag is ugly.
(Note that one possible reason for doing that in E -- the fact that there
are other namespaces that work in a similar way such as *__uriGetter --
does not apply to ECMAScript.)

 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`...`;

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

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com



signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mark S. Miller]

On Tue, Dec 15, 2009 at 12:40 PM, Mike Samuel mikesam...@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.

-- 
   Cheers,
   --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Ash Berlin]

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

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)

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.

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.

If you haven't yet read http://www.python.org/dev/peps/pep-3101/ (Advanced 
String Formatting) I suggest you do - its well worth a read and feels like a 
possible very javascripty solution.

One thing I'm not seeing here is a way to interpolate one quasi literal inside 
another one. I'm guessing the intent is html`h1$x/h1` would html escape the 
x variable (this wasn't actually explicitly stated anywhere that I read). But 
how do you say 'x is already html, don't escape it again?' I guess this comes 
down to how do you detect and interact with quasi-literals? Do they have a new 
typeof? What methods do the instances have? How exactly to you write new quasi 
tags/types?

I can understand not having printf style formatting codes, but how would you 
suggest you format a number to 2 decimal places?

In summary:
* Quasi-Literal or string interpolation strawman? whats what?
* How do you interact with literals (in more detail)
* What quasi types would be built in?
* I would *really* like multiline literals. (akin to pythons  operator or 
heredocs in perl and ruby)
* The metadata example - there is no other mention to metadata
* I'm not sure its worth allowing such complex expressions inside the ${} 
(brackets example)
* No printf/formatting at all might be missed

Thanks for fleshing this out in more detail - I've been meaning to write an 
email about the lack of detail in the string interpolation strawman for a 
couple of weeks.

-ash

[1]: http://wiki.ecmascript.org/doku.php?id=strawman:string_interpolation
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mike Samuel]

2009/12/14 Ash Berlin ash...@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 :)


 If you haven't yet read http://www.python.org/dev/peps/pep-3101/ (Advanced 
 String Formatting) I suggest you do - its well worth a read and feels like a 
 possible very javascripty solution.

I have not read it.  Thanks for the link.  It has a good summary of
alternate syntaxes and establishes a point partway between positional
and inline syntax.  It does include a bunch of format specifiers that
I think incompatible with DSL schemes.

 One thing I'm not seeing here is a way to interpolate one quasi literal 
 inside another one. I'm guessing the intent is html`h1$x/h1` would html 
 escape the x variable (this wasn't actually explicitly stated anywhere that I 
 read). But how do you say 'x is already html, don't escape it again?' I guess 
 this comes down to how do you detect and interact with quasi-literals? Do 
 they have a new typeof? What methods do the instances have? How exactly to 
 you write new quasi tags/types?

Not quite.  The same secure string interpolation scheme paper covers this issue.



 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`

 In summary:
 * Quasi-Literal or string interpolation strawman? whats what?

A general desugaring that supports a variety of content generation
schemes including the quasi-proposal and the secure string
interpolation proposals linked under references, and hopefully allow
experimentation with DSLs.

 * How do you interact with literals (in more detail)

I'm not sure I understand the question.

 * What quasi types would be built in?

I think HTML/CSS/JS should be built into a new version of DOM.  And a
SQL version might be built into a new version of HTML5 persistence.
I'm not sure that any need to be built into Ecmascript.

 * I would *really* like multiline literals. (akin to pythons  operator or 
 heredocs in perl and ruby)

That seems orthogonal to this proposal, though this strawman does try
to make sure that such changes won't change the meaning of programs
that use quasis but not python triple quoted strings or heredoc.


 * The metadata example - there is no other mention to metadata

The motivation there 

Re: quasi-literal strawman

[Dean Landolt]

On Mon, Dec 14, 2009 at 7:04 PM, Mike Samuel mikesam...@gmail.com wrote:

 2009/12/14 Ash Berlin ash...@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.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mike Samuel]

2009/12/14 Dean Landolt d...@deanlandolt.com:


 On Mon, Dec 14, 2009 at 7:04 PM, Mike Samuel mikesam...@gmail.com wrote:

 2009/12/14 Ash Berlin ash...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss