Re: Spawn proposal strawman

[Eugene Lazutkin]

I think JsonML (with []) is perfect:

- it doesn't introduce new concepts like the other proposal
- working with it doesn't require new APIs
- it is simple but not more restrictive than the other proposal
- we can add new "tokens" if we need to without introducing new objects/APIs

Given these positives and the lack of notable negatives I give +1 for
JsonML. If we need more user-friendly facade we can always implement it
with a library that uses JsonML-based facilities under the hood.

Eugene Lazutkin
Dojo Toolkit, Committer
http://lazutkin.com/

On 05/12/2009 02:31 AM, Brendan Eich wrote:
> On May 12, 2009, at 12:24 AM, kevin curtis wrote:
> 
>> JsonML looks good for for an AST handling:
>>
>> ["||",
>>   ["||",
>> ["Id", "X"],
>> ["Id", "Y"]],
>>   ["Id", "Z"]]
> 
> Yes.
> 
> 
>> Maybe the 'canonical' AST serialized string format could actually be
>> more scheme-y:
>>
>> (or (or X Y) Z)
>>
>> JsonML could be used for building pure js in-memory AST graphs which
>> could then be easily stringified to the 'canonical' format.
> 
> JsonML wouldn't be used to build object graphs -- the JSON decoder would
> do that given JsonML in a string, from the AST encoder. That's the point
> I made in the words you bottom-cite about not mandating a big fat object
> graph if the use-case doesn't need the graph, just the string containing
> the AST serialization.
> 
> 
>> The benefit is that a scheme-y format could help the thinking on the
>> semantics for es6/harmony.
> 
> That seems like no benefit in memory use or cycles, only in thinking. If
> you squint, don't the []s turn into ()s? :-P
> 
> 
>> (Downside compared to a JSON  canonical format is that with JSON the
>> parsing/stringifying is free via the JSON api in es5).
> 
> This is a big downside.
> 
> 
>> For convenience JSON could remain JSON in this scheme-y format:
>> var x = [1,4,5]
>> becomes:
>> (var x [1,4,5])
> 
> I don't see why we'd invent a third language.
> 
> /be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Spawn proposal strawman

[Eugene Lazutkin]

+1 from me too. AST + tools (compile JS to AST, get AST from a function
object, produce a function object from AST, simple AST manipulations,
and so on) will help us (JS developers) tremendously by reducing the
existing hackery, and increasing the performance, while clearing the
road for the various meta-programming techniques.

Eugene Lazutkin
Dojo Toolkit, Committer
http://lazutkin.com/

On 05/09/2009 11:19 AM, David-Sarah Hopwood wrote:
> kevin curtis wrote:
>> Re:
>> eval.hermetic(program :(string | AST), thisValue, optBindings) :any
>>
>> Is a 'canonical' AST part of the plans for ecmascript 6/harmony.
> 
> I hope so; that would be extremely useful. I would like to see an
> ECMAScript source -> AST parser (as well as an AST evaluator) in the
> Harmony standard library.
> 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Basic Lambdas and Explicit Tail Calls Repackaged

[Eugene Lazutkin]

I agree with you: lambdas in 
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas look useless 
too. They don't have a clearly articulated vision nor compelling use 
cases (at least not in the document).


I am for the lambda facility as a short notation for small functional 
snippets, but both proposals do nothing for this use case. So far it all 
looks like "lambdas are cool --- we can do lambdas too!" kind of exercise.


Thanks,

Eugene


Michael Day wrote:

Hi Eugene,

Is your lambda proposal competing with 
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas (gave me by 
Brendon)?


It is a different proposal, I think it helps to have more than one 
proposal, in order to clearly see the different trade offs involved.


Why would anybody want to use a lambda instead of a function? 2 
characters less to type? What is the compelling reason, the super idea 
behind the lambda besides confusing programmers, and more things to 
implement by compiler writers?


Well, that's a really good question, as lambdas don't sound sufficiently 
different to regular functions in this proposal to be worth doing.


The lambda proposal on the wiki gives the following "Why" reasons:

