On 2/29/12 5:52 PM, Graydon Hoare wrote:
That's what it means, yeah. "TCP-preserving-return" is a somewhat common
gotcha in languages that have the temerity to mix closures and explicit
flow control.
Yes, I just mean that the way TCP is usually phrased is: "I can convert
some expr X into (fn()
On 12-02-29 05:45 PM, Niko Matsakis wrote:
> then doing:
>
> for i in iterator() { }
>
> would be the same.
>
> I believe this holds.
That's what it means, yeah. "TCP-preserving-return" is a somewhat common
gotcha in languages that have the temerity to mix closures and explicit
flow contr
On 2/29/12 5:11 PM, Niko Matsakis wrote:
Presuming (of course) that the iterator respects "break", and that the
iterator didn't intend to perform any action after the iteration
terminated, I think it's TCP-preserving. These seem like reasonable
assumptions to me.
I was thinking about this mo
On 12-02-29 05:11 PM, Niko Matsakis wrote:
Also, now more than ever, I think we should still prohibit explicit
`break`, `cont`, and `ret` statements in sugared lambdas.
Tricky. Plausible. I've less of an opinion on this, assuming we've moved
a large number of blocks back to for-loop form. Mig
On 2/29/12 4:47 PM, Graydon Hoare wrote:
Yeah, I can't either. And since we don't presently know, in other
loops (while, vector-for), whether we exited them by
loop-condition-completion or explicit-break, I can't see how this
would deserve more-special consideration. If you have a Really Specia
On 12-02-29 04:41 PM, Niko Matsakis wrote:
This sounds fine. The only downside I can see to Marijn's technique is
that there is no way for an iteration function to distinguish "broke out
of the loop" from "returned out of the loop". This may or may not be
important? I could imagine that the itera
This sounds fine. The only downside I can see to Marijn's technique is
that there is no way for an iteration function to distinguish "broke out
of the loop" from "returned out of the loop". This may or may not be
important? I could imagine that the iterator may want to perform
actions on a b
On 12-02-17 07:37 AM, Niko Matsakis wrote:
On 2/17/12 7:18 AM, Andrew Pennebaker wrote:
ssylvan, as a Lisper I would be in favor of having fn name(args) ...
desugar to let name = fn(args) ... where fn is essentially lambda.
I am not in favor of removing named fn items for several reasons.
Ag
On 12-02-29 01:12 PM, Marijn Haverbeke wrote:
I was actually thinking there wouldn't have to be a special may_return
type at all. The returned value can be an option, and return can store
to that and then break. Code after the call to the iterator then
checks for a `some` value in the return slot
I was actually thinking there wouldn't have to be a special may_return
type at all. The returned value can be an option, and return can store
to that and then break. Code after the call to the iterator then
checks for a `some` value in the return slot and, if found, returns
it.
Marijn suggested a simplification which I like.
The types can be:
enum loop_ctl = { lc_break, lc_cont, lc_ret };
enum may_return = { mr_cont, mr_ret };
In other words, the return value is not carried in the types. Instead,
the `for` loop transform stores the return value in a local va
So, I've been thinking more about supporting "break", "ret", and "cont"
in all loops (including those implemented in library code). I
originally proposed in #1619 a system that supported "break" and "cont"
based on enums. But I was thinking that we could get a bit more
ambitious and support r
12 matches
Mail list logo
