I am really astonished to hear protection keys being thought
of as brittle under transformation: that is just the opposite
of what they are about!
Executive summary:
- de Bruijn indices are a good assembly language of
binding constructs, suitable for automatic transformation,
I am really astonished to hear protection keys being thought
of as brittle under transformation: that is just the opposite of what they
are about!
Sorry to astonish you. :)
Executive summary:
- de Bruijn indices are a good assembly language of
binding constructs, suitable for
On Mar 27, 2011, at 11:13 AM, David Herman wrote:
To be fair, your suggestion is more moderate than de Bruijn, although it's
not clear whether you're proposing the ability to refer to shadowed bindings
of *all* variables or just |this|. If it's the former, I'm *strongly*
opposed. If it's
On Mar 27, 2011, at 10:31 PM, Brendan Eich wrote:
That strawman is essentially functional record update for setting __proto__
AKA [[Prototype]], although it reads backwards compared to FRU in ML-family
languages. Those languages put the update on the right, often linked using
'with'
Shawn, would you be ok with adding this new API to the list for 0.5 so we
can support collation search?
I'll edit the strawman in case nobody objects to this addition.
25. март 2011. 16.34, Nebojša Ćirić c...@google.com је написао/ла:
In that case I wouldn't put this new functionality in the
On 28.03.2011 0:05, Brendan Eich wrote:
On Mar 27, 2011, at 11:33 AM, Juan Ignacio Dopazo wrote:
On Sat, Mar 26, 2011 at 6:31 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com wrote:
Why not just to use already reserved `extends` keyword for
This discussion has had me pretty confused. I never understood why you would
*want* string search inside collator: the APIs and usage models are completely
different. While there is some underlying relation, it’s just confusing to try
to jam them into the same API.
StringSearch is modestly
Searching gets tricky. Is the result greedy or not (matches as much as
possible or as little as possible), etc. There are lots of variations, which
is why it was skipped from the initial v0.5.
Comparison, Search and Casing are all dependent on each other. If search finds
a substring, we’d
My initial thinking was that “type” would indicate a more restrictive or a
fuzzy matching, with the idea that when known strings are sorted (like records
from a database being sorted for display), a detailed sort is appropriate,
however when querying the database to see if there’s a record for
I didn’t say it was “useless”, only that we had a lower priority for us.
What I trying to say (but didn’t) was that I’m quite happy with this design
compared to what came previously.
Addison
From: Nebojša Ćirić [mailto:c...@google.com]
Sent: Monday, March 28, 2011 2:26 PM
To: Phillips, Addison
Searching is discussed in UTS#10. It does need to be correlated with user's
expectations for matching, as you observe.
Mark
*— Il meglio è l’inimico del bene —*
On Mon, Mar 28, 2011 at 14:13, Shawn Steele shawn.ste...@microsoft.comwrote:
Searching gets tricky. Is the result greedy or not
Sorry, useless was connected with the collator object type not to search
itself...
28. март 2011. 14.47, Phillips, Addison addi...@lab126.com је написао/ла:
I didn’t say it was “useless”, only that we had a lower priority for us.
What I trying to say (but didn’t) was that I’m quite happy
Reading this thread, we have possibly three types? sort, comparison,
in-text search?
I'm trying to remember, and fail. Was sort and non-sort different
other than default options?
As for proposals in this thread, I'm not too fond of putting
non-optional arguments into options, that's not
Yes, sort, comparison and in-text search seem like reasonable buckets to me.
Although in-text can further be broken into, I think, exact and non-exact cases.
- Shawn
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Axel
On Mar 28, 2011, at 1:53 PM, Dmitry A. Soshnikov wrote:
Exactly. Classes are not about just the class keyword, but about the
_ability to classify_, i.e. to program in classified (i.e. with
object-patterned programming). JS supports (and supported all these years
both approaches:
I think we can do that, leave the collatorType with sort and comparison. We
can add more, like in-text-search, later.
28. март 2011. 15.45, Shawn Steele shawn.ste...@microsoft.com је
написао/ла:
Yes, sort, comparison and in-text search seem like reasonable buckets to
me. Although in-text can
On Mar 28, 2011, at 12:29 PM, Allen Wirfs-Brock wrote:
Dmitry's suggestion of #proto or a similar sigil-distinguished name makes me
wonder, though: could we have FRU via the spread operator *and* proto
presetting without adding a funky [no LineTerminator here] proto infix
operator?
On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Overall, I really like ^this as a narrow solution to a specific real usage
problem. I'm interested in reactions and unless somebody thinks of something
that seriously torpedoes it I will probably write it up as a
On Mon, Mar 28, 2011 at 10:16 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Overall, I really like ^this as a narrow solution to a specific real usage
problem. I'm interested in reactions and unless somebody
On Mar 28, 2011, at 5:36 PM, Brendan Eich wrote:
On Mar 28, 2011, at 12:29 PM, Allen Wirfs-Brock wrote:
That is why in my proposal
class Foo {};
is defined to mean almost exactly the same thing as
function Foo() {};
(but things start to change when you put something between the
On Mar 28, 2011, at 8:30 PM, Sam Tobin-Hochstadt wrote:
On Mon, Mar 28, 2011 at 10:16 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Mon, Mar 28, 2011 at 10:35, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Overall, I really like ^this as a narrow solution to a specific real usage
21 matches
Mail list logo
