Brendan Eich wrote:
I want to say thanks for making this proposal (open namespace search
only for lexical references). It leaves most of the use-cases I cited
intact. Well done, good compromise (not complete evisceration of
property qualifiers, or dismissal of unqualified import).
Jeff Dyer wrote:
Works for me in the RI:
var x = 10; var x = 20; print(x)
20
As it should.
Could be an old build? Check one of the snapshots.
http://buildbot.ecmascript.org/es4/waterfall
-Graydon
___
Es4-discuss mailing list
ToolmakerSteve98 wrote:
Wondering if there is any info beyond the source itself that would give me a
big picture view of what is there, before I start wandering around in the
depths of the code.
Not a lot, though I've posted some notes to this list in the past; I'm
happy to discuss it
Peter Hall wrote:
I have a few questions/comments about parametrized types. Some I know
has been discussed, but I still unclear on the outcome of those
conversations.
Good questions!
1. If there is a type T.J,K, can T be referenced itself, or must it
be referenced for some specific values
Maciej Stachowiak wrote:
To expand a bit on Geoff's comment:
I'd like Apple and the WebKit project to get involved with ES4
implementation.
Great! Though please keep in mind a point in the remainder of your
comments: WebKit (and Rhino) are operating from a somewhat newcomer
perspective,
Michael O'Brien wrote:
As a solution: I think we need an intermediate step. Not a spec, but
some detailed design notes. Lar's document was a good
overview, but drill down on exactly how the mechanisms are meant to work
would be very helpful to broaden the base of
implementations. Some
Maciej Stachowiak wrote:
I don't think the sets are disjoint, but they are not identical either.
Agreed. I am trying to arrive at an understanding of which camp Apple
aspires to (designer, implementor or both) and in particular how you
wish to enact that role. Any Rhino hackers (or other
Maciej Stachowiak wrote:
What I am asking is this: for each proposal where you'd like early
implementations, before implementation commences please write down
enough information about that proposal in some reasonably understandable
form to represent the current shared understanding of the
Maciej Stachowiak wrote:
We're unlikely to have much interest in working on implementing the RI.
Ok. I'm sorry to hear that, but I understand.
As for reading the RI, it seems a lot harder to understand than specs
written in prose. As far as I can tell, only people who have coded
Michael O'Brien wrote:
Graydon,
Thanks -- that helps to understand the status.
You are in a somewhat unique position having implemented more than any
other. Given Jeff's roadmap outline and the goal of weighing the
features against implementation experience -- which of the features that
Hi,
Dave Herman has prepared some new binary builds of the the ES4 RI and
made them available for download at:
http://www.ecmascript.org/download.php
Please report any bugs you find in this release with the ES4 bug
tracking system, and we'll endeavor to fix them:
Igor Bukanov wrote:
I am saying that even for calls in the tail position an implementation
may not eliminate the parent frame completely as it still may be
exposed via closures. As such the tail call optimization cannot
guarantee that the space complexity of the tail recursion is O(1).
This
Jonathan Watt wrote:
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 desirable
Brendan Eich wrote:
let q = {p:42} : {p:int}
[stack] [init q()]
**ERROR** EvalError: typecheck failed, val=obj type={p: [ns public
'__ES4__']::int } wanted={p: [ns public '__ES4__']::int } (near no
filename:1:1-1.3)
The val and wanted parts of the diagnostic look the same to me.
Yuh-Ruey Chen wrote:
I'm not sure how to phrase this, but it seems to me that ES4 is trying
to make fixed properties and non-fixed properties (and by extension,
type expressions and value expressions, and compile-time features and
run-time features) as similar and compatible as possible (e.g.
Brendan Eich wrote:
But again, two engines don't cut it, for footprint and memory
reasons. And two engines are intentionally unnecessary by the design
of ES4.
(Catching up on this thread...)
An additional technical aspect of the language, for newcomers who may
not have noticed it:
It
16 matches
Mail list logo
