On Jul 9, 2007, at 4:51 PM, Kris Zyp wrote:
You are right, it doesn't work for a Date, but it does work on an
Array.
Only if you don't call toString or toLocaleString.
Most Array and String prototype methods are intentionally generic.
Too bad we didn't generalize this all over the place
On Jul 9, 2007, at 9:09 PM, Kris Zyp wrote:
I think it seems worth considering what a programmer is intending
if writes
a function and defines a prototype for it. This is an explicit
action to
create objects that inherit from the prototype object. If a user has
specifically written code
On Jul 31, 2007, at 5:41 AM, P T Withington wrote:
Indeed. I was suggesting that the spec was broken; that it meant to
prescribe an optimization to avoid unnecessary closures, but that it
got it wrong (perhaps because it overlooked the mutability of the
function object itself?). Surely
On Aug 14, 2007, at 10:10 AM, liorean wrote:
Peter Hall wrote:
type B = {b:Self};
On 14/08/07, Cormac Flanagan [EMAIL PROTECTED] wrote:
Yes, I think this should be fine.
I'm all for allowing recursive structural types e.g. for use as binary
trees or linked lists.
type BinTree =
On Aug 16, 2007, at 10:42 AM, Lars T Hansen wrote:
On 8/16/07, Stefan Gössner [EMAIL PROTECTED] wrote:
Hello,
here are my first questions after following the list quite a while.
1. I really like the array slice syntax [start:end:step] described in
On Aug 16, 2007, at 11:42 AM, Dave Herman wrote:
Dave Herman's analysis is on the wiki, but for some reason I'm
getting an error trying to access the relevant page [3].
...
[3] https://wiki.ecmascript.org/ECMA/wiki/doku.php?
id=discussion:classes_as_structural_types_with_branding
You've
On Aug 17, 2007, at 2:47 PM, Garrett Smith wrote:
It would be nice to have Array literal syntax declare it's ArrayType
before the declaration of the array.
For example:
1. var x : ArrayString = [ foo, bar, document.title,
getAnotherString() ];
Array is not a parameterized type. If it
On Aug 21, 2007, at 1:36 PM, zwetan wrote:
On 8/21/07, Brendan Eich [EMAIL PROTECTED] wrote:
On Aug 21, 2007, at 1:24 AM, zwetan wrote:
+1 for being able to set the attributes
but I think we should not add a TRANSIENT attributes for ES3,
DONTENUM should be enought and backward compatible
That's partial application, not currying. No one has proposed its
standardization; lots of Ajax libraries implement it much as you show
below. The ones I've looked at play their own custom variations on a
theme, so wouldn't all be subsumed by a standard.
/be
On Aug 28, 2007, at 2:20 PM,
On Sep 3, 2007, at 7:10 PM, Brendan Eich wrote:
On Sep 3, 2007, at 3:00 AM, Lars T Hansen wrote:
On 8/26/07, Garrett Smith [EMAIL PROTECTED] wrote:
Back to caller...
caller is on the prototype in Mozilla.
Not lately:
js function f(){ return f.hasOwnProperty('caller')}
js f()
true
ES embeddings exist where URIs make no sense, so it's not a good
candidate for the core standard. But we expect the burgeoning Ajax
ecosystem to keep on burgeoning (http://www.answers.com/main/ntquery?
gwp=13s=burgeon), and make good use of shared library hosting
arrangements such as those
On Sep 10, 2007, at 1:21 PM, liorean wrote:
On 10/09/2007, Brendan Eich [EMAIL PROTECTED] wrote:
Either reflect the __proto__ (read-only, please) property as some
implementations do, or hardcode the prototype structure and code your
propertyIsEnumerable tests accordingly.
Would
On Sep 10, 2007, at 2:21 PM, Garrett Smith wrote:
And my point was that it appears to duplicate functionality of
hasOwnProperty in a differently named method.
The two functions are different:
js var Op = Object.prototype;
js Op.foo = 42;
42
js print(Op.hasOwnProperty('foo'),
I am not looking to make trouble here, believe me, but I want to
point out two things that could help David's case:
1. JS regexps were modeled by me (to lwall's horror ;-) on Perl
regexen. Here's what perl (5.8.8) does:
$ perl
aaab =~ /(a\1)+|b/;
print $ ($1)\n;
b ()
It's no surprise
On Sep 23, 2007, at 12:22 PM, Garrett Smith wrote:
in no case is the value of (new function(){}).constructor Function.
It shouldn't be, but it is in OSX Ref Impl. (I did not build this).
js (new function(){}).constructor
[function Function]
No, that's just
On Oct 2, 2007, at 4:11 PM, Chris Double wrote:
I notice the Spec page on the publically accessible wiki comes up with
Sorry, you don't have enough rights to continue. Perhaps you forgot
to login?. Is it possible for this to be public? Page reference is:
On Oct 7, 2007, at 11:41 PM, Garrett Smith wrote:
I personally believe that the unsound, untestable/non-executable ES3
spec is a rathole we should avoid. The errata (which are not complete
by a long shot) that we have hosted at http://www.mozilla.org/js/
language/E262-3-errata.html would have
On Oct 9, 2007, at 6:33 PM, Brad Fults wrote:
Hi,
As far as I can tell [1] there have never been logical assignment
operators (AND, OR) in ES and I can't access the spec on the wiki [2]
anymore, so I don't know if they're in the spec. I don't see anything
in the proposals section, so here's
On Oct 10, 2007, at 3:53 PM, Garrett Smith wrote:
Typechecking is a problem.
typeof is limited and allows host objects to return anything. The
problem is that some host objects return function, for example, a
NodeList in Safari. This is perfectly legal, according to the spec.
See
On Oct 11, 2007, at 7:21 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
When convert null to string it is better to return empty string
then 'null' string;
var a= null;
var b= '';
b= 'test' + a; //b == 'testnull'; EXPECTED: b == 'test'
This is an incompatible change and there's no point
On Oct 11, 2007, at 1:36 PM, Garrett Smith wrote:
On 10/10/07, Brendan Eich [EMAIL PROTECTED] wrote:
On Oct 10, 2007, at 3:53 PM, Garrett Smith wrote:
if (it is Callable) ...
I wonder how host objects will deal with this.
Will there be a transitive relationship of callable
On Oct 11, 2007, at 8:02 PM, Garrett Smith wrote:
If you want to apply or call a non-function
callable, use Function.apply(callable, thisp, argArray) or
Function.call(callable, thisp, arg1, ...argN).
So these are equivalent?
aNonFunctionCallableObj()
Function.call( aNonFunctionCallableObj
On Oct 11, 2007, at 10:36 PM, Garrett Smith wrote:
So that that's out of scope for ES4; it's OK for host objects to have
custom behavior.
I'm afraid so, but we could say that host objects that are callable
SHOULD be functions if they appear to be functions otherwise; we
could say that all
On Oct 16, 2007, at 8:19 AM, Dave Herman wrote:
But that's not what you proposed, is it? I understood your proposal to
mean something more like:
function f(g) {
if (let (tmp = g())// case g():
(tmp is RegEx ? tmp.match(x) : x == tmp))
if
}
Dave
Right,
I know of two industry-scale implementations under way, in addition
to Mozilla's Tamarin project, and Michael O'Brien (mbedthis.com), all
implementing ES4 in the next six to nine months. There's no reason,
zero, apart from will to do something else, why Microsoft (which has
enormous
On Oct 22, 2007, at 4:53 AM, P T Withington wrote:
String has its uses, not just embedded in content that requires
compatibility: string and String inter-convert, String is non-final,
and the two share a prototype object.
I think Dylan would have made String an open subclass of the sealed
On Oct 26, 2007, at 12:48 PM, Darryl wrote:
I think it'd be interesting and useful to have some
way to have units of measure as part of the structure
of a number.
See http://www.mozilla.org/js/language/old-es4/rationale/units.html
(and everyone, please help disambiguate by using program
On Oct 26, 2007, at 5:11 PM, James Clark wrote:
Calling the second relationship like seems strange to me. An
object that stands in the strong relationship to a type is just as
like the type as an object that stands in the weak relationship.
The canonical term (both in theory and in real
On Oct 27, 2007, at 8:00 AM, Scott Elcomb wrote:
Hi all,
First off, I'd like to say thanks for all the good questions and
answers from folks on the list. I haven't been here long, but have
already learned a bunch. Looking forward to ES4.
Thanks. Here's hoping ES4 as proposed is not quashed
On Oct 27, 2007, at 3:38 PM, Scott Elcomb wrote:
Not sure if you're active on Slashdot or not. Would you mind if I
attached your message to the /. thread? (I won't post it without
permission, and will mention with permission if it's provided.)
You could instead hyperlink to:
On Oct 28, 2007, at 5:45 AM, David Teller wrote:
Hi list,
After reading the Outline document, I find myself wondering if
there's
a way to provide a type without any method for the user to manually
create an inhabitant of that type ?
A class with a private constructor. See
On Oct 28, 2007, at 4:39 PM, Dan Scott wrote:
Ah, fabulous - it seems that although the term sprintf appears in
the wiki, it's highlighted and therefore doesn't turn up in a
search for the term. And I was too dumb to search for string
format -- thanks for letting me know that the issue
On Oct 29, 2007, at 10:56 AM, Yehuda Katz wrote:
Is there any reason browser vendors couldn't continue to ship the
old ES3 interpreter, and make it available for script type=text/
javascript and make ES4 available for script type=application/
javascript or script type=application/es4.
On Oct 30, 2007, at 12:55 PM, Yehuda Katz wrote:
After playing with the ES4 RI yesterday, my biggest concern comes
from the handling of various number types as compared to other types:
* Literal numbers become ints, rather than Numbers. While ES4 is
still compatible with ES3 via some
On Oct 31, 2007, at 9:55 AM, Kris Zyp wrote:
, and this sandboxed eval, with the getters and setters of ES4,
developers can create safe sandboxes with host object wrappers with
fine grained access control to enable cross site scripts to be
loaded and executed with controlled limited
On Nov 2, 2007, at 2:40 PM, Yuh-Ruey Chen wrote:
Lastly, all this accusations concerning intentions need to stop.
In the absence of technical arguments, these are inevitable.
Mozilla, this concerns you too - I find that saying you won't let big
bully MS block ES4 is somewhat hypocritical,
On Nov 10, 2007, at 5:17 PM, Garrett Smith wrote:
I know it's too late for a proposal, but I keep wanting a couple of
things for AOP stuff.
One is a newApply
Creational = {
getByNode : function(el){
if(!this.hasOwnProperty(instances)) this.instances = {};
return
method to the class object for other purposes
in the future)
The last point is significant.
/be
On Nov 10, 2007, at 7:19 PM, Michael O'Brien wrote:
Brendan,
I didn't see the reflect namespace documented in the overview.
Can you please provide some pointers to its doc?
Michael
Brendan
On Nov 10, 2007, at 8:00 PM, Mark Miller wrote:
* To prevent these new keywords breaking ES3 compatibility, these
keywords are only recognized when a version attribute on the script
tag says the script is in ES4.
This has happened before, FYI -- from ES1-3 under various vendor
On Nov 10, 2007, at 9:03 PM, Yuh-Ruey Chen wrote:
I see. I wonder if this can somehow be extended so that it works on
non-structural types as well. For example, to initialize a Map, you
could use {a: 0, b: 1, c: 2} : Map, instead of Map({a:0, b:1, c:2}).
Perhaps it would map onto the |meta
On Nov 10, 2007, at 10:08 PM, Brendan Eich wrote:
On Nov 10, 2007, at 9:52 PM, Mark Miller wrote:
I'm using with here only as an example, to try to understand the
nature of the compatibility constraints on the ES4 process.
Compatibility imposes footprint costs, but it also creates
On Nov 10, 2007, at 9:57 PM, Brendan Eich wrote:
If I understand your point, it's that if we allow
(a is T)
given a type name T bound by a type, class, or interface definition;
but we disallow
let (t = T) (a is t)
and insist on
let (t = T) (a is type t)
Make that
let (t
there was confusion.
We could just remove spec: at some point. The plan is not to use
dokuwiki for actual spec production, since it isn't rich enough to
generate the final Ecma or ISO spec format.
/be
On Nov 10, 2007, at 10:51 PM, Yuh-Ruey Chen wrote:
Brendan Eich wrote:
I'm going to summon Graydon
On Nov 11, 2007, at 4:11 AM, liorean wrote:
On 11/11/2007, Jonathan Watt [EMAIL PROTECTED] wrote:
I've noticed that rounding in the reference implementation is
implemented using
IEEE roundTiesToEven, but in browsers .5 values appear to round
towards zero.
Although roundTiesToEven is
On Nov 11, 2007, at 4:26 PM, Brendan Eich wrote:
Part of the thinking in
resolving #103 in favor of type expression on right of 'is' was to
future-proof against a world where type and value expressions are
combined somehow. I don't believe that world will come to pass,
though. If it should
On Nov 12, 2007, at 9:00 AM, Jonathan Watt wrote:
Hi,
As I understand it the reason assignment to ReadOnly properties
fails silently
is that there was no try-catch prior to ECMAScript 3.
Right. Netscape 2 reported a fatal error, but during ES1
standardization we agreed to go with
On Nov 12, 2007, at 9:34 AM, Jonathan Watt wrote:
I like the idea of a pragma more than opt-in versioning since it
can be used
in-place, and (I guess) placed before and after a section of code
to turn the
handling on then off again.
Pragmas are block-scoped, so just one should do.
On Nov 12, 2007, at 1:40 PM, YR Chen wrote:
Definitely like it. I wonder how convoluted the grammar change was
- did it require a new value_expr_no_conflicts_with_type_expr
production and all related productions/rules?
Not sure, but top-down parsers have it easy, discriminating on the
On Nov 12, 2007, at 4:01 PM, Mark Miller wrote:
To fix delete within this constraint, delete whatever in Caja
either return true or throws.
At this point, either ES4 slides down the slippery slope a bit and
courts migration pain that holds it back (we really do expect most
pages on the web
On Nov 13, 2007, at 10:40 PM, Yuh-Ruey Chen wrote:
I don't see how that's workable. I mean, technically it is, since |is|
is a runtime check. But it creates another incompatibility between
type annotations and |is|, and you seem pretty adamant to keep the two
as coherent as possible.
You're
Hey Maciej, thanks for the detailed comments. As many detailed
responses as I can muster below -- all opinions mine unless noted
(e.g. where I cite a group opinion).
On Nov 14, 2007, at 2:03 PM, Maciej Stachowiak wrote:
Goals: I strongly agree with the stated goals of compatibility and
On Nov 15, 2007, at 9:17 AM, Kris Zyp wrote:
+1 from me. One request: When a filter function is provided to
JSON.parse, I would like the filter to be called with |this|
defined to be the root object that is being created by the parsed
JSON text. Having a reference to the created root
On Nov 14, 2007, at 5:34 PM, Brendan Eich wrote:
On Nov 14, 2007, at 2:03 PM, Maciej Stachowiak wrote:
Conversions: In addition, any value in the language converts to a
member of AnyBoolean, but the conversions specified are all to the
more specific boolean type, so perhaps it should
On Nov 14, 2007, at 11:56 PM, Brendan Eich wrote:
Modula 3 had branding for making nominal types from structural
types, but going the other way, unbranding a nominal type to get
a structural type, has no precedent I know of,
Shaver pointed to generic metaprogramming using C++ templates
On Nov 19, 2007, at 7:51 AM, Garrett Smith wrote:
So... I want to iterate over the keys in a Map.
Yuh-Ruey already replied, but I just wanted to point out that this:
for (let k in map.iterator::getKeys())
print(k);
can be done simply via:
for (let k in map)
print(k)
because the
On Nov 19, 2007, at 6:45 PM, P T Withington wrote:
On 2007-11-19, at 12:40 EST, Brendan Eich wrote:
This item iteration case has no more concise form analogous to for-
each-in, because if ES4 were always to map:
for (let [k, v] in map) ...
to:
for (let [k, v] in map.iterator::getItems
On Dec 13, 2007, at 3:09 PM, Nathan de Vries wrote:
On Thu, 2007-12-13 at 08:07 -0800, Michael O'Brien wrote:
I believe this is an important issue that will force non-standard
implementations...
On the same topic, it seems that Adobe are planning on introducing the
decimal type into the
On Dec 13, 2007, at 11:42 PM, Lars T Hansen wrote:
I believe let function is broken in the RI (it has been in the
past).
I encouraged Michael to file a trac ticket, and he did:
http://bugs.ecmascript.org/ticket/337
Anyone else who finds an RI bug and can't see a report of it in the
On Dec 14, 2007, at 12:50 PM, P T Withington wrote:
On 2007-09-23, at 14:14 EDT, Brendan Eich wrote:
The reason for the original prototype-owned constructor was to afford
a back-pointer from prototype to constructor function without
imposing a per-instance property (which could be optimized
On Dec 21, 2007, at 7:33 AM, StevenLevithan wrote:
Yes, its easy to pull off oneself, so I don't care much other way.
Still, it
seems pretty weird to me to be able to do ``regex(str)`` but not
``regex.call(context, str)``. This is accentuated when typeof returns
function for regexes
On Dec 24, 2007, at 8:44 AM, StevenLevithan wrote:
(I emailed this to the list last night, but it doesn't seem to have
gone
through. Sorry if this becomes a dupe.)
(I don't see a moderator request based on your sending from a
different e-mail address -- I don't see a dup either.)
Given
On Jan 3, 2008, at 9:36 AM, Igor Bukanov wrote:
On 03/01/2008, Brendan Eich [EMAIL PROTECTED] wrote:
let (f = function() { ... f() ... }) { ... }
The call to f within itself always refers to itself.
I do not see how ES3 is relevant to this second case.
Oops, sorry -- pre-caffeine here. I
On Jan 3, 2008, at 9:58 AM, Igor Bukanov wrote:
On 03/01/2008, Brendan Eich [EMAIL PROTECTED] wrote:
let function f() { };
I missed that if so -- did you see this in the wiki, a trac ticket,
or another doc?
I have not seen this, I just assumed for some reasons that syntax for
let blocks
On Jan 3, 2008, at 11:41 AM, Igor Bukanov wrote:
So one way or another the symmetry is broken meaning an extra
complexity for the implementations and extra rules for a user to
learn.
This asymmetry exists with let declarations vs. blocks/expressions:
// outer x may be bound here
{
...
On Jan 18, 2008, at 9:36 PM, Peter Michaux wrote:
Will proper tail calls be implicit in ES4 or will there be a need for
special syntax? I hope it is just a required optimization but then I
read this ticket
http://bugs.ecmascript.org/ticket/323
and it seems there is a suggestion that the spec
On Jan 19, 2008, at 12:31 AM, Peter Michaux wrote:
It seems like having types in ES4 is adding quite a bit of difficulty
to when a proper tail call can occur. The Scheme folks don't have to
deal with that, I suppose.
Contract systems in Scheme may use space, so this is a problem that
has
On Jan 20, 2008, at 5:22 PM, Erik Arvidsson wrote:
My concern with E (or A for that matter) is that it requires
additional syntax. I'd prefer if we could keep the syntax small. I
don't think implicit PTC is an issue. It is an optimization that the
interpreter/compiler should do. What are
On Jan 21, 2008, at 1:11 PM, Jeff Dyer wrote:
On 1/21/08 12:35 PM, Brendan Eich wrote:
So the axes of disagreement seem to me to be:
We need to agree on the primary purpose of proper tail calls. I say
it is
portability of code, and that all other concerns do not have enough
weight
On Jan 21, 2008, at 8:12 PM, Maciej Stachowiak wrote:
On Jan 18, 2008, at 10:49 PM, Brendan Eich wrote:
If, in order make the presence of an explicit form convenient, we
have to add sugar for it as an additional form of expression-closure
-- goto call-expr() means {goto call-expr();} -- I
On Jan 21, 2008, at 10:50 PM, Brendan Eich wrote:
return might be a
good choice of syntax if it weren't for the implicit conversion
problem.
It would, indeed: return and yield would both then be low-precedence
unary operators.
(Low-level grammatical quibble with myself, probably only
On Jan 21, 2008, at 5:26 PM, Peter Hall wrote:
Thanks. That would work. But I can still see the average user being
confused when debugging, and not knowing what is going on.
Would you think an explicit keyword syntax for mandatory tail call
would help such a user?
To the claim that
On Jan 21, 2008, at 11:37 PM, Maciej Stachowiak wrote:
What I meant to point out is that the motivating use case for
additional up-front checking can't in general be checked until
runtime, which somewhat undermines the point you made that many non-
tail cases could be caught at compile
On Jan 22, 2008, at 7:45 AM, Neil Mix wrote:
Thanks. That would work. But I can still see the average user
being
confused when debugging, and not knowing what is going on.
Would you think an explicit keyword syntax for mandatory tail call
would help such a user?
I do.
Others argue that
On Jan 22, 2008, at 11:03 AM, Neil Mix wrote:
I also want to make clear: this isn't about debugging code that uses
PTC intentionally -- that tradeoff is up to the developer. This is
about the novice coder who finds a stack trace on a production system
from code that he doesn't own which just
On Jan 22, 2008, at 11:27 AM, Thomas Reilly wrote:
Depends on what you mean by meaningful stack trace. Do you actually
want to see the same function name repeated N times for each
invocation?
I would think not, I would just come up with some notation to decorate
the stack trace.
Tail
On Jan 22, 2008, at 12:14 PM, Lars T Hansen wrote:
Ergo some implementations will have this
improvement; users will start depending on it; other implementations
will follow; and the explicit syntax is useful *only* as an assert
that the tail call can in fact take place, and will be useful
Yes, but there have been hot flame wars (probably still burning)
about the advisability of setting reply-to-list. I'm not in favor
myself. Is this a big problem, or only a sporadic nuisance (possibly
much less of a problem than the reverse: private replies
inadvertently going to the list).
On Feb 1, 2008, at 5:28 PM, Mark Filipak wrote:
Mr. Eich: Thank you for your suggestion. Unless I've been spending
time with Mescalito, to implement
getFirstChildOfElement(Papa).withTagName('baby'),
since it has no idea which child is targeted, the first function
would have to return
On Feb 5, 2008, at 3:45 PM, Garrett Smith wrote:
if(a) {
function b(){ }
}
A block can contain statements. A statement can't start with the
function keyword.
Mozilla's Core JavaScript guide explains that of |b| should be
evaluated as a functionExpression, but this isn't right.
Source:
On Feb 13, 2008, at 3:46 PM, Peter Hall wrote:
- Union types are spelled (x|y|z) now, not (x,y,z).
Popularity contest, the pipe character won.
Didn't notice that change! (and I like it :))
Popularity, but deeper reasons include (a) more future-proof; (b)
precedent from other PLs.
poor old comma, which might want to be used for something
tuple-ish.
/be
Peter
On Feb 13, 2008 11:48 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Feb 13, 2008, at 3:46 PM, Peter Hall wrote:
- Union types are spelled (x|y|z) now, not (x,y,z).
Popularity contest, the pipe
On Feb 20, 2008, at 10:17 AM, Kris Zyp wrote:
Is there any way this compatibility can be mitigated? I am assuming
there is
no conceivable way to actually replace methods ad-hoc with arbitrary
functions and retain sane typing and class expectations.
I'm not sure why you assume this. Latest
On Feb 20, 2008, at 1:00 PM, Adam Peller wrote:
Each of us has some pet addition we think would be a great
addition to
the language. const, decimal, getters and setters, destructing
assignment -- all these have come up just this morning!. Each of
these
makes the language larger and more
On Feb 20, 2008, at 3:42 PM, Kris Zyp wrote:
I thought the question was about annotating class fixtures?
Yes, that was my intent, sorry I wasn't clearer.
No problem, sorry for assuming you meant ES3-compatible code.
I knew that built-ins were
designed to be backwards compatible. I don't
On Feb 20, 2008, at 4:21 PM, Kris Zyp wrote:
Of course a library function (like dojo.connect) that is called to
advise a
method on an object doesn't have control of how the object was
created. If
it is an instance of user class (and not dynamic), this function
will this
fail. This
There's a lot of implicit context here, some of which may be new to
es4-discuss readers. Also, not everything here is bound to become an
Ecma standard, as noted in mail I sent earlier today (3.1 could be a
TR and should be in the view of some on the TC39 committee). Comments
inline below,
On Feb 20, 2008, at 6:10 PM, Mike Samuel wrote:
JSON ⊂ ADsafe ⊂ Cajita ⊂ Caja ⊂ ES3 ⊂ ES4
People who know Unicode are dangerous ;).
Yes, we need more of you ;-).
There's three problems according to my reading of http://
www.ietf.org/rfc/rfc4627.txt but only the first is directly
On Feb 20, 2008, at 1:25 PM, Mark S. Miller wrote:
What numbers are representable as double but not decimal?
Mike Cowlishaw's page at http://www2.hursley.ibm.com/decimal/ is
extremely informative, especially http://www2.hursley.ibm.com/decimal/
decifaq.html; see also the link to
On Feb 21, 2008, at 1:25 AM, Mike Cowlishaw wrote:
Separately from the decimal discussion, I am a bit confused at how
ES3.x
or ES4 is migrated to from ES3. If the syntax cannot change then that
implies that the semantics change without any indication in the
syntax.
ES4 has new syntax;
On Feb 21, 2008, at 7:47 AM, Neil Mix wrote:
Another thought: does ES4 provide enough introspection capability to
write proxy objects that wrap an immutable class instance? It seems
as though it should be possible to create a single class (with *
getter/setter functions) that can wrap any
On Feb 21, 2008, at 12:48 PM, Geoffrey Garen wrote:
I'd like Apple and the WebKit project to get involved with ES4
implementation. But right now, as far as I can tell, there isn't a
written record for any of ES4's features that I could point an
engineer to and say implement this.
There's
On Feb 21, 2008, at 5:49 PM, Maciej Stachowiak wrote:
On Feb 21, 2008, at 5:03 PM, Graydon Hoare wrote:
So presenting yourself as a participant with neither of those
supports in place, you're sort of walking into a room, kicking the
legs out from under a table and asking why it's suddenly
On Feb 21, 2008, at 2:24 PM, Maciej Stachowiak wrote:
On Feb 21, 2008, at 10:41 AM, Brendan Eich wrote:
We'd like to be active participant. However, it seems like as
newcomers/outsiders, we do not have enough information available
to participate in early implementation.
Neither does
On Feb 19, 2008, at 6:39 PM, Graydon Hoare wrote:
Finally there is a category I left off the above elaboration, mostly
because it is under-developed in the RI: control mechanisms. There are
dependencies between tail calls, generators and stack inspection,
and I
can't say I fully understand
On Feb 21, 2008, at 11:40 PM, Michael O'Brien wrote:
The reason is we could remove a few road blocks with some design
notes.
These won't be as complete as the spec but could from the basis of
writing some of the spec prose.
Ok.
Also, the spec can reference the RI (not just SML but, for
On Feb 25, 2008, at 5:58 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
Thanks for understanding. Now with that in mind, please re-read
Jeff's
post and mine. We are talking about working intensively in the next
three months on both specs and implementation. Now is the time to
step
up
On Feb 27, 2008, at 5:33 AM, Lars Hansen wrote:
None of the above speaks to the possibility that decimal might be
a distinct data type in the language, of course, along with
double and int and uint. Such a data type would in our
opinion not be a poor fit for ES4, and as your own
On Feb 27, 2008, at 9:00 AM, Lars Hansen wrote:
Meta-level methods
The predefined namespace meta is used for methods that
participate in
language-level protocols: invocation and property access and
update. A
class that defines meta::invoke is callable as a function (the
meta::invoke
On Feb 27, 2008, at 10:40 AM, Brendan Eich wrote:
First, nothing's ruled out -- you're asking the wrong guy if you
want Adobe's position, but see Lars's reply to Mike Cowlishaw:
decimal as a type without any implicit literal/operators mode is
still possible,
I should have written without
On Feb 27, 2008, at 3:59 PM, Waldemar Horwat wrote:
I'd like write access to the spreadsheet so we can fill in the
Google column:
http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQgid=2
Also, some features have been omitted from the spreadsheet, such as
tuple types. Are
1 - 100 of 252 matches
Mail list logo
