On 9/29/11 11:00 AM, Graydon Hoare wrote:
- Write 1 iter interfaces on most collections, with varying
strategies, to reduce unwanted boilerplate in cases you don't
need it. Cold code is cold, harmless.
vec::each(v) == takes fn(e) - (), returns ()
vec::scan(v) == takes fn(e) - bool, returns ()
On 30/09/2011 8:29 AM, Patrick Walton wrote:
I whipped up a small testcase using clang and it seems that LLVM indeed
can optimize this style of iteration into a loop.
Is everyone ok with this?
Oh also note: you almost certainly want to make the
traling-block-as-last-arg syntax work before
On 30/09/2011 10:00 AM, Marijn Haverbeke wrote:
I'm also fine with this. As for the syntax...
vec::each(v) {|e| ... }
This once again produces ambiguity with fail and ret: does 'fail {|e|
...}' mean 'call the function produced by fail with this block', or
'fail with this block as the
I see two potential problems with this... We can't use references for
the yielded values, which might be a major penalty in some cases. And
I somewhat doubt that it is easy to optimize. Firstly, our objects are
heap-allocated, so you have a malloc/free for every loop, and
secondly, inlining things
On Thu, Sep 29, 2011 at 5:17 AM, Graydon Hoare gray...@mozilla.com wrote:
- I prefer the closure-passing form:
With this form, would it be possible to extract more than one value
per loop - for example if I had a sequence of numbers that I wanted to
pair up to make a sequence of (x, y)
On 9/29/11 5:20 AM, Peter Hull wrote:
On Thu, Sep 29, 2011 at 5:17 AM, Graydon Hoaregray...@mozilla.com wrote:
- I prefer the closure-passing form:
With this form, would it be possible to extract more than one value
per loop - for example if I had a sequence of numbers that I wanted to
pair
On 9/28/11 9:17 PM, Graydon Hoare wrote:
- Expresses the iteratee is aliased during iteration fact to the
alias-checker, so you don't have to worry about invalidating
externalized iterators. This is important; particularly if you want
to exploit next part ...
I don't understand this, sorry...
On 9/29/11 5:25 AM, Marijn Haverbeke wrote:
I guess we could use return-by-alias here, yes. I was kind of assuming
everybody hated that and wanted it to go away. But if we use that we
can no longer return a tag to indicate end of sequence (you can't
currently wrap a reference in a data structure
On 9/29/11 5:46 AM, Marijn Haverbeke wrote:
I still consider using swap to return things an absolute non-solution.
Try writing some code in that style. Unless I'm missing some part of
the way you want to approach this, it's absolutely dreadful to work
with.
If swap is unacceptable, then, as
It would be nice if we could figure out what to do about iterators for
0.1. I was thinking that we could make them Java-style iterators -- that
is, objects with has_next() : bool and next() : T methods. |for each|
would simply be syntactic sugar.
This form:
for each (x in iter()) {
On principle I do not want us to go down this path, even if we change later. It
adds risk that we won't change. It imposes a stateful model on iterators where
has_next and next must be coherent, and you have to write two methos (not one
as in Python or JS.next). And, Java.
/be
On Sep 28,
On 9/28/11 5:27 PM, Brendan Eich wrote:
On principle I do not want us to go down this path, even if we change later. It
adds risk that we won't change. It imposes a stateful model on iterators where
has_next and next must be coherent, and you have to write two methos (not one
as in Python or
On Sep 28, 2011, at 5:53 PM, Patrick Walton wrote:
On 9/28/11 5:27 PM, Brendan Eich wrote:
On principle I do not want us to go down this path, even if we change later.
It adds risk that we won't change. It imposes a stateful model on iterators
where has_next and next must be coherent, and
+1 This is nice. Should make iterating over ML-style lists very natural. Not
sure how you would write a closure for an array, could you post a sample for
that?
-Rob
On Wed, Sep 28, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.org wrote:
On Sep 28, 2011, at 5:53 PM, Patrick Walton wrote:
On
14 matches
Mail list logo
