That hash symbol

classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

That hash symbol

Kevin Smith-21
As a simple matter of taste, I find the # symbol to be quite ugly and have been thinking of alternatives for shortening function expression syntax.

In working with my own wonky version of promises, I continue to make the same typing error over and over again.  This is something like what I mean to type:

obj.doSomething().then(function(val, err)
{
    ...
});

But I find myself typing this instead:

obj.doSomething().then(val, err)
{
    ...
});

The problem isn't so much the extra typing of the "function" keyword, but the profusion of parens.  I'd like to suggest the following form instead.

obj.doSomething().then(<val, err>
{
    ...
});

Correct me if I'm wrong, but since expressions cannot start with "<", this shouldn't present any problems for a top-down parser.  Is that right?

Thanks,
khs




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Mike Samuel
2011/3/25 Kevin Smith <[hidden email]>:

> As a simple matter of taste, I find the # symbol to be quite ugly and have
> been thinking of alternatives for shortening function expression syntax.
> In working with my own wonky version of promises, I continue to make the
> same typing error over and over again.  This is something like what I mean
> to type:
> obj.doSomething().then(function(val, err)
> {
>     ...
> });
> But I find myself typing this instead:
> obj.doSomething().then(val, err)
> {
>     ...
> });
> The problem isn't so much the extra typing of the "function" keyword, but
> the profusion of parens.  I'd like to suggest the following form instead.
> obj.doSomething().then(<val, err>
> {
>     ...
> });
> Correct me if I'm wrong, but since expressions cannot start with "<", this
> shouldn't present any problems for a top-down parser.  Is that right?

Does this cause ambiguities with E4X ?  https://developer.mozilla.org/en/e4x

> Thanks,
> khs
>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Kevin Smith-21
Oh, boogers!  : )


On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel <[hidden email]> wrote:
2011/3/25 Kevin Smith <[hidden email]>:
> As a simple matter of taste, I find the # symbol to be quite ugly and have
> been thinking of alternatives for shortening function expression syntax.
> In working with my own wonky version of promises, I continue to make the
> same typing error over and over again.  This is something like what I mean
> to type:
> obj.doSomething().then(function(val, err)
> {
>     ...
> });
> But I find myself typing this instead:
> obj.doSomething().then(val, err)
> {
>     ...
> });
> The problem isn't so much the extra typing of the "function" keyword, but
> the profusion of parens.  I'd like to suggest the following form instead.
> obj.doSomething().then(<val, err>
> {
>     ...
> });
> Correct me if I'm wrong, but since expressions cannot start with "<", this
> shouldn't present any problems for a top-down parser.  Is that right?

Does this cause ambiguities with E4X ?  https://developer.mozilla.org/en/e4x

> Thanks,
> khs
>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

David Foley-2
Implicit functions?


globalMethod(argument)
{
    // implementation
};

AnObject.prototype.method(value)
{
    // whatevs
};

On 25 Mar 2011, at 17:28, Kevin Smith <[hidden email]> wrote:

Oh, boogers!  : )


On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel <[hidden email]> wrote:
2011/3/25 Kevin Smith <[hidden email]>:
> As a simple matter of taste, I find the # symbol to be quite ugly and have
> been thinking of alternatives for shortening function expression syntax.
> In working with my own wonky version of promises, I continue to make the
> same typing error over and over again.  This is something like what I mean
> to type:
> obj.doSomething().then(function(val, err)
> {
>     ...
> });
> But I find myself typing this instead:
> obj.doSomething().then(val, err)
> {
>     ...
> });
> The problem isn't so much the extra typing of the "function" keyword, but
> the profusion of parens.  I'd like to suggest the following form instead.
> obj.doSomething().then(<val, err>
> {
>     ...
> });
> Correct me if I'm wrong, but since expressions cannot start with "<", this
> shouldn't present any problems for a top-down parser.  Is that right?

Does this cause ambiguities with E4X ?  https://developer.mozilla.org/en/e4x

> Thanks,
> khs
>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Mike Samuel
2011/3/25 David Foley <[hidden email]>:

> Implicit functions?
>
> globalMethod(argument)
> {
>     // implementation
> };
> AnObject.prototype.method(value)
> {
>     // whatevs
> };

Is this a proposed syntax?

If so, in the presence of semicolon insertion, isn't this ambiguous with

globalMethodCall(argument);
{
  // block
}
;  // noop
AnObject.prototype.methodCall(value);
{
  // another block
}
;  // noop