"A simpler primitive underlying the language’s first-class functions."

Removing 'this' and 'arguments' also gives a simpler primitive, but is 
it enough to bother with?


"Supports defining other features via desugaring without breaking 
equivalence with implicit features (arguments, this, return) — this is 
sometimes described as Tennent’s Correspondence Principle [ 1, 2 ]."


Not clear what this means, or what benefit it brings to either 
JavaScript programmers or implementors.


"A well-tested feature of programming languages since time immemorial."

JavaScript already has higher-order functions, and much fewer languages 
have lambdas where a return returns from the enclosing function.


"Supports tail calls more naturally than function."

I don't see what's unnatural about explicit tail calls in functions.

"Simple, composable features like lambda are useful for other language 
features defined via desugaring/compiling other languages to ES/macros"


What do lambdas in the wiki have that lambdas-as-functions-without-this 
do not have? They seem to have more complexity, but I can't see how they 
are significantly more useful.


Best regards,

Michael


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

Re: Basic Lambdas and Explicit Tail Calls Repackaged

[Eugene Lazutkin]

Is your lambda proposal competing with 
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas (gave me by 
Brendon)?


Another question: the only difference between lambda and function is:

// pseudo code
this = undefined;
delete arguments;

Why would anybody want to use a lambda instead of a function? 2 
characters less to type? What is the compelling reason, the super idea 
behind the lambda besides confusing programmers, and more things to 
implement by compiler writers?


Thanks,

Eugene

Michael Day wrote:

Hi,

I thought it might be good to package these two proposals together, as 
they are interrelated.


It would be very much appreciated if anyone could point out major use 
cases that these proposals don't cover, or any other important issues 
that they might currently neglect.


BASIC LAMBDAS

Lambdas are similar to functions, but use the "lambda" keyword instead 
of "function", always have a "this" value of "undefined", and do not 
have an "arguments" object in scope.


LAMBDA EXAMPLES:

var x = lambda(n) { return n + 1 }

var x = lambda fact(n) {
if (n <= 1)
return 1;
else
return n * fact(n-1);
};

EXPLICIT TAIL CALLS

The JavaScript specification should require implementations to
treat any ReturnStatement containing a CallExpression as a tail call, 
except in cases when the ReturnStatement is within a WithStatement or 
within a TryStatement.


TAIL CALL EXAMPLES:

function f()
{
return g(); // <-- tail call!
}

function f()
{
g(); // <-- not a tail call, no "return" keyword
}

function f(x)
{
with (x)
{
return g(); // <-- not a tail call, inside with
}
}

ADVANTAGE: Very easy to specify and very easy to implement.

It does not require tail calls for CallExpressions which occur outside
of a ReturnStatement, eliminating a big chunk of specification devoted
to figuring out exactly what is or isn't a tail call position.

It does not require scanning through a function to identify tail
positions, so even the most basic interpreter operating directly on
abstract syntax trees could still implement them easily.

ADVANTAGE: It makes tail calls explicit.

Using "return f()" is as close as you can get to introducing a new
keyword, without introducing a new keyword. It makes it immediately
obvious whether a call is a tail call or not. EIBTI.

ADVANTAGE: Explicit tail calls preserve correctness.

The only point of requiring tail call optimisation rather than leaving
it optional is because the correctness of some code depends upon it.
However, implicit tail calls are easily lost as code changes. Consider a
tail call within a deeply nested block:

function f()
{
if (cond)
{
if (cond)
{
...
g(); // <-- supposed to be a tail call, but is it?
}
}

minorCleanup(); // <-- oh no! someone added this!
}

If tail calls use an explicit return, it is much harder to accidentally
break them, or overlook them. If tail calls are essential to ensure the
correctness of some code, they should be explicit in that code.

NOTE: Does not preclude fancier optimisations.

Implementations would be required to treat return calls as tail calls.
However, they would be free to treat other calls as tail calls as well,
or perform more complex optimisations such as introducing accumulator
arguments to transform code into tail-recursive form.

