It strikes me as odd to see specific infix operators hardcoded
in the language spec. ..
I'd be interested to learn whether user-defined infix operators
have been considered, to keep the language-level specification
limited but general, while allowing late specification of details
in library
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
2011/3/25 Kevin Smith khs4...@gmail.com:
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
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com wrote:
2011/3/25 Kevin Smith khs4...@gmail.com:
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
Implicit functions?
globalMethod(argument)
{
// implementation
};
AnObject.prototype.method(value)
{
// whatevs
};
On 25 Mar 2011, at 17:28, Kevin Smith khs4...@gmail.com wrote:
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com wrote:
2011/3/25
2011/3/25 David Foley davi@gmail.com:
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
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
Sure - no offense or time-wasting intended.
On Fri, Mar 25, 2011 at 1:34 PM, Brendan Eich bren...@mozilla.com 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
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 bren...@mozilla.com wrote:
It's totally ambiguous.
Suggestion: do not mail syntax ideas without working through (pencil and
paper,
Hi Nebojša,
Some comments follow.
1. “Use Unicode identifier vs. BCP47 in the API” It isn’t clear what you
mean by this. I would strongly prefer that we use BCP 47 identifiers. If you
mean “allow the Unicode locales extension to BCP 47”, I’m fine, but I don’t see
why we would want to
Hi Claus,
Interesting idea; I'd never considered lifting some of these good syntax ideas
from Haskell before.
One issue with the Haskell `...` syntax directly is conflict with the
quasi-literals proposal, but we can think about alternatives offline (let's
*not* get into a discussion of
No problem -- just don't provoke Zeus to unleash the Crock-en ;-).
https://mail.mozilla.org/pipermail/es-discuss/2011-February/012761.html
/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
On Fri, Mar 25, 2011 at 11:24 AM, Brendan Eich bren...@mozilla.com 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
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
I think we meant allowing the -u extensions for, at least, collation variants.
- Shawn
http://blogs.msdn.com/shawnste
Selfhost a custom locale from
\\scratch2\scratch\shawnste\customlocaledrop\install.batfile:///\\scratch2\scratch\shawnste\customlocaledrop\install.bat
(Selfhost
Those would be BCP 47 language tags too, though. I guess the question is what
level of support the spec should contain (MUST/SHOULD/MAY support RFC 6067).
Addison
From: Shawn Steele [mailto:shawn.ste...@microsoft.com]
Sent: Friday, March 25, 2011 12:56 PM
To: Phillips, Addison; Nebojša Ćirić;
I’m not sure that all u extensions are appropriate. Presumably there could
always be implementation specific variations (like someone could ignore
–u-whatever and just do the chop-from-right thing of BCP47).
From: Phillips, Addison [mailto:addi...@lab126.com]
Sent: Friday, March 25, 2011 1:10
Looking through the notes from the meeting I also found some problems with
the collator. We did specify the collatorType: search, but we didn't offer a
function that would make use of it. Mark and I are thinking about:
/**
* string - string to search over.
* substring - string to look for in
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
Looking through the notes from the meeting I also found some problems with
the collator. We did specify the collatorType: search, but we didn't offer a
function that would make use of it. Mark and I are thinking about:
/**
* string - string to search over.
* substring - string to look for in
2011/3/25 Nebojša Ćirić c...@google.com:
Looking through the notes from the meeting I also found some problems with
the collator. We did specify the collatorType: search, but we didn't offer a
function that would make use of it. Mark and I are thinking about:
/**
* string - string to search
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 david.bru...@labri.fr 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 :-/.
find method wouldn't return boolean but an array of two values:
myCollator.find('gaard', 'ard', 2) - [2, 5] // 4 or 5 as a bound
myCollator.find('ard', 'ard', 0) - [0, 3] // 2 or 3 as a bound
I guess [2, 5] !== [0, 3]
We could return [-1, undefined] for not found state, or just undefined.
I
2011/3/25 Nebojša Ćirić c...@google.com:
find method wouldn't return boolean but an array of two values:
Sorry if I wasn't clear. The !! at the beginning of the call to find
is important.
The undefined value you mentioned below as possible no match result is
falsey because !!undefined ===
Hi Dave,
Interesting idea; I'd never considered lifting some of these
good syntax ideas from Haskell before.
thanks. Yes, I've often noticed that people equate Haskell
language design with its advanced type system ideas, while
the much more stable ideas (such as reducing syntactic
noise) in
2011/3/25 Mike Samuel mikesam...@gmail.com:
2011/3/25 Nebojša Ćirić c...@google.com:
find method wouldn't return boolean but an array of two values:
Sorry if I wasn't clear. The !! at the beginning of the call to find
is important.
The undefined value you mentioned below as possible no
There was a tiny bit of discussion around scientific notation and number
formatting a while back. I thought this included some comments around
globalization differences between cultures on how scientific notation worked.
Does anyone have any examples of such differences?
Thanks,
- Shawn
On Fri, Mar 25, 2011 at 1:34 PM, Nebojša Ćirić c...@google.com wrote:
Looking through the notes from the meeting I also found some problems with
the collator. We did specify the collatorType: search, but we didn't offer a
function that would make use of it. Mark and I are thinking about:
/**
I think an iterator is a cleaner interface; we were just trying to minimize
new API.
In general, collation is context sensitive, so searching on substrings isn't
a good idea. You want to search from a location, but have the rest of the
text available to you.
For the iterator, you would need to
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
In that case I wouldn't put this new functionality in the Collator object. A
new StringSearch or StringIterator object would make more sense:
options = {
collator[optional - default, collatorType=search],
source[required],
pattern[required]
}
LocaleInfo.StringIterator = function(options) {}
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
32 matches
Mail list logo
