Peano Arithmetic
Good evening,
I apologize if this issue was discussed already, I've been unable to
find an answer after a few hours of digging and Googling.
I was watching some old SICP videos and translating some of the code
into JavaScript to see how it compared to Scheme and came across a
couple of errors when implementing Peano Arithmetic.
Each of these functions should are expected to return 4 if I pass 2,2
into them:
--
function add1(x,y){
if(!x){
return y;
}
else{
x--;y++;
return add1(x,y);
};
}
function add2(x,y){
if(!x){
return y;
}
else{
return add2(x--,y++); //recursion error
};
}
function add3(x,y){
if(!x){
return y;
}
else{
x--;
return add3(x,y)++; //error: cannot assign to a
function result
}
}
--
The first function works as expected.
The 2nd function goes into an infinite loop since the variables are
apparently not assigned as expected before passed into the function
The 3rd function throws an assignment error once it reaches the return.
So my question is whether this behavior is by design or by accident?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
How to escape implicit 'with (this)' of a method body
/function foo () { return 'global'; }
class bar {
function foo () { return 'local'; }
function zot () {
// How can I call the global foo from here?
without (this) { foo(); }
}
}/
You could use window[foo](); or whatever the global object is named in
the environment
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Opt-in versioning
So let me see if I understand this argument correctly.
{{...}} means the same thing as a generic let statement and {{...}} is
optional
Because it's optional, the language should contain both let and {{...}}?
I don't see how this doesn't add a level of complexity.Instead of just
remembering how I declared my variable I would also have to see what
kind of block I put it in. If my program has 1500+ lines of code, this
isn't exactly going to be clear, especially if the whitespace is nasty
and the {{ isn't on the same line, nor indented properly . let
clearly states that this variable is bound by its block and I just have
to find the { }. var means its clearly bound by its function and I
just have to find where the function is.
I assume with these rules the following is legal?
if(a){
}
else{{
}}
If I want the benefits of this blocking, does that mean I have to give
up some of my shorthand?
(a === b) ? true : false;
How would the block work in this case?
The JavaScript 1.7 let statement is already the better block we need,
and instead of being a generic solution like the one you've suggested,
it has flexibility and doesn't force me to change the way I already code
things:
var x = 5;
var y = 0;
let (x = x+10, y = 12) {
print(x+y + \n);
}
---
var x = 5;
var y = 0;
document.write( let(x = x + 10, y = 12) x+y + br\n);
---
if (x y){
let gamma = 12.7 + y;
i = gamma * x;
}
document.write(x+y + br\n);
print((x + y) + \n);
---
for (let expr1; expr2; expr3) statement where expr2, expr3, and statement are
local
---
How would you're better block work as a viable alternative without creating
more work or doing what can already be done by let?
Examples from http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Opt-in versioning
Jon Zeppieri wrote:
On Mon, Jul 21, 2008 at 8:58 PM, Michael Haufe [EMAIL PROTECTED] wrote:
So let me see if I understand this argument correctly.
I generally agree with what you've written here -- just a couple of
comments...
If I want the benefits of this blocking, does that mean I have to give
up some of my shorthand?
(a === b) ? true : false;
How would the block work in this case?
Not sure what you're getting at here. What block are you referring to?
The JavaScript 1.7 let statement is already the better block we need,
and instead of being a generic solution like the one you've suggested,
it has flexibility and doesn't force me to change the way I already code
things:
I'm partial to the let statement, too, but you should know that it's
not being proposed for either ES3.1 or ES4. But yes, it makes the
scope of the let-bound variables perfectly clear -- let vs. let*
binding semantics aside. (Does the JS1.7 let statement bind
sequentially or in parallel?)
-Jon
I was basically asking if these two structures were supposed to be
equivalent and part of what he was suggesting:
if(a === b){
foo;
}
else{{
bar;
}}
_
(a === b) ? foo : {{ bar }};
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Opt-in versioning
The entire concept of {{ ... }} irks me, and probably quite a few
others. This would add a level of syntax complexity and confusion
non-intuitive to most developers.
Object literal {{ foo : bar}}?
function(){{...}} ?
if(){{
...
}}
else {{
...
}}
switch()? with()? Imagine JSON with these rules. thats abhorrent. I
understand the concern with scoping but this would be too far of a shift
to be considered I would hope.
I would like an arrangement that combines opt-in and explicit
block-type notation.
A block is either scoping or non-scoping:
function Test (List)
{{
if (Debugging)
{
const DbName = Test;
var Counter = 5;
}
for (var Num = 0; Num List.length; ++Num)
{{
var Text = List [Num];
Result += Text [3];
}}
}}
Double braces {{ }} indicate a scoping block, single braces
{ } indicate a non-scoping block. A declaration binds the
name to the nearest surrounding scoping block {{ }}. A non-
scoping block { } can never bind a name. All the keywords
var, const, function etc. behave in exactly the same way
in this regard.
You opt in by using double braces at a point where a block is
possible. At the outermost level of the source text the old
rules apply. If you use { } the old rules remain in force.
If at any point you surround a block with {{ }}, then inside
this block double braces {{ }} are always scoping and single
braces { } are never scoping.
You can choose freely between scoping and non-scoping block
wherever this is supported by the standard. When a context
requires a certain type of block you must use the correct
markings, else a syntax error is thrown. There is no hidden
automatic correction, your notation must be correct. (But
only when you enable this.) This is so a programmer who
doesn't know the requirement is told. No hidden semantics!
So if the language requires that all function blocks must
be scoping, then when this is enabled you can only mark
function blocks with {{ }}. And if the language can't
deal with a certain construct written in a non-scoping
block, then you can only put this construct in blocks
that you mark {{ }}.
If peculiar rules are needed, they won't cause surprises if
they become opt-in together with the syntax change. But I'm
hoping that the above, together with clear compilation error
messages, can minimize peculiarities and make things clear
and simple.
Note that old browsers can compile source that uses this
syntax. However the meaning may be different. Hopefully
with suitable preparations and restrictions a linter or an
ECMAScript implementation can check the intended meaning
and analyze whether the program will have this intended
meaning when compiled in an old browser.
One unknown factor is that I don't know if the proposed
markings are sufficient for opt-in, or if something else
is required to avoid incompatible ambiguity.
The scoping rules of ECMAScript are becoming very complicated.
The behavior of the keyword function varies so much among
vendors that it can't be standardized,
https://mail.mozilla.org/pipermail/es3.x-discuss/2008-July/000280.html
var and const have now been specified to behave each in
its own way, and let requires many paragraphs of explanation.
I think the above can offer simplicity and clarity.
Ingvar
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