Best regards,

Michael


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

Re: Allen's lambda syntax proposal

[Eugene Lazutkin]

Thank you for useful links and explanations. Correct me if I am wrong 
but in the current form lambda is a facility that duplicates a function. 
More than that it reminds my old languages that had separate keywords 
for functions (our "lambda"?) and procedures (our "function"?).


Writing code I frequently need small functions (or lambdas). The smaller 
the code the better --- it allows to be concise and does not obscure the 
intent. That's why I prefer to use lambda's proposed by Oliver Steele 
(http://osteele.com/sources/javascript/functional/), which have a lot of 
problems being a pure JavaScript implementation. Writing a factorial 
using a linear recursion combinator with lambdas:


var fact1 = linrec("<= 1", "1", "[n - 1]", "m * n[0]");

is simple and more readable than the equivalent:

var fact2 = linrec(
  function(n){ return n <= 1; },
  function(){ return 1; },
  function(n){ return [n - 1]; },
  function(m, n){ return m * n[0]; });

I typed 200% more text, and the readability went down by the same 200% 
--- because I added 200% of the technical noise not relevant to the 
algorithm itself. Anything that improves on that is good in my book. 
Lambdas are good:


var fact3 = linrec(
  lambda(n) n <= 1,
  lambda() 1,
  lambda(n) [n - 1],
  lambda(m, n) m * n[0]);

Shortcuts for lambdas are better:

var fact4 = linrec(\(n) n <= 1, \() 1, \(n) [n - 1], \(m, n) m * n[0]);

I perceive them as less noisy.

The link you gave features long lambdas and I don't see what they buy 
vs. the regular functions. This is the example from that page:


lambda(i) {
  if (!isNumeric(i))
// etc.
  else if (i < 0)
// etc.
  else if (i < params.length)
params[i][0]()
  else {
i -= params.length;
if (i < rest.length)
  rest[i]
else
 // etc.
  }
}

Written as function it is not that long or less clear:

function(i) {
  if (!isNumeric(i))
// etc.
  else if (i < 0)
// etc.
  else if (i < params.length)
return params[i][0]()
  else {
i -= params.length;
if (i < rest.length)
  return rest[i]
else
 // etc.
  }
}

My point is we gain more by concentrating on small light-weight snippets 
than on one more way to code a big function.


So concentrating on small snippets:

1) Reducing "technicalities" and the boilerplate improves the clarity of 
the code.


1a) I don't mind if lambdas don't have their own "this", "arguments", or 
a scope --- from my experience they are rarely used in small snippets.


1b) I am all for skipping "return" --- it reduces the boilerplate for 
small snippets.


2) Named lambdas, and parameter defaults are of little value. Use 
functions if you truly need a named functionality. Otherwise assign it 
to a variable and pass around (rarely needed).


3) Losing the keyword "lambda" in favor of a small shortcut (e.g., \) 
will be of great value --- less noise, less boilerplate, less typing, 
less opportunities to mistype.


I suggest paring down "lambda" by shedding names, default parameters, 
and possibly the keyword "lambda" itself --- it reduces complexity, no 
chance for ambiguity, easier to implement, easier to use.


Thanks,

Eugene


Brendan Eich wrote:

On Dec 4, 2008, at 5:44 PM, Eugene Lazutkin wrote:


If you started to recap the history of this discussion, could you (or
anybody else in the know) verbalize following things:

1) What is the difference between the function and the lambda? I am not
talking about their syntax, I want to understand the semantic
difference, if there is any.


Please read

http://wiki.ecmascript.org/doku.php?id=strawman:lambdas



2) Why is it important for a lambda to have an optional name?


It may not be.



What's
wrong with using a function, if we want a name? IMHO lambda should have
the minimalistic syntax.


"Minimalistic" does not define itself. The question is what is the 
minimal syntax given various constraints.


Church's Lambdas take one argument only. One can curry by hand. Why 
isn't that the minimum minimum?




3) Why is it important to be able to specify parameter defaults in
lambda? Again, it looks like an extra sugar to me that can be covered by
a function with parameter defaults.