> On 25 Mar 2011, at 17:28, Kevin Smith <[hidden email]> wrote:
>
> Oh, boogers!  : )
>
> On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel <[hidden email]> wrote:
>>
>> 2011/3/25 Kevin Smith <[hidden email]>:
>> > As a simple matter of taste, I find the # symbol to be quite ugly and
>> > have
>> > been thinking of alternatives for shortening function expression syntax.
>> > In working with my own wonky version of promises, I continue to make the
>> > same typing error over and over again.  This is something like what I
>> > mean
>> > to type:
>> > obj.doSomething().then(function(val, err)
>> > {
>> >     ...
>> > });
>> > But I find myself typing this instead:
>> > obj.doSomething().then(val, err)
>> > {
>> >     ...
>> > });
>> > The problem isn't so much the extra typing of the "function" keyword,
>> > but
>> > the profusion of parens.  I'd like to suggest the following form
>> > instead.
>> > obj.doSomething().then(<val, err>
>> > {
>> >     ...
>> > });
>> > Correct me if I'm wrong, but since expressions cannot start with "<",
>> > this
>> > shouldn't present any problems for a top-down parser.  Is that right?
>>
>> Does this cause ambiguities with E4X ?
>>  https://developer.mozilla.org/en/e4x
>>
>> > Thanks,
>> > khs
>> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > [hidden email]
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Brendan Eich-3
It's totally ambiguous.

Suggestion: do not mail syntax ideas without working through (pencil and paper, Jison/Bison/Antlr/something, or better) the grammar.

More specific suggestion: don't bikeshed function syntax without a new prefix character or a convincing top-down parsing story. If you don't know what top-down vs. bottom-up means, find out first.

/be

On Mar 25, 2011, at 10:32 AM, Mike Samuel wrote:

> 2011/3/25 David Foley <[hidden email]>:
>> Implicit functions?
>>
>> globalMethod(argument)
>> {
>>     // implementation
>> };
>> AnObject.prototype.method(value)
>> {
>>     // whatevs
>> };
>
> Is this a proposed syntax?
>
> If so, in the presence of semicolon insertion, isn't this ambiguous with
>
> globalMethodCall(argument);
> {
>  // block
> }
> ;  // noop
> AnObject.prototype.methodCall(value);
> {
>  // another block
> }
> ;  // noop
>
>
>> On 25 Mar 2011, at 17:28, Kevin Smith <[hidden email]> wrote:
>>
>> Oh, boogers!  : )
>>
>> On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel <[hidden email]> wrote:
>>>
>>> 2011/3/25 Kevin Smith <[hidden email]>:
>>>> As a simple matter of taste, I find the # symbol to be quite ugly and
>>>> have
>>>> been thinking of alternatives for shortening function expression syntax.
>>>> In working with my own wonky version of promises, I continue to make the
>>>> same typing error over and over again.  This is something like what I
>>>> mean
>>>> to type:
>>>> obj.doSomething().then(function(val, err)
>>>> {
>>>>     ...
>>>> });
>>>> But I find myself typing this instead:
>>>> obj.doSomething().then(val, err)
>>>> {
>>>>     ...
>>>> });
>>>> The problem isn't so much the extra typing of the "function" keyword,
>>>> but
>>>> the profusion of parens.  I'd like to suggest the following form
>>>> instead.
>>>> obj.doSomething().then(<val, err>
>>>> {
>>>>     ...
>>>> });
>>>> Correct me if I'm wrong, but since expressions cannot start with "<",
>>>> this
>>>> shouldn't present any problems for a top-down parser.  Is that right?
>>>
>>> Does this cause ambiguities with E4X ?
>>>  https://developer.mozilla.org/en/e4x
>>>
>>>> Thanks,
>>>> khs
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

David Foley-2
>> Is this a proposed syntax?
No- It was an off the cuff reaction

> Suggestion: do not mail syntax
Noted

On 25 Mar 2011, at 17:34, Brendan Eich <[hidden email]> wrote:

> It's totally ambiguous.
>
> Suggestion: do not mail syntax ideas without working through (pencil and paper, Jison/Bison/Antlr/something, or better) the grammar.
>
> More specific suggestion: don't bikeshed function syntax without a new prefix character or a convincing top-down parsing story. If you don't know what top-down vs. bottom-up means, find out first.
>
> /be
>
> On Mar 25, 2011, at 10:32 AM, Mike Samuel wrote:
>
>> 2011/3/25 David Foley <[hidden email]>:
>>> Implicit functions?
>>>
>>> globalMethod(argument)
>>> {
>>>    // implementation
>>> };
>>> AnObject.prototype.method(value)
>>> {
>>>    // whatevs
>>> };
>>
>> Is this a proposed syntax?
>>
>> If so, in the presence of semicolon insertion, isn't this ambiguous with
>>
>> globalMethodCall(argument);
>> {
>> // block
>> }
>> ;  // noop
>> AnObject.prototype.methodCall(value);
>> {
>> // another block
>> }
>> ;  // noop
>>
>>
>>> On 25 Mar 2011, at 17:28, Kevin Smith <[hidden email]> wrote:
>>>
>>> Oh, boogers!  : )
>>>
>>> On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel <[hidden email]> wrote:
>>>>
>>>> 2011/3/25 Kevin Smith <[hidden email]>:
>>>>> As a simple matter of taste, I find the # symbol to be quite ugly and
>>>>> have
>>>>> been thinking of alternatives for shortening function expression syntax.
>>>>> In working with my own wonky version of promises, I continue to make the
>>>>> same typing error over and over again.  This is something like what I
>>>>> mean
>>>>> to type:
>>>>> obj.doSomething().then(function(val, err)
>>>>> {
>>>>>    ...
>>>>> });
>>>>> But I find myself typing this instead:
>>>>> obj.doSomething().then(val, err)
>>>>> {
>>>>>    ...
>>>>> });
>>>>> The problem isn't so much the extra typing of the "function" keyword,
>>>>> but
>>>>> the profusion of parens.  I'd like to suggest the following form
>>>>> instead.
>>>>> obj.doSomething().then(<val, err>
>>>>> {
>>>>>    ...
>>>>> });
>>>>> Correct me if I'm wrong, but since expressions cannot start with "<",
>>>>> this
>>>>> shouldn't present any problems for a top-down parser.  Is that right?
>>>>
>>>> Does this cause ambiguities with E4X ?
>>>> https://developer.mozilla.org/en/e4x
>>>>
>>>>> Thanks,
>>>>> khs
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> [hidden email]
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Kevin Smith-21
In reply to this post by Brendan Eich-3
Sure - no offense or time-wasting intended.


