Re: Quasis: assignable substitutions?

On Sat, Jun 18, 2011 at 5:59 PM, Mike Samuel wrote: [...] > >> What idiom should quasi handler authors use to distinguish a writable > >> slot from a read-only slot? > [...] > By read-only slot vs read-write slot I meant > > example` > ${x} is read only > ${=y} is read-write > ` > > I should h

Re: block lambda proposal in light of compiling to JavaScript

So one thing that lambda really helps with, and where TCP is a serious practical issue and not just philosophical, is macros. Macros need the ability to create new kinds of control flow by taking expressions and reordering and delaying them. You can use 'function' for this but you don't want th

Re: Quasis: assignable substitutions?

2011/6/18 Mark S. Miller : > On Sat, Jun 18, 2011 at 10:53 AM, Mike Samuel wrote: >> >> 2011/6/17 Mark S. Miller : > > [...] >> >> >     "${x}" continue to expand to "x", as in the current not-slotified >> > proposal. >> >     "${=x}" expand to >> >     ice9({ >> >         get: function() { return

Re: [Harmony Proxies] Proposal: Property fixing

Le 19/06/2011 00:30, Mark S. Miller a écrit : > Hi David, yes, that code is just a stale illustrative example. This > abstraction itself is not being used, and the code predates many > changes to the proxy API that render it invalid. And even then, it was > sloppy in ways you point out, e.g, regard

Re: block lambda proposal in light of compiling to JavaScript

On Jun 18, 2011, at 1:50 PM, Brendan Eich wrote: > On Jun 18, 2011, at 1:02 PM, Peter Michaux wrote: >> So what can be done to help move the block lambda proposal towards Harmony? > > To me the biggest obstacle is the meta-point about "OMG too different" > regarding return, break, and continue h

Re: [Harmony Proxies] Proposal: Property fixing

Hi David, yes, that code is just a stale illustrative example. This abstraction itself is not being used, and the code predates many changes to the proxy API that render it invalid. And even then, it was sloppy in ways you point out, e.g, regarding enumerability. However, it is a good example of t

Re: [Harmony Proxies] Proposal: Property fixing

Le 18/06/2011 05:35, Mark S. Miller a écrit : > An even better example where Tom and I used these invariants, even if > only for an illustrative example, is > . > The old text at the bottom of this old code says: >

Re: block lambda proposal in light of compiling to JavaScript

On Jun 18, 2011, at 1:02 PM, Peter Michaux wrote: > Drawing the line in the right place is important of course. I was > trying to contribute to the case that drawing the line with lambdas in > would be beneficial to some and perhaps a growing group in the future. If you wrote "might" instead of "

Re: Prototypes as the new class declaration

On Jun 18, 2011, at 12:51 PM, Juan Ignacio Dopazo wrote: > I see the value in the <| operator in that it deals with any object. But I > think the prototypes as classes idea is focusing on creating an object that > describes a prototype and creating a constructor under the hood. No, not under th

Re: block lambda proposal in light of compiling to JavaScript

On Sat, Jun 18, 2011 at 1:02 PM, Peter Michaux wrote: [...] > So what can be done to help move the block lambda proposal towards Harmony? > Accumulating more arguments in its favor, as you are attempting to do in this thread, and answering arguments against. The gate is achieving consensus among

Re: Quasis: assignable substitutions?

On Sat, Jun 18, 2011 at 10:53 AM, Mike Samuel wrote: > 2011/6/17 Mark S. Miller : > [...] > > "${x}" continue to expand to "x", as in the current not-slotified > > proposal. > > "${=x}" expand to > > ice9({ > > get: function() { return x; }, > > set: function(newVal)

Re: block lambda proposal in light of compiling to JavaScript

On Sat, Jun 18, 2011 at 11:53 AM, Brendan Eich wrote: > On Jun 18, 2011, at 10:33 AM, Peter Michaux wrote: > Yet CoffeeScript does not need lambdas with TCP control effects today. It > translates in a straightforward (mostly) "transpiling" way. Even its > expression-language mapping of statements

Re: Prototypes as the new class declaration

I see the value in the <| operator in that it deals with any object. But I think the prototypes as classes idea is focusing on creating an object that describes a prototype and creating a constructor under the hood. This functionality can already be implemented in ES5 (see https://gist.github.com/1

Re: block lambda proposal in light of compiling to JavaScript

On Jun 18, 2011, at 10:33 AM, Peter Michaux wrote: > Recently, I've invested time looking at current > compiling-to-JavaScript developments. Although people have been doing > this for many years now, it seems CoffeeScript is making it clear that > being a target of compilation is at least part of

Re: Prototypes as the new class declaration

On Jun 18, 2011, at 10:30 AM, Axel Rauschmayer wrote: >> Now, we could have a "second protocol" as Irakli's gists show. He wires up >> both per-instance and "static" (ugh, I mean constructor-side) 'new' methods >> that bottom out by calling the constructor. This is not quite the second >> proto

Re: Prototypes as the new class declaration

On Jun 18, 2011, at 8:53 AM, Axel Rauschmayer wrote: >>> Where would the prototype of the new instance come from? Would >>> SkinnedMesh.constructor.prototype point to SkinnedMesh? >> >> Of course -- Allen's proposal just "rotates" the (constructor, prototype) >> pair so the named or "outer" obj

Re: Quasis: assignable substitutions?

2011/6/17 Mark S. Miller : > On Fri, Jun 17, 2011 at 1:50 PM, Mike Samuel wrote: >> >> 2011/6/17 Mark S. Miller : >> > A failed strict assignment throws, and therefore a failed ES-next >> > assignment >> > does. So are you sure it does not currently throw? From your expansion, >> > I'd >> > expect

block lambda proposal in light of compiling to JavaScript

Recently, I've invested time looking at current compiling-to-JavaScript developments. Although people have been doing this for many years now, it seems CoffeeScript is making it clear that being a target of compilation is at least part of JavaScript's future. The pending additions in browsers of su

Re: Prototypes as the new class declaration

> Now, we could have a "second protocol" as Irakli's gists show. He wires up > both per-instance and "static" (ugh, I mean constructor-side) 'new' methods > that bottom out by calling the constructor. This is not quite the second > protocol you proposed that we agreed would be less desirable, al

Re: Prototypes as the new class declaration

On Tue, Jun 14, 2011 at 10:08 PM, Allen Wirfs-Brock wrote: > The correspondence is even closer if we slightly extend the new operator. > Using current new operator semantics and my alternative way of defining > SkinnedMeesh and then executing: > > let aSM = new SkinnedMesh(aGeo, aMat); > > we

Re: Prototypes as the new class declaration

>> Where would the prototype of the new instance come from? Would >> SkinnedMesh.constructor.prototype point to SkinnedMesh? > > Of course -- Allen's proposal just "rotates" the (constructor, prototype) > pair so the named or "outer" object is the prototype. > > This matches the syntax. It's a

Re: Prototypes as the new class declaration

> Now consider rewriting using proposed object literal extensions as: > > const SkinnedMesh = THREE.Mesh <| { > constructor(geometry, materials) { > super.constructor(geometry, materials); > > this.identityMatrix = new THREE.Matrix4(); > this.bones = []; > this.boneMatrices = [