ES4 draft LAST CALL: Map

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

ES4 draft LAST CALL: Map

Lars Hansen-3
Last call for comments.  Minor changes since previous drafts (and some
comments at the beginning to address changes that are known to come).

--lars

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

Map.html (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft LAST CALL: Map

David Teller-3
I have a question related to collections in general.

I have the impression that ES4 will someday accept some kind of high-level concurrency, possibly Erlang-style. If so, we will probably need the ability to perform some kind of (destructive) pattern-matching/switch-type on the contents of a collection. Now, maybe this kind of pattern-matching will only needed for some concurrency-specific data structure, say a dynamically-typed Mailbox (à la Erlang) or a statically-typed Channel (à la Concurrent ML) or perhaps something higher-level (à la JoCaml).

With the current definition of Map and collections, this form of pattern-matching may probably be hand-coded using an iterator and intrinsic::remove, although the process is relatively unfriendly and the thread-safety will remain uncertain until there's a concurrency model for ES4.

Now, on to my question: should we add a method for finding some data in a collection from destructive pattern-matching or should this be left for later ?

Cheers,
   David

Quoting Lars Hansen <[hidden email]>:

> Last call for comments.  Minor changes since previous drafts (and some
> comments at the beginning to address changes that are known to come).
>
> --lars
>



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

RE: ES4 draft LAST CALL: Map

Lars Hansen-3
A later version of ES may or may not embrace some sort of concurrency
solution.  (It seems likely, but who knows.)  I don't think it's possible
to say anything about what form that might take, except I'm fairly sure
that shared-memory threads won't be it.

My opinion is that if there are features that are primarily useful for
concurrency (and it sounds like what you have in mind is that) then we
should not try to guess about them until we start talking about
concurrency in earnest.

--lars

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of David Teller
> Sent: 21. mars 2008 03:26
> To: [hidden email]
> Subject: Re: ES4 draft LAST CALL: Map
>
> I have a question related to collections in general.
>
> I have the impression that ES4 will someday accept some kind
> of high-level concurrency, possibly Erlang-style. If so, we
> will probably need the ability to perform some kind of
> (destructive) pattern-matching/switch-type on the contents of
> a collection. Now, maybe this kind of pattern-matching will
> only needed for some concurrency-specific data structure, say
> a dynamically-typed Mailbox (à la Erlang) or a
> statically-typed Channel (à la Concurrent ML) or perhaps
> something higher-level (à la JoCaml).
>
> With the current definition of Map and collections, this form
> of pattern-matching may probably be hand-coded using an
> iterator and intrinsic::remove, although the process is
> relatively unfriendly and the thread-safety will remain
> uncertain until there's a concurrency model for ES4.
>
> Now, on to my question: should we add a method for finding
> some data in a collection from destructive pattern-matching
> or should this be left for later ?
>
> Cheers,
>    David
>
> Quoting Lars Hansen <[hidden email]>:
>
> > Last call for comments.  Minor changes since previous
> drafts (and some
> > comments at the beginning to address changes that are known
> to come).
> >
> > --lars
> >
>
>
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft LAST CALL: Map

David Teller-3
On Fri, 2008-03-21 at 14:46 +0000, Lars Hansen wrote:
> My opinion is that if there are features that are primarily useful for
> concurrency (and it sounds like what you have in mind is that) then we
> should not try to guess about them until we start talking about
> concurrency in earnest.
>
> --lars

Ok. Other than in a concurrency, this destructive pattern-matching may
occasionally be useful, but I guess re-implementing it by hand is simple
enough that it probably doesn't need to be built-in collections.

Cheers,
 David

--
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations.

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

RE: ES4 draft LAST CALL: Map

Lars Hansen-3
> -----Original Message-----
> From: David Teller [mailto:[hidden email]]
> Sent: 21. mars 2008 08:08
> To: Lars Hansen
> Cc: [hidden email]
> Subject: RE: ES4 draft LAST CALL: Map
>
> On Fri, 2008-03-21 at 14:46 +0000, Lars Hansen wrote:
> > My opinion is that if there are features that are primarily
> useful for
> > concurrency (and it sounds like what you have in mind is
> that) then we
> > should not try to guess about them until we start talking about
> > concurrency in earnest.
> >
> > --lars
>
> Ok. Other than in a concurrency, this destructive
> pattern-matching may occasionally be useful, but I guess
> re-implementing it by hand is simple enough that it probably
> doesn't need to be built-in collections.

Feel free to air concrete thoughts, if for no other reason than
for the record.  Just because we're trying to nail down ES4 doesn't
mean we have to stop talking about the design space.

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

Re: ES4 draft LAST CALL: Map

Waldemar Horwat
In reply to this post by Lars Hansen-3
The current definition in 1.2.2 of what Map(o) does is a harmful dead end.  The current behavior is:

- If o is already a Map then leave it alone.
- Otherwise enumerate the visible properties of o and construct a Map out of those.

This is harmful because it's guaranteed to cause current and future incompatibilities.  There are many other map-like things for which this is the wrong default and we'll be unable to fix them for compatibility reasons.  Here are just a few:

- If you construct a Map out of a Vector, you want the mapping of indices to the elements, with nothing else.  The default behavior brings in extraneous miscellaneous housekeeping properties (length, maybe fixed, perhaps more in the future).
- Folks will write libraries that define MultiMap and Set classes.  We'll want to later allow natural conversion of these to a Map, but the default will get in the way.

For these reasons the current definition of Map(o) is broken and should not be adopted.  The fix is to take out the auto-enumerating behavior.  If it's needed, it should be done by a static function.

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