On Fri, Mar 25, 2011 at 1:34 PM, Brendan Eich <[hidden email]> wrote:
It's totally ambiguous.

Suggestion: do not mail syntax ideas without working through (pencil and paper, Jison/Bison/Antlr/something, or better) the grammar.

More specific suggestion: don't bikeshed function syntax without a new prefix character or a convincing top-down parsing story. If you don't know what top-down vs. bottom-up means, find out first.

/be

On Mar 25, 2011, at 10:32 AM, Mike Samuel wrote:

> 2011/3/25 David Foley <[hidden email]>:
>> Implicit functions?
>>
>> globalMethod(argument)
>> {
>>     // implementation
>> };
>> AnObject.prototype.method(value)
>> {
>>     // whatevs
>> };
>
> Is this a proposed syntax?
>
> If so, in the presence of semicolon insertion, isn't this ambiguous with
>
> globalMethodCall(argument);
> {
>  // block
> }
> ;  // noop
> AnObject.prototype.methodCall(value);
> {
>  // another block
> }
> ;  // noop
>
>
>> On 25 Mar 2011, at 17:28, Kevin Smith <[hidden email]> wrote:
>>
>> Oh, boogers!  : )
>>
>> On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel <[hidden email]> wrote:
>>>
>>> 2011/3/25 Kevin Smith <[hidden email]>:
>>>> As a simple matter of taste, I find the # symbol to be quite ugly and
>>>> have
>>>> been thinking of alternatives for shortening function expression syntax.
>>>> In working with my own wonky version of promises, I continue to make the
>>>> same typing error over and over again.  This is something like what I
>>>> mean
>>>> to type:
>>>> obj.doSomething().then(function(val, err)
>>>> {
>>>>     ...
>>>> });
>>>> But I find myself typing this instead:
>>>> obj.doSomething().then(val, err)
>>>> {
>>>>     ...
>>>> });
>>>> The problem isn't so much the extra typing of the "function" keyword,
>>>> but
>>>> the profusion of parens.  I'd like to suggest the following form
>>>> instead.
>>>> obj.doSomething().then(<val, err>
>>>> {
>>>>     ...
>>>> });
>>>> Correct me if I'm wrong, but since expressions cannot start with "<",
>>>> this
>>>> shouldn't present any problems for a top-down parser.  Is that right?
>>>
>>> Does this cause ambiguities with E4X ?
>>>  https://developer.mozilla.org/en/e4x
>>>
>>>> Thanks,
>>>> khs
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Brendan Eich-3
No problem -- just don't provoke Zeus to unleash the Crock-en ;-).


/be

On Mar 25, 2011, at 10:39 AM, Kevin Smith wrote:

Sure - no offense or time-wasting intended.


On Fri, Mar 25, 2011 at 1:34 PM, Brendan Eich <[hidden email]> wrote:
It's totally ambiguous.

Suggestion: do not mail syntax ideas without working through (pencil and paper, Jison/Bison/Antlr/something, or better) the grammar.

More specific suggestion: don't bikeshed function syntax without a new prefix character or a convincing top-down parsing story. If you don't know what top-down vs. bottom-up means, find out first.

/be

On Mar 25, 2011, at 10:32 AM, Mike Samuel wrote:

> 2011/3/25 David Foley <[hidden email]>:
>> Implicit functions?
>>
>> globalMethod(argument)
>> {
>>     // implementation
>> };
>> AnObject.prototype.method(value)
>> {
>>     // whatevs
>> };
>
> Is this a proposed syntax?
>
> If so, in the presence of semicolon insertion, isn't this ambiguous with
>
> globalMethodCall(argument);
> {
>  // block
> }
> ;  // noop
> AnObject.prototype.methodCall(value);
> {
>  // another block
> }
> ;  // noop
>
>
>> On 25 Mar 2011, at 17:28, Kevin Smith <[hidden email]> wrote:
>>
>> Oh, boogers!  : )
>>
>> On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel <[hidden email]> wrote:
>>>
>>> 2011/3/25 Kevin Smith <[hidden email]>:
>>>> As a simple matter of taste, I find the # symbol to be quite ugly and
>>>> have
>>>> been thinking of alternatives for shortening function expression syntax.
>>>> In working with my own wonky version of promises, I continue to make the
>>>> same typing error over and over again.  This is something like what I
>>>> mean
>>>> to type:
>>>> obj.doSomething().then(function(val, err)
>>>> {
>>>>     ...
>>>> });
>>>> But I find myself typing this instead:
>>>> obj.doSomething().then(val, err)
>>>> {
>>>>     ...
>>>> });
>>>> The problem isn't so much the extra typing of the "function" keyword,
>>>> but
>>>> the profusion of parens.  I'd like to suggest the following form
>>>> instead.
>>>> obj.doSomething().then(<val, err>
>>>> {
>>>>     ...
>>>> });
>>>> Correct me if I'm wrong, but since expressions cannot start with "<",
>>>> this
>>>> shouldn't present any problems for a top-down parser.  Is that right?
>>>
>>> Does this cause ambiguities with E4X ?
>>>  https://developer.mozilla.org/en/e4x
>>>
>>>> Thanks,
>>>> khs
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Kris Kowal-2
On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich <[hidden email]> wrote:
> No problem -- just don't provoke Zeus to unleash the Crock-en ;-).
> https://mail.mozilla.org/pipermail/es-discuss/2011-February/012761.html

Perhaps there needs to be a venue where non-experts can bounce ideas
and discuss points of pain with volunteering committee members to
reduce noise in this venue. There is little room here for
light-hearted discussion and mentoring for members of the community
who have less than full-time commitment and years of experience in
language design.

It's disappointing to be ostracized, but it is true. I also want to
see careful and well-wrought steady progress. I remember a former
decade when this discussion was impossible to follow, too many bad
ideas were too thoroughly discussed, and much time was wasted.

Kris Kowal
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Brendan Eich-3
Dunno. You were ravaged by the Crocken so you may be a bit sore still :-/.

Any list with informal/unsound syntax talk is not one I want to be on. It's not quite beer talk. It could lead to a breakthrough idea, who knows? But the cost is pretty high.

I'm not against syntax proposals here, mind you. Let's just work out the grammar a bit before launching.

/be

On Mar 25, 2011, at 12:09 PM, Kris Kowal wrote:

> On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich <[hidden email]> wrote:
>> No problem -- just don't provoke Zeus to unleash the Crock-en ;-).
>> https://mail.mozilla.org/pipermail/es-discuss/2011-February/012761.html
>
> Perhaps there needs to be a venue where non-experts can bounce ideas
> and discuss points of pain with volunteering committee members to
> reduce noise in this venue. There is little room here for
> light-hearted discussion and mentoring for members of the community
> who have less than full-time commitment and years of experience in
> language design.
>
> It's disappointing to be ostracized, but it is true. I also want to
> see careful and well-wrought steady progress. I remember a former
> decade when this discussion was impossible to follow, too many bad
> ideas were too thoroughly discussed, and much time was wasted.
>
> Kris Kowal

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

David Bruant-4
Le 25/03/2011 20:18, Brendan Eich a écrit :
> Dunno. You were ravaged by the Crocken so you may be a bit sore still :-/.
>
> Any list with informal/unsound syntax talk is not one I want to be on. It's not quite beer talk. It could lead to a breakthrough idea, who knows? But the cost is pretty high.
>
> I'm not against syntax proposals here, mind you. Let's just work out the grammar a bit before launching.
This is said and (hopefully) read by people who are currently on the
list. But it might be worth saying it while welcoming people on
es-discuss (on the listinfo page or welcoming e-mail after validation)
so that each time someone comes in with the expectation of bringing a
syntax idea, s/he can be told beforehand that s/he should start working
on the grammar and bring something already solid to the mailing-list.

I haven't taken the occasion to do so yet, but I'd like to thank you for
considering that an open mailing-list will be beneficial for ECMAScript
as a language.
Nevertheless, by doing so, you're creating a community and like every
community, there are rules, conventions, expectations. It might be time
to formalize these in a way or another. The WHATWG has done it on their
wiki. For inspiration, I recommend reading:
*
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F
*
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
* http://wiki.whatwg.org/wiki/FAQ#Mailing_List

Regards,

David