See

https://mail.mozilla.org/pipermail/es-discuss/2008-October/007715.html

Also consider that default parameters are a convenience we want lambdas 
to have if we believe functions should be avoided for much lambda-coding 
by hand. The countervailing argument is that lambdas have unintended 
completion value hazards, but Schemers and others don't worry about 
these and would prefer not to have to run back to functions and lose 
Tennent's Correspondence Principle every time default parameters beckon.




The reason I ask is a lot of discussion is going around "but if it has a
name" 

Re: Allen's lambda syntax proposal

[Eugene Lazutkin]

If you started to recap the history of this discussion, could you (or
anybody else in the know) verbalize following things:

1) What is the difference between the function and the lambda? I am not
talking about their syntax, I want to understand the semantic
difference, if there is any.

2) Why is it important for a lambda to have an optional name? What's
wrong with using a function, if we want a name? IMHO lambda should have
the minimalistic syntax.

3) Why is it important to be able to specify parameter defaults in
lambda? Again, it looks like an extra sugar to me that can be covered by
a function with parameter defaults.

The reason I ask is a lot of discussion is going around "but if it has a
name" and "but if it has a default". If it doesn't have a name I would
be satisfied personally with \(a, b) {...} --- it doesn't clash with
anything. Or even with \(a, b) expr.

Thanks,

Eugene

Mark S. Miller wrote:
On Wed, Dec 3, 2008 at 7:25 PM, Jon Zeppieri 
<[EMAIL PROTECTED] 
> wrote:


Okay -- so we agree.  In that case, it's clear that your proposed
syntax:

  &(a,b,c) {...}

has the same problem, right?  Any valid ES3 infix operator will have
the same problem, if we use it as a prefix lambda operator.



Welcome to the syntax races. "lambda" takes an early lead, but drops 
back because of too much weight. For a while, it's neck and neck between 
"||" and "^", with "\" following closely and "fn", "&", and other 
trailing. Many old timers (including your commentator) are rooting for 
"||" because of its previous historic performances. But "||" trips up 
over ambiguities not present on its original track. "^" is now in the 
lead. Oh no! It trips on a different ambiguity. This track seems riddled 
with more ambiguities than any of these contenders have ever trained on. 
Seeing "^" stumble, "&" and other conte nders saddled with "binary 
operator"ness, drop back and concede. "\" has taken the lead


--
   Cheers,
   --MarkM




___
Es-discuss mailing list
[EMAIL PROTECTED]
https://mail.mozilla.org/listinfo/es-discuss

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

Re: Strengthening Function.prototype.toString

[Eugene Lazutkin]

Inline.

Yuh-Ruey Chen wrote:
> 
> So as far as I can tell, what we need to discourage usage of
> func.toString() is:
> 
> 1) An API for function currying/partial evaluation (specializing/binding
> certain arguments).
> 2) A read-only property on functions that contains the list of parameter
> names.

Both points are valid. But #2 is of little utility for variadic 
functions. Example:

function foo(){
   return arguments[5];
};

As you can see it is generally impossible to know how many arguments are 
actually expected, and what are their names.

Personally I am not against a read-only property for argument names, 
just pointing out its limited utility.

> For any other purpose, I would think that you might as well parse the
> whole source file rather than just the function, since you would need to
> keep track of closures. For example, consider this:
> 
> function foo() {
> var x = 10;
> return function() {
>return x;
> };
> }
> 
> function bar(f) {
> var x = 20;
> print(f());
> print(eval(f.toString())());
> }
> 
> bar(foo());
> 
> That would print 10, then 20. So as you can see, even in the same scope,
> eval(f.toString())(...) is not necessarily equal to f(), even if
> f.toString() is a correct decompilation of f.

That's a good point about literal comparison of bodies. The other side 
of this argument is: it is generally impossible to read the function 
body, and compile it back with eval() expecting to get the same 
functional behavior because it this point we have no idea about 
closures. To accomplish that we need a way to manipulate 
closures/context: extract it from a function somehow, specify it as a 
parameter to eval()< and so on. I am not sure it is doable/practical.

