Sorry for seeing this thread so late. I am the maintainer of Traceur at the moment.
We do want Traceur to align with the ES6 draft and with Harmony proposals. Any missmatch is a bug and both bug reports and patches are welcome. The reason a lot of the generated code depends on a runtime library is mostly because it makes code size smaller (but it also makes generating the code easier). We should make it optional to include the required runtime functions in the generated code at least. On Tue, Oct 11, 2011 at 11:57, Jake Verbaten <[email protected]> wrote: > > > On Tue, Oct 11, 2011 at 7:40 PM, John J Barton <[email protected]> > wrote: >> >> >> On Tue, Oct 11, 2011 at 11:14 AM, Brendan Eich <[email protected]> >> wrote: >>> >>> On Oct 11, 2011, at 1:47 PM, John J Barton wrote: >>> >>> On Tue, Oct 11, 2011 at 10:08 AM, Brendan Eich <[email protected]> >>> wrote: >>>> >>>> On Oct 11, 2011, at 12:49 PM, John J Barton wrote: >>>> >>>> > We don't know what the standard will be so we need some why to try out >>>> > different features. >>>> >>>> That's not how the committee has worked since 2008, and even before then >>>> (pre-Harmony), with a split committee, we still had two groups working on >>>> consensus by drafting proposals and prototyping them. >>>> >>>> The way we try to work is to propose before implementing, including >>>> prototype features. Individual vendors don't deviate from proposals >>>> unilaterally and silently. >>>> >>>> If old proposals were implemented, and then the proposals changed, we >>>> may have some work to do adjusting implementations (certainly true of >>>> SpiderMonkey, and we will do it). But we do not go off on our own, as >>>> individual vendors, and try out features never proposed on the wiki. >>> >>> You're making something out of nothing. >>> >>> Somehow I suspect the shoe would be on the other foot if other vendors >>> did likewise. >>> But I'm tired of arguing in favor of keeping consensus. If it's not >>> important, let's all go off and run our own experiments and see what >>> happens. Biggest company wins, best two out of three in case of a >>> order-of-magnitude market cap tie :-P. That will be fun. >>> >>> If you have a beef with how Google works with the committee, then >>> contact a Google rep on the committee and complain to them. >>> >>> I already have, but that's not the topic here: you just wrote "We don't >>> know what the standard will be so we need some why to try out different >>> features" (cited above) and I wrote back arguing with you, not with anyone >>> else. >>> >>> But don't paint the Traceur project as some weird plot to derail your >>> work. >>> >>> I never said anything like that ("weird plot" -- come on!). I don't know >>> why Traceur was developed the way it was, and then abandoned (I have some >>> theories, but really, who cares?). >>> Maybe it's someone else's turn to maintain Traceur, and Google has done >>> its fair share. The problem is no one else knows the code and Jake said he >>> got no response when he asked (but maybe he asked in the wrong channel or >>> something). It's hard for others to pick up where things left off. >> >> I have quite a lot of first hand experience in picking up where things >> left off. No question it's hard, but you may get further by building on >> Traceur rather than starting over. >> >>> >>> >>> It's just like a thousand other open source projects, a risky labor of >>> love, a gift to the community of engineers. >>> >>> There is a lot of abandon-ware in open source, but that's a very low bar >>> to meet. >>> >>> Well we don't have a Mark and Tom for Traceur. We just have some great >>> source code. If anyone here wants to try to match Traceur up to Ecma >>> consensus, please step up. >>> >>> So you, another Googler, exhort anyone, or Jake, to "fix it" and "step >>> up" (but thanks for the "please" the second time :-/). >>> I think it's fair to ask why anyone would do that, instead of choosing to >>> work on other projects that seem to have active maintainers and open source >>> communities going back to their genesis. >> >> Juan asked about Traceur. Advocates for other projects can reply if they >> like. >> >>> >>> Beyond this, I'm still picking a fight with your "We don't know what the >>> standard will be so we need some why to try out different features" line, >>> which you have not defended. But we can table that, or forget about it if >>> you prefer. >> >> Well we don't know what the standard will be, that's just a fact. I happen >> to think that one needs to gain experience with language features by trying >> them out. I know you have a lot of experience so perhaps you don't need this >> step. I totally don't understand why you want to prevent Juan or Jake from >> trying out ideas related to JS. >> >>> >>> Something's wrong here. Jake cited specific concerns about Traceur and >>> got a lecture to be grateful for it being open source, and to get to work >>> fixing it. Is that really the best answer? >> >> I'm sorry if I came across as lecturing. I was taken aback by Jake's >> puzzling comments. I was just trying to being things back to reality. >> Traceur seems like a useful bit of code; it does not look like it will be >> maintained by the original authors. I was trying to encourage Jake and Juan >> to participate in taking it forward. >> > > +1 for encouraging participation, traceur may be good starting point. > >>> >>> /be >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- erik _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