> /be
>
> On Mar 25, 2011, at 12:09 PM, Kris Kowal wrote:
>> On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich <[hidden email]> wrote:
>>> No problem -- just don't provoke Zeus to unleash the Crock-en ;-).
>>> https://mail.mozilla.org/pipermail/es-discuss/2011-February/012761.html
>> Perhaps there needs to be a venue where non-experts can bounce ideas
>> and discuss points of pain with volunteering committee members to
>> reduce noise in this venue. There is little room here for
>> light-hearted discussion and mentoring for members of the community
>> who have less than full-time commitment and years of experience in
>> language design.
>>
>> It's disappointing to be ostracized, but it is true. I also want to
>> see careful and well-wrought steady progress. I remember a former
>> decade when this discussion was impossible to follow, too many bad
>> ideas were too thoroughly discussed, and much time was wasted.
>>
>> Kris Kowal
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

David Foley-2
That's something I for one would welcome, and I'm sure others too. I'd like to see some traction on this

On 25 Mar 2011, at 20:38, David Bruant <[hidden email]> wrote:

> Le 25/03/2011 20:18, Brendan Eich a écrit :
>> Dunno. You were ravaged by the Crocken so you may be a bit sore still :-/.
>>
>> Any list with informal/unsound syntax talk is not one I want to be on. It's not quite beer talk. It could lead to a breakthrough idea, who knows? But the cost is pretty high.
>>
>> I'm not against syntax proposals here, mind you. Let's just work out the grammar a bit before launching.
> This is said and (hopefully) read by people who are currently on the
> list. But it might be worth saying it while welcoming people on
> es-discuss (on the listinfo page or welcoming e-mail after validation)
> so that each time someone comes in with the expectation of bringing a
> syntax idea, s/he can be told beforehand that s/he should start working
> on the grammar and bring something already solid to the mailing-list.
>
> I haven't taken the occasion to do so yet, but I'd like to thank you for
> considering that an open mailing-list will be beneficial for ECMAScript
> as a language.
> Nevertheless, by doing so, you're creating a community and like every
> community, there are rules, conventions, expectations. It might be time
> to formalize these in a way or another. The WHATWG has done it on their
> wiki. For inspiration, I recommend reading:
> *
> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F
> *
> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
> * http://wiki.whatwg.org/wiki/FAQ#Mailing_List
>
> Regards,
>
> David
>
>> /be
>>
>> On Mar 25, 2011, at 12:09 PM, Kris Kowal wrote:
>>> On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich <[hidden email]> wrote:
>>>> No problem -- just don't provoke Zeus to unleash the Crock-en ;-).
>>>> https://mail.mozilla.org/pipermail/es-discuss/2011-February/012761.html
>>> Perhaps there needs to be a venue where non-experts can bounce ideas
>>> and discuss points of pain with volunteering committee members to
>>> reduce noise in this venue. There is little room here for
>>> light-hearted discussion and mentoring for members of the community
>>> who have less than full-time commitment and years of experience in
>>> language design.
>>>
>>> It's disappointing to be ostracized, but it is true. I also want to
>>> see careful and well-wrought steady progress. I remember a former
>>> decade when this discussion was impossible to follow, too many bad
>>> ideas were too thoroughly discussed, and much time was wasted.
>>>
>>> Kris Kowal
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Brendan Eich-3
On Mar 25, 2011, at 2:07 PM, David Foley wrote:

> That's something I for one would welcome, and I'm sure others too. I'd like to see some traction on this

I don't want to spend too much time on custom etiquette.

Also I don't want to be a jerk about it, but your post both bottom-cites heavily (top-citing without editing is even worse, but please trim; I nag everyone and fail myself, so again don't take this as more than a chance to restate an old USENET rule).

Another thing: you'd like to see some traction on "this", my favorite pronoun. Which "this"? If you don't like # for sharp functions, then we're back to inventing syntax. That requires some care not to walk right into (fairly well-known, but trickier due to ASI and "lack of ASI where you expected it") grammatical ambiguities.