Thanks,

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

Re: Strengthening Function.prototype.toString

[Eugene Lazutkin]

Inline.

Karl Krukow wrote:
>>>
>>> (function(a,b) {return a+b;}).specialize([42])
>> Does your example substitute a or b? How to indicate what parameter(s)
>> you want to specialize?
> 
> In this second form, it would specialize the first parameter. To  
> specialize the second, you would use
> 
> (function(a,b) {return a+b;}).specialize([undefined,42])
> 
> granted you would be unable to specialize using undefined as a value.
> 
> Alternatively you could use a form:
> 
> (function(a,b) {return a+b;}).specialize([{1: 42}])

My understanding you are not proposing this as a part of the standard, 
but rather how someone can implement the functionality, right?

> At least it depends on being able to produce a FunctionDeclaration  
> which, when eval'ed, is equivalent to the original function. However,  
> a JIT would have some representation of the function stored already,  
> otherwise how would it emit code? Now I am theorizing, but wouldn't it  
> just be adding another 'translation module' which emits code back in  
> JavaScript?

1) JIT can use an intermediate byte code that was most probably optimized.
2) JIT can use optimized syntax tree notation (I hope we'll go past that).
3) No JIT, the code is already (partially) compiled.

To sum it up: I don't see the practical need to keep the code in its 
source form around.

> I'm not convinced that it is 'complicated, resource-hungry or  
> redundant.'  At least I have an early prototype implementation, Jeene 
> (http://code.google.com/p/jeene/ 
> ) which I feel is not too bad performance wise: it is a one pass  
> solution as is based on Crockford's efficient Pratt parser.

My intention was more humble: I wanted to voice my personal opinion on 
this matter rather than convincing anyone that my opinion is the 
ultimate truth. And I am sure that your solution works just fine barring 
small details of the performance testing.

Still I think requiring to keep the source code around other than for 
debugging is an overkill.

> However, you are right! I would actually like to 'ask big' ;-) If I  
> could ask for more I would not ask for a specialize function directly  
> in the environment. 'specialize' is just one application of a much  
> more powerful concept which is the LISP code/data duality. Instead, I  
> would ask for e.g., a Function.prototype.representation function that  
> would return an object representing the abstract syntax tree of the  
> function, perhaps even annotated with additional information (and  
> perhaps a dual Function.prototype.compile). This would be even better  
> as I wouldn't have to do the parsing myself.

Here we go again: you made another implicit assumption that AST are 
still around (and untransformed) when the code is running. And even one 
more: AST objects should be the same on all interpreters.

> Think I can have that? ;-) Thanks for your great reply.
> 
> /Karl

I think that there is one common flaw with both suggestions (the source 
code and the AST) --- they are too low-level, require too much 
JavaScript (parser + interpreter, even for AST), don't give much 
flexibility to implementers, and my prevent possible optimizations. I 
feel that more high-level (actually medium-level) constructs would give 
the flexibility for programmers and implementers without compromising 
the performance. Of course it is all predicated on the interest from 
users in this functionality, which is still to be seen.

Thanks,

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

Re: Strengthening Function.prototype.toString

[Eugene Lazutkin]

Karl Krukow wrote:
> 
> However I would have to move from a form:
> 
> (function(a,b) {return a+b;}).specialize({ a: 42})
> 
> to
> 
> (function(a,b) {return a+b;}).specialize([42])

Does your example substitute a or b? How to indicate what parameter(s)
you want to specialize?

Another thing: your solution relies on keeping around potentially big
function bodies in their textual form, and a full-blown parser (+
interpreter, if you want to do optimizations while specializing) written
in JavaScript, while there is a parser already in the
compiler/interpreter that is a part of a run-time (see eval()). Sounds
complicated, resource-hungry, and redundant. Why not implement
specialize() at the interpreter/compiler level rather than hacking
around with toString()? If we are to ask for features let's ask big! ;-)

Thanks,

Eugene


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