On 1/21/08, Igor Bukanov [EMAIL PROTECTED] wrote:
let f2;
function f(a)
{
f2 = function() { return a; }
goto return g();
}
function g() {f2 = null; ... }
Here in f return g() is in tail position yet the frame of f can not
be eliminated completely since it is referenced through
On 1/21/08, Igor Bukanov [EMAIL PROTECTED] wrote:
Consider another example:
function f(a) {
function f2 { return a * 2; }
if (a == 0) return 0;
goto return f(a - 1);
}
f(1 20);
One may expect that this would require O(1) space. But this is not the
case as the implementation
On 1/21/08, Igor Bukanov [EMAIL PROTECTED] wrote:
You can not deduce that from ES4 specs that it does not require that f
should be ever dropped.
f has nothing to do with it. f2 is the closure that is constructed on
each iteration (assuming it is not optimized away in the specific
example you
On 1/21/08, Igor Bukanov [EMAIL PROTECTED] wrote:
ES4 does not guarantee that. Moreover, in most current implementations
of ES3 the unreachable objects do consume space until GC collects
them, but with a conservative GC even that can not be relied upon.
The until GC collects them part does
Unfortunately, this issue has become confused, and I've helped confuse it.
First of all, I'm sure you're right that ES4 does not mandate the
reclamation of memory for unreachable objects. R6RS doesn't mandate
it either: The reason that implementations of Scheme do not
(usually!) run out of
On 1/24/08, Lars T Hansen [EMAIL PROTECTED] wrote:
Either the spec will mandate proper tail calls in a set of clearly
defined situations, or it will not mention them at all. The set
should be ambitiously large, but it also needs to be describable.
Anyhow, an implementation will always be
How would the 'fixed' property be used, in practice? I can see a use
for fixed-length vectors, but I'm unsure about vectors that can be
switched between fixed and variable length by untrusted code.
-Jon
On 3/3/08, Lars Hansen [EMAIL PROTECTED] wrote:
Draft 2 enclosed (changelog near the top).
On 3/5/08, Lars Hansen [EMAIL PROTECTED] wrote:
So, why a read/write, rather than a read-only, 'fixed' property?
It was my hunch when I designed that feature that code that uses
fixed-length vectors wants to be able to catch errors most of the time,
but also does not want to be stuck in
On 3/5/08, Lars Hansen [EMAIL PROTECTED] wrote:
Note, the Vector class called as a function does not create a new
vector if its input is a vector. The prose is wrong in the draft,
but the code is right.
There probably should be copy() method on the Vector class.
It's identical to a
On 3/10/08, Lars Hansen [EMAIL PROTECTED] wrote:
First draft of the spec for the Function class. Please comment.
Suggestion: deprecate the Function constructor and static invoke().
Almost all of its uses are better handled by function expressions and,
in those cases where eval() in required,
On 3/10/08, Erik Arvidsson [EMAIL PROTECTED] wrote:
There are valid use cases for new Function (...) and Function(...).
One that comes to mind is getting an attribute in DOM and make it into
an event handler. Yes, the Function constructor and meta::invoke can
be replaced by eval but
On Tue, Mar 11, 2008 at 10:49 AM, Lars Hansen [EMAIL PROTECTED] wrote:
I think there are three points to be made here. The first is
that the Function constructor provides functionality that
eval does not, namely, creating new functions that are closed
in the global environment only.
I promise not to drag out this discussion, since no one else seems to
be interested in it.
On Tue, Mar 11, 2008 at 12:16 PM, Lars Hansen [EMAIL PROTECTED] wrote:
Sure, nobody argues about that per se, but I don't see the spec
as being the place to take an ideological stand about whether
On 3/20/08, Lars Hansen [EMAIL PROTECTED] wrote:
Thanks for pointing some of these out, Brendan did the same. This is
already legal to define catch-alls:
{ var meta::get: function () { ... } }
Is there a more recent version of the grammar than the docs at
Are namespaces (and I'm not referring to the reflected objects here)
first class values?
The overview document explicitly calls then compile-time values,
then proceeds to give the following example:
The following lines create namespace constants ns1, ns2, ns3, and ns4;
the first two are
On 3/21/08, Brendan Eich [EMAIL PROTECTED] wrote:
I believe the intention among the core ES4 group over the last couple
of years has been to support runtime qualifiers in ES4, as well. JS
has computed property names since day 1: o[id] to access o.p. An
optional strict mode can't reason
On Fri, Mar 21, 2008 at 11:12 AM, Jeff Dyer [EMAIL PROTECTED] wrote:
Names that can be resolved at compile time won't (can't) change meaning at
runtime. And names that are qualified by constant namespaces that appear in
the (safe) contexts you describe above can be resolved at compile-time.
2008/3/24 Lars Hansen [EMAIL PROTECTED]:
I would in particular like comments on eval.
Why does the operator form of eval have the name 'intrinsic::eval' (in
addition to plain 'eval')? Either eval has the distinction of being
the only namespaced operator in the language, or else this is a pun.
I think I need to understand the following before I can comprehend the rest:
On Tue, Mar 25, 2008 at 12:42 PM, Lars Hansen [EMAIL PROTECTED] wrote:
Note also that
eval(s)
is the same as
null::eval(s)
so arguments about 'namespaced operators' are probably not right.
Not right in
On Tue, Mar 25, 2008 at 5:47 PM, Lars Hansen [EMAIL PROTECTED] wrote:
Not right in what sense? I'm not sure whether you're
claiming that the operator form of intrinsic::eval isn't a
namespaced operator (in which case, how is it not a pun?) or
that it's not the *only* namespaced
On 3/30/08, Jeff Dyer [EMAIL PROTECTED] wrote:
Hi,
I've updated the ES4 grammar files linked from
http://wiki.ecmascript.org/doku.php?id=proposals:normative_grammar
Thanks, Jeff.
- Allowing splat expressions in array literals is a nice addition, but
restricting them to the end of element
On 3/31/08, Lars Hansen [EMAIL PROTECTED] wrote:
Having thought more about this, we may get away with less
draconian measures for lexically scoped eval -- it's enough
to simply decree that eval may not add bindings to the
caller's binding object in strict mode (a simple run-time check,
On 4/2/08, Lars Hansen [EMAIL PROTECTED] wrote:
Lars, does this mean that expr::[expr] can't introduce
lexical bindings? Or: in strict mode, it can't, but in
standard it can?
It can't introduce bindings; it's just a name.
I meant something like:
var foo::[bar] = baz;
My
On 4/2/08, Lars Hansen [EMAIL PROTECTED] wrote:
I meant something like:
var foo::[bar] = baz;
My objection to expr::[expr] in earlier messages was based on
the assumption that these computed names could be used on the
left-hand side of an assignment expression -- which, I'm
On Wed, Apr 2, 2008 at 11:15 PM, Lars Hansen [EMAIL PROTECTED] wrote:
Is this already in AS3? If so, is it often used?
The syntax comes from E4X, which is incorporated into AS3 and
Spidermonkey. Try this in Firefox:
script type=text/javascript;e4x=1
var x = ns:p
On 4/3/08, Lars Hansen [EMAIL PROTECTED] wrote:
package X {
namespace myns;
class C {
myns var v = 37;
}
var x = myns;
var y = v;
print((new C).x::[y]);
}
This does print '37' if compiled with ASC and run through
the Tamarin VM.
This is like
On 4/3/08, liorean [EMAIL PROTECTED] wrote:
On 04/04/2008, Jon Zeppieri [EMAIL PROTECTED] wrote:
function foo(name) {
...
return null::[name];
}
... treats the environment as if it were a datum. I know that in the
ES3 spec all bindings are referred
On 4/4/08, Jon Zeppieri [EMAIL PROTECTED] wrote:
eval has a real use: runtime code generation. (This does not require
dynamically scoped eval, but that's beside the point here.)
Uh, I meant lexically scoped eval, of course...
___
Es4-discuss
On Fri, Apr 4, 2008 at 11:30 AM, Lars Hansen [EMAIL PROTECTED] wrote:
I don't get it.
Your comment about inhibiting static analysis isn't right; if ns::x is a
name then either ns is known to be constant at compile time or not, and
if it is, then nothing prevents early binding. ES3
On Fri, Apr 4, 2008 at 1:25 PM, Lars Hansen [EMAIL PROTECTED] wrote:
I hope the forthcoming spec on names will clarify
this, so I suggest we hold off arguing about this particular point for
the moment.
Happily.
You can argue, and I think you are arguing, that there is no utility in
On Fri, Apr 4, 2008 at 1:45 PM, Lars Hansen [EMAIL PROTECTED] wrote:
That could be true. But it could also be the case that people
find that it is easier to say
var x = ...
var y = ...
var n = x // but could be y
...
// n may change here by assigning another string to it
On Fri, Apr 4, 2008 at 2:42 PM, Mark Miller [EMAIL PROTECTED] wrote:
On Fri, Apr 4, 2008 at 11:24 AM, Jon Zeppieri [EMAIL PROTECTED] wrote:
(and the latter does not handle shadowing, for better or worse).
Heh. Someone should revive Mark Miller.
[startles] What? I'm awake. Can
On Thu, Apr 10, 2008 at 1:30 PM, Lars Hansen [EMAIL PROTECTED] wrote:
Have the printf/sprintf been considered for inclusion?
Similar functions have been considered, and rejected. Curiously,
I can't find writeups of the rejected proposals now.
Referred to in:
On 4/10/08, Jon Zeppieri [EMAIL PROTECTED] wrote:
var o = { null var count = 100, ... };
Sorry: two syntactic mistakes, here, one of which is interesting.
The boring one is my use of '=' rather than ':'.
But after reading the object initializer draft, I see that, if the
intent
On Fri, Apr 11, 2008 at 11:04 AM, Lars Hansen [EMAIL PROTECTED] wrote:
Right, I get that, and Brendan's point was a good one. I was
just thrown by the fact that I hadn't seen an example of
class A {
var public::count = 10;
}
rather than
class A {
public var
On Fri, Apr 11, 2008 at 12:17 PM, Lars Hansen [EMAIL PROTECTED] wrote:
One motivation is that programmers are likely to prefer the Java-like
syntax where the namespace (in its role as access control) shows
up early:
public var count =
private var key =
I really think this is the
On Fri, Apr 11, 2008 at 1:05 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
Yep, I agree with this, too. I certainly wouldn't want to mandate
var public::x
in classes and wouldn't really want to write it myself. But there's
some value in having a single, canonical syntactic form
On 4/10/08, Lars Hansen [EMAIL PROTECTED] wrote:
Here is the third draft, which I have tentatively labeled as stable.
Please note the OPEN ISSUES, the input of everyone on these would be
appreciated.
* There is no way to seal the object created by an object
initializer, as a prefix
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
2008/7/29 Brendan Eich [EMAIL PROTECTED]:
On Jul 28, 2008, at 3:22 PM, Michael Haufe wrote:
function foo () { return 'global'; }
class bar {
function foo () { return 'local'; }
function zot () {
// How can I call the global foo from here?
without (this) { foo(); }
}
40 matches
Mail list logo