Throwing up ideas and letting the grammarians debug them on the list is possible and might be fun but (in my view; I'm not the list moderator, just admin -- we have no moderator) it's not a good use of the list or all our time.

So: top-cite and trim carefully, avoid pronoun trouble, and try to make concrete proposals where (if they involve new syntax) you've worked through some of the consequences to avoid the obvious gotchas.

This may be too much to ask, but I'll ask for it anyway. It ought not cause a swerve into "OMG fascist list rules". But some of us old timers expect at least the old netiquette rules to apply still. Follow them and the Crocken may stay peacefully asleep.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

David Foley-2
My response was simply this : assuming normative scope in conversational tone, that I would welcome is a venue where end users (engineers and architects as well as scripters) could contribute to the developer experience of using JavaScript without incurring the wrath of it's fathers, which appear to be more focused on the interpreter of the language rather than the thrust of it's use cases (which almost always appear to bottom out on library abstractions to solve the issues).

I really would have hoped that rather than assuming an asses POV that this list would assume the best without requirement of over-qualification.

Like it or not, JavaScript is the glue of the web. This language space has been embroiled in vendor politics since day one- end users need an effective forum to describe their requirements- that is what I was espousing. Clear enough?

You do yourself a disservice by assuming idiocracy.

On 25 Mar 2011, at 22:49, Brendan Eich <[hidden email]> wrote:

> On Mar 25, 2011, at 2:07 PM, David Foley wrote:
>
>> That's something I for one would welcome, and I'm sure others too. I'd like to see some traction on this
>
> I don't want to spend too much time on custom etiquette.
>
> Also I don't want to be a jerk about it, but your post both bottom-cites heavily (top-citing without editing is even worse, but please trim; I nag everyone and fail myself, so again don't take this as more than a chance to restate an old USENET rule).
>
> Another thing: you'd like to see some traction on "this", my favorite pronoun. Which "this"? If you don't like # for sharp functions, then we're back to inventing syntax. That requires some care not to walk right into (fairly well-known, but trickier due to ASI and "lack of ASI where you expected it") grammatical ambiguities.
>
> Throwing up ideas and letting the grammarians debug them on the list is possible and might be fun but (in my view; I'm not the list moderator, just admin -- we have no moderator) it's not a good use of the list or all our time.
>
> So: top-cite and trim carefully, avoid pronoun trouble, and try to make concrete proposals where (if they involve new syntax) you've worked through some of the consequences to avoid the obvious gotchas.
>
> This may be too much to ask, but I'll ask for it anyway. It ought not cause a swerve into "OMG fascist list rules". But some of us old timers expect at least the old netiquette rules to apply still. Follow them and the Crocken may stay peacefully asleep.
>
> /be
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Brendan Eich-3
On Mar 25, 2011, at 8:45 PM, David Foley wrote:

> My response was simply this : assuming normative scope in conversational tone, that I would welcome is a venue where end users (engineers and architects as well as scripters) could contribute to the developer experience of using JavaScript without incurring the wrath

"wrath"? I may have failed to add a smiley, but c'mon. No wrath here.


> of it's fathers, which appear to be more focused on the interpreter of the language rather than the thrust of it's use cases (which almost always appear to bottom out on library abstractions to solve the issues).

What do you mean? What library abstractions, and what issues? Please be specific.

Remember, I'm the one pushing for new syntax more than many others involved in TC39:

http://brendaneich.com/2011/01/harmony-of-my-dreams/


> I really would have hoped that rather than assuming an asses POV that this list would assume the best without requirement of over-qualification.

Skipping, I don't know how to read this and I really don't want to guess ("asses POV" meaning "ass's POV"? Who said anything about "ass" here? Yeesh.)


> Like it or not, JavaScript is the glue of the web. This language space has been embroiled in vendor politics

There is no "vendor politics" in this thread, though.


> since day one- end users need an effective forum to describe their requirements- that is what I was espousing. Clear enough?

No, you have not made any requirement clear. Let's take your first post today:

> Implicit functions?
>
>
> globalMethod(argument)
> {
>     // implementation
> };
>
> AnObject.prototype.method(value)
> {
>     // whatevs
> };

Dropping function as the leading keyword makes these examples ambiguous, due to automatic semicolon insertion as Mike Samuel pointed out.

Sure, losing the heaviness of eight-letter 'function' is a goal, and we've discussed it often:

http://www.google.com/search?q=site%3Amail.mozilla.org+shorter+function+syntax

The ecmascript.org wiki has a strawman on it:

http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax

This is not going forward as-is, and the plan is to write a new strawman, but the goal of shorter function syntax is getting attention.

We spent time yesterday at the TC39 meeting not only on shorter syntax but exactly how to support better |this| handling for several distinct use-cases: inner functions that want the outer |this|, callbacks that want a certain |this|, and object methods that want the receiver when called as methods of a given (receiver) object (else possibly a default such as the outer function's |this|).

Anyway, there's more to do than fix syntax, but the syntax has to be unambiguous. That's the first requirement, before we can go further.

Kevin Smith started this thread by objecting to #, and that's fair. It's a bit chicken-scratchy. If we can find a better introductory keyword or formal parameter bracketing form, I'm game. I don't think <>-bracketing is it, not only due to E4X (who cares, right?) but mainly because that breaks symmetry with call expression, which uses ()-bracketing.

CoffeeScript uses () for formal parameter bracketing (where there are formal parameters; parameter-less functions start with -> or =>), but allows call expressions to elide the ( and ) where there is no ambiguity -- no ambiguity according to CoffeeScript's complex, evolving rules for disambiguation.

I had the chance to talk to Jeremy Ashkenas about this recently, and he does not recommend trying to graft these rules onto JS and standardize them. I agree.

So a leading character instead of 'function' still seems like the cleanest solution. Ideas other characters than '#' are welcome, since so long as they are not used in the language already (either as punctuators, operators, or identifier characters), they can't introduce ambiguity.


> You do yourself a disservice by assuming idiocracy.

I did not assume anything.

(Good movie, though -- Mike Judge is great!)

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Inner functions and outer 'this' (Re: That hash symbol)

Claus Reinke
> We spent time yesterday at the TC39 meeting not only on shorter
> syntax but exactly how to support better |this| handling for several
> distinct use-cases: inner functions that want the outer |this|,
> callbacks that want a certain |this|, and object methods that
> want the receiver when called as methods of a given (receiver)
> object (else possibly a default such as the outer function's |this|).

That reminds me of an old solution looking for this problem.

Back in 1976, Klaus Berkling suggested to complement the
lambda calculus with an operator to protect variables from
the nearest enclosing binding [1].

The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).

If I may use '#' as a placeholder for a suitable protection
key, then this translates to Javascript as

function Outer() {
    var x = "outer";
    function Inner() {
        var x = "inner";

        log(x); // "inner"
        log(#x); // "outer"
        log(##x); // global scope, probably unbound
    }
}

I've seen this in action in a functional language based on his
ideas, in the late 80s, and have since been repeatedly surprised
by general unawareness of Berkling's ideas. Variants have been
rediscovered occasionally - git's "HEAD^" is a recent example:

http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

Of course, applying the idea to Javascript's 'this' is complicated
by dynamic scoping. Personally, I've found it useful to think of
'this' as an implicit, lexically scoped parameter - then I only have
to worry about which applications pass which implicit parameter.

I don't know whether that is sufficient to make Berkling's idea
applicable here, but I wanted to make sure it is known;-)

Claus
http://www.haskellers.com/user/claus

[1] The original report is hard to come by, the idea was also
    published again in 1982, items 5/6 in this bibliography:

http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/b/Berkling:Klaus_J=.html

    Here is the original report's abstract:

@techreport{Berkling76,
 author  = {Berkling, K.J.},
 title   = {{A Symmetric Complement to the Lambda Calculus}},
 institution = GMD,
 note    = {ISF-76-7},
 month   = {September},
 year    = 1976,
 abstract =  {"The calculi of Lambda-conversion" introduced by A.Church
 are complemented by a new operator lambda-bar, which is in
 some sense the inverse to the lambda-operator. The main
 advantage of the complemented system is that variables do
 not have to be renamed. Conversely, any renaming of
 variables in a formula is possible. Variables may, however,
 appear with varied numbers of lambda-bars in front of them.
 Implementations of the lambda calculus representation with
 the symmetric complement are greatly facilitated.

 In particular, a renaming of all variables in a formula to
 the same one is possible. Variables are then distinguished
 only by the number of preceding lambda-bars. Finally, we
 give a four symbol representation of the lambda calculus
 based on the above mentioned freedom in renaming.  },
 topics  = {FP - Lambda Calculi}
}
 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Wes Garland
In reply to this post by Brendan Eich-3
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich <[hidden email]> wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:

> My response was simply this : assuming normative scope in conversational tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute to the developer experience of using JavaScript

I was going to suggest comp.lang.javascript, but I just had a look and it seems to have been taken over by DOM questions and spam.  David, why don't you start an "ES Tech" group or something, and ban questions which aren't related to JS? (Copy your charter from comp.lang.c, maybe).  Announce it here, and I will subscribe. Probably even participate.
 
Kevin Smith started this thread by objecting to #, and that's fair. It's a bit chicken-scratchy. If we can find a better introductory keyword or formal parameter bracketing form, I'm game.

I like Doug's florin idea from an aesthetic POV, but I have two problems with it -- suddenly, I have to care what charset my editor is using -- but more importantly, I can't figure out how to type it on my Sun keyboard or on my Windows box. Also, what of JS which is delivered on the web using something other than unicode?

Allowing both is an interesting option, but then I remember how annoying ANSI tri-graphs were (history lesson for !brendan: not all terminals had {, C programs allow ??< instead) and realise that would be a mistake.

I, too, find #(a,b) but frankly, there aren't many lead-char solutions which aren't ugly, easy to type, and not used by identifiers (or as operators) already.  What have we got to chose from?  I think `@#%^&* -- none of these are measurably better than # and some are worse. Maybe you could make the point that & looks like a melted lambda. But I see no point in bike shedding over this.

Non leading-char solutions have the disadvantage of using some other kind of bracketing -- e.g.  `a,b { return a + b; }` -- I don't find syntax like this clear from a coder's POV, and there is the re-tooling issue with highlighting editors and the ability to trivially transform between the styles for faster adoption and old code minification -- while these issues certainly shouldn't be deciding factors for TC39 it is nice that leading-char lparen...rparen makes most of them go away.


> You do yourself a disservice by assuming idiocracy.

I don't think Brendan ever assumed that this place is governed by idiots.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Alex Russell

On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:

> On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich <[hidden email]> wrote:
>
>> On Mar 25, 2011, at 8:45 PM, David Foley wrote:
>>
>>> My response was simply this : assuming normative scope in conversational
>> tone, that I would welcome is a venue where
>>
> end users (engineers and architects as well as scripters) could contribute
>> to the developer experience of using JavaScript
>>
>
> I was going to suggest comp.lang.javascript, but I just had a look and it
> seems to have been taken over by DOM questions and spam.  David, why don't
> you start an "ES Tech" group or something, and ban questions which aren't
> related to JS? (Copy your charter from comp.lang.c, maybe).  Announce it
> here, and I will subscribe. Probably even participate.
>
>
>> Kevin Smith started this thread by objecting to #, and that's fair. It's a
>> bit chicken-scratchy. If we can find a better introductory keyword or formal
>> parameter bracketing form, I'm game.
>
>
> I like Doug's florin idea from an aesthetic POV, but I have two problems
> with it -- suddenly, I have to care what charset my editor is using -- but
> more importantly, I can't figure out how to type it on my Sun keyboard or on
> my Windows box. Also, what of JS which is delivered on the web using
> something other than unicode?
>
> Allowing both is an interesting option, but then I remember how annoying
> ANSI tri-graphs were (history lesson for !brendan: not all terminals had {,
> C programs allow ??< instead) and realise that would be a mistake.
>
> I, too, find #(a,b) but frankly, there aren't many lead-char solutions which
> aren't ugly, easy to type, and not used by identifiers (or as operators)
> already.  What have we got to chose from?  I think `@#%^&* -- none of these
> are measurably better than # and some are worse. Maybe you could make the
> point that & looks like a melted lambda. But I see no point in bike shedding
> over this.

Erik and I worked through most of these options, considering their placement on US and non-US keyboard layouts and their relative "does it look like a function?"-ness. "#" won, not because either of us loved it, but because it was the least bad.

> Non leading-char solutions have the disadvantage of using some other kind of
> bracketing -- e.g.  `a,b { return a + b; }` -- I don't find syntax like this
> clear from a coder's POV, and there is the re-tooling issue with
> highlighting editors and the ability to trivially transform between the
> styles for faster adoption and old code minification -- while these issues
> certainly shouldn't be deciding factors for TC39 it is nice that
> leading-char lparen...rparen makes most of them go away.
>
>
>>> You do yourself a disservice by assuming idiocracy.
>>
>
> I don't think Brendan ever assumed that this place is governed by idiots.
>
> Wes
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

--
Alex Russell
[hidden email]
[hidden email]
[hidden email] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: That hash symbol

Mike Samuel
In reply to this post by Wes Garland
2011/3/26 Wes Garland <[hidden email]>:

> On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich <[hidden email]> wrote:
>>
>> On Mar 25, 2011, at 8:45 PM, David Foley wrote:
>>
>> > My response was simply this : assuming normative scope in conversational
>> > tone, that I would welcome is a venue where
>>
>> end users (engineers and architects as well as scripters) could contribute
>> to the developer experience of using JavaScript
>
> I was going to suggest comp.lang.javascript, but I just had a look and it
> seems to have been taken over by DOM questions and spam.  David, why don't
> you start an "ES Tech" group or something, and ban questions which aren't
> related to JS? (Copy your charter from comp.lang.c, maybe).  Announce it
> here, and I will subscribe. Probably even participate.

I'd be happy to participate too.

If the goal is to, as Kevin suggested, provide an early vetting
service of ideas as to how the language *should be* by people who know
have a detailed knowledge of how the language *is*, would a ticket
system be more appropriate/additionally useful?  A ticket system might
use scarce attention better since it is 1:1, not 1:n.



>>
>> Kevin Smith started this thread by objecting to #, and that's fair. It's a
>> bit chicken-scratchy. If we can find a better introductory keyword or formal
>> parameter bracketing form, I'm game.
>
> I like Doug's florin idea from an aesthetic POV, but I have two problems
> with it -- suddenly, I have to care what charset my editor is using -- but
> more importantly, I can't figure out how to type it on my Sun keyboard or on
> my Windows box. Also, what of JS which is delivered on the web using
> something other than unicode?
>
> Allowing both is an interesting option, but then I remember how annoying
> ANSI tri-graphs were (history lesson for !brendan: not all terminals had {,
> C programs allow ??< instead) and realise that would be a mistake.
>
> I, too, find #(a,b) but frankly, there aren't many lead-char solutions which
> aren't ugly, easy to type, and not used by identifiers (or as operators)
> already.  What have we got to chose from?  I think `@#%^&* -- none of these
> are measurably better than # and some are worse. Maybe you could make the
> point that & looks like a melted lambda. But I see no point in bike shedding
> over this.
>
> Non leading-char solutions have the disadvantage of using some other kind of
> bracketing -- e.g.  `a,b { return a + b; }` -- I don't find syntax like this
> clear from a coder's POV, and there is the re-tooling issue with
> highlighting editors and the ability to trivially transform between the
> styles for faster adoption and old code minification -- while these issues
> certainly shouldn't be deciding factors for TC39 it is nice that
> leading-char lparen...rparen makes most of them go away.
>
>>
>> > You do yourself a disservice by assuming idiocracy.
>
> I don't think Brendan ever assumed that this place is governed by idiots.
>
> Wes
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
1234