Content deleted Content added
No edit summary |
|||
Line 298:
::Simply put, it means that <code>return</code> inside the closure would return not from the closure itself, but from the function inside which that closure was created. This is the take on closures the Java guys did, and you can read more on it [http://www.javac.info/closures-v04.html here] - you may notice an oddly familiar name in the list of authors there as well. ;)
::Of course, such approach is only meaningful in a language which distinguishes closures from "normal" functions (Scheme doesn't, for example, and neither does ECMAScript), and it seems to be conceptually weak in a sense that it does not go well with nested closures (what if I don't want to return from the topmost enclosing non-closure, but from a closure 2 levels up? and if I can't, why not?). [[User:Int19h|-- int19h]] 08:53, 28 January 2007 (UTC)
::: ''"what if I don't want to return from the topmost enclosing non-closure, but from a closure 2 levels up? and if I can't, why not?"'' <br />I think JavaScript lets you do that, but through an improper use of a differently aimed construct, so I'm writing this just for comparison sake (since this method could make one of the javascript examples to behave like the Smaltalk one on the "^" operator). Furthermore, this method requires an explicit handling of the "exit point", yet it's very easy and maybe obvious: just use <code>throw</code> instead of <code>return</code> and capture the result as an exception, wherever you need it.<br /><br />Of course, that's not the right way one should use an exception-handling construct, so that'd be perhaps misleading/confusing in a real script, yet that should work as wished. And of course, great troubles might arise when using such an improper return method combined with regular exceptions, yet it's possible to make it work: in example, one could wrap the "exception-like" result into a certain "class" object and verify whether a captured exception is an instance of such a "class". So doing, the <code>throw</code> keyword whould behave quite like the <code> ^ </code> operator in Smalltalk, while <code>return</code> whould be the equivalent of a "normal" procedure end.--[[Special:Contributions/151.74.14.142|151.74.14.142]] ([[User talk:151.74.14.142|talk]]) 01:21, 2 April 2008 (UTC) xeal
::: In languages with full support for closures, you can't "return" from any closure, no matter how many levels up, except by providing a final expression. Providing an example of what it would look like in Javascript would require that I make up a new syntax. For that, I suggest you see the proposed Java extension. [[User:Gafter|Gafter]] 17:14, 28 January 2007 (UTC)
Line 304 ⟶ 306:
:::: A programming language's expressive power is not determined by what one can compute, but rather what kinds of abstractions one can express. Most modern languages are Turing-complete and can therefore compute the same set of functions. I suggest you read Guy Steele's "lambda the ultimate..." series of papers to understand what is lost when not all lexical bindings are preserved. Alternatively, I suggest you attempt to write a function in JavaScript that can be used in place of the built-in if-then-else statement (of course the invocation syntax would differ; that's OK). You'll find you can't. [[User:Gafter|Gafter]] 23:51, 28 January 2007 (UTC)
::::: ''"Alternatively, I suggest you attempt to write a function in JavaScript that can be used in place of the built-in if-then-else statement (of course the invocation syntax would differ; that's OK)."'' <br />I'm not sure this is exactly what you're asking for, but at first glance I'd write the following:
<pre>
//
// Implementing the if-else construct as a function which takes three functions as arguments.
// The first function passed is the condition to be tested, and is expected to evaluate as
// true or false; the second one is the block to be executed if the test condition evaluates to
// true, and may optionally return a value; the third is the alternative block to be executed
// and may optionally return a value. One of such optional values is returned (null or undefined
// if none is supplied). The calling function might assign the result value to a somewhat variable,
// or let the function-block to handle it. A preferred way to call this function and easily handle
// variables as in a standard if-else statement is throughout internal functions, as shown in
// the alertMax function below.
//
function if_else(ifcond, ifblock, elseblock){
var result = null;
var doIF = ( ifcond() ) && ( result = ifblock() ); //when ifcond evaluates to true ifblock is
//called and results assigned to result,
var doELSE = (! ifcond() ) && ( result = elseblock() ); //otherwise elseblock is called in
//the same fashion.
return result;
}
//
// Comparing values by calling if_else function with opportune parameters.
//
function alertMax( a, b ){
var max = if_else(
function(){ return (a >= b); },
function(){ alert( a + " is greater than or equal to " + b); return a; },
function(){ alert( b + " is greater than " + a); return b; }
); //note functions passed as ifblock and elseblock alerts different text;
//this shows the alternate execution of statements-equivalent functions works.
alert("Max computed value is: " + max);
}
alertMax(6, 5);
alertMax(8, 9);</pre>
:::::--[[Special:Contributions/151.74.14.142|151.74.14.142]] ([[User talk:151.74.14.142|talk]]) 01:21, 2 April 2008 (UTC) xeal
::::: I can, however, write a function in JavaScript that can be used the same way Scheme's <code>if</code> or <code>cond</code> expression can be used. That's what my point was - that JavaScript closures can express all abstractions Scheme closures can. [[User:Int19h|-- int19h]] 06:45, 29 January 2007 (UTC)
| |||