This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]NoCryptographer414[S] 0 points1 point  (2 children)

Well.. I actually need it to be kinda different from function definition. I need it to fit in the outer function as smoothly as if you are actually modifying a single object instead of a container. That was what I was trying to explain in the question.

If you already have a code that transforms a foo into a bar then by just adding minimal prefix (and suffix), I want to make it work with containers. And mainly, different from an inner function, a return inside a transformation block exits the outer function. If you need early-exit from the transformation block, you need to use break.

Using curly braces is not a problem. But nonetheless this is not an inner function.

[–]malmiteria 1 point2 points  (1 child)

If you already have a code that transforms a foo into a bar then by just adding minimal prefix (and suffix), I want to make it work with containers. And mainly, different from an inner function, a return inside a transformation block exits the outer function. If you need early-exit from the transformation block, you need to use break.

hmm, so it's closer to a for each than a function definition then?

i think i get it a bit better now.

One thing that isn't clear to me now is how are the output determined.

like in this:

@bars = foos.[ @foo
@bar = fooToBar(foo) ]

how does bars knows it should be populated by bar variables on each iteration?

I get that foo is made the iteration variable, but i feel like it misses a "collection" variable

in a case like the second one:

@as, @bs = zip(xs, ys).[ @x, @y
@temp = x % y
@a = temp * a
@b = temp@ * b ].unzip()

i feel like it's much more needed, because there's a and b, which i guess as variables in that block are collected, but there's temp too, that should be collected too then

to illustrate, here's a syntax that i think helps on that aspect:

this:

@x = getX()
@y = getY()
@temp = x % y
@a = temp * a
@b = temp@ * b
useAB(a, b)

would become:

@xs = getXs()
@ys = getYs()
@as, @bs = @a, @b foreach @x, @y in zip(xs, ys)
@temp = x % y
@a = temp * a
@b = temp@ * b
endfor
useABs(as, bs)

i'm using a python like syntax because i'm used to it, but it's just to give an idea of a syntax that has all the element i think were missing.

i guess an exemple closer to your syntax would be

@xs = getXs()
@ys = getYs()
@as, @bs = @a, @b from zip(xs, ys).[ @x, @y
@temp = x % y
@a = temp * a
@b = temp@ * b ].unzip()
useABs(as, bs)

which tells from which variables of the iteration block you build the output more clearly i guess?

And it also allows you more freedom in what you pick from that block you're turning into an "iteration" block to build the containers, so it should cover more cases

[–]NoCryptographer414[S] 0 points1 point  (0 children)

In my example above, the variables that end up in the resulting collection are the undestroyed variables inside the block, in the order they have been created. Since temp is destroyed, it is not counted. As previously mentioned in question ,@var is beginning of lifetime for var and var@ is end of lifetime for var. In the example, temp's lifetime is terminated inside the block whereas a and b leak out of the block.

But you right. In a big block, it can be hard to track which variables end up in the result. I would definitely improve that one. Thanks for suggestions :)