AltME groups: search

About the bug thing. When returning to the first object, A is set 
again to "OK" in the line just after the call to F:
	f 2
	a: "OK"
]
...


That should be the A in the first object, shouldn't it? So I can't 
figure out the internals giving the result, we see.

That should be the A in the first object, shouldn't it?

 - it certainly is not the first object, that is why you see the "bug!"

To me, it's like if the following code would return "bug":

>> o: context [a: "bug" a: "ok"]
>> get in o 'a
== "ok"

The fact is, that in the article, there is a simulation fully explaining 
what is going on. And, moreover, the MAKE OBJECT! [...] binds the 
[...] block, which is a modification, that does not get "reversed". 
And, moreover, there is a code that shows how to "cure" it.

such deep bug in REBOL
 is not a bug in REBOL at all

it is just a bug in the example code

If this is not a bug in REBOL, then there is a bigger problem, as 
I see it. The language is way too complicated.

Actually, it is not. The only thing you should know is, that the

    MAKE OBJECT! [...]


expression modifies the [...] block. If you want to use the block 
as code (in a recursive, or otherwise repetitive manner), you need 
to realize that.

if you want the things to become simple, you can just define a new 
non-modifying function and you are safe.

Nah, better start over and make a new language, that is simple in 
the first place.

That does not make sense in this case, when what you need is just 
a function like:

safe-object: func [blk [block!]] [make object! copy/deep blk]

and you are done

So, this is not about the language, this is just about a different 
function to use.

But, of course, it looks easier (at the first sight) to push somebody 
to define a new language for you. I can guarantee you, that no matter 
how hard you push, there will always be something you find "complicated".

Gabriele, I guess, you're joking, but to answer your question: it 
would be simple, if the above function returning "bug!" would instead 
return "ok" like this function:

g: does [
	get in make object! [
		a: "ok"
		a: "bug!"
		get in make object! [
			a: "ok"
		] 'a
		a: "ok"
	] 'a
]

>> g
== "ok"

In REBOL, literal blocks are just literal blocks. If you modify them... 
they are modified. Binding a block modifies the words inside the 
block, ie. it modifies the block. It can't get any simpler than this.


Now, you may argue that MAKE OBJECT! should bind/copy the block instead; 
the reason it does not is purely performance (as 99.99% of the time 
the copy is not necessary). In that 0.01% of cases where you need 
it... you just write MAKE OBJECT! COPY/DEEP [...] instead.

Our understanding of "simple" is different, or I would go as far 
as saying, your understanding of "simple" is twisted.


It would be simple because it fits your model better? Or because 
the model to describe that behavior would be simpler?
I'm asking 
because the latter is certainly false, especially if you want to 
preserve things like dialecting.


I would say, the model giving my suggested behaviour is simpler. 
If you disagree, then look at the code again. 'a' is set to "ok" 
again, after the recursive call. A model giving some other result 
is not simple. If you think, it is, then describe that model in a 
simple way! A simple model should also be simple to describe, right?

On the other hand, the behaviour of self-modifying code is not as 
terribly complicated as you are trying to suggest, since:


* Taking into account the modifying properties of the MAKE OBJECT! 
[...] expression I wanted to write a relatively simple example to 
show what bug you may run into when ignoring the modifications.

* I succeeded immediately without actually running into such a case 
in practice, i.e. I did not have to hit my head to the wall first 
to run into this.

* It sufficed to think of a case when the modification would twist 
the block behaviour relatively to what you might find simple.

* Since I did it without actually running into it, I am fully entitled 
to saying, that the behaviour is actually transparent to me.

BTW, did you already succeed to get your head around the difference 
between a function and a closure?

Yeah, I have a reasonable understanding of what a function and a 
closure is, and if I remember correctly, R2 functions are neither 
... or are a combination.


Back to the self-modifying code when making objects. Look at this:

>> b: [print 'ok a: 1]
== [print 'ok a: 1]
>> o: make object! b
ok
>> ? b
B is a block of value: [print 'ok a: 1]


Since making the object doesn't change the block, do you still think, 
the above bug isn't a bug in REBOL?

Gettin' rid of this bug doesn't mean, we should or would sacrifice 
self-modifying code

 - actually, you get rid of the bug by not writing a self-modifying 
 code. Unless you forbid me to write a self-modifying code, I can 
 always recreate the bug.

I have a reasonable understanding of what a function and a closure 
is, and if I remember correctly, R2 functions are neither ... or 
are a combination

 - this looks quite superficial. Seems to me you did not read the 
 suggested section of the article and have actually no idea.

(the general definition does not apply to REBOL closures, I am not 
sure I picked a correct name, that may be my mistake)

Since making the object doesn't change the block" - it does, I leave 
it as an exercise for the reader to find out how"

>> b: [print 'ok a: 1]
== [print 'ok a: 1]
>> b2: copy b
== [print 'ok a: 1]
>> make object! b
ok
>> b = b2
== true
>> b == b2
== true


b and b2 are clearly not the same, so I won't test that. Now, before 
you suggest a fourth type of equal test, maybe you should reconsider 
your statement, that this is a simple part of the language? And that 
my claim of this being a bug has something to it.


(I know, the difference lies in the binding, so you don't have to 
make any 'smart-ass' points about that, just take a step back and 
look at all this again. That's all I'm asking.)

Regarding your "this being a bug" - how that can be a bug of the 
language is beyond my understanding, when I know that it was intended.

Moreover, as already mentioned at least three times: it is easy to 
avoid any problems. It suffices to use a non-modifying SAFE-OBJECT 
function.

Anyway, for the readers that are curious, here is the explanation:

a: [print 'ok a: 1]
get third a ; == [print 'ok a: 1]
b: copy a
get third b ; == [print 'ok a: 1]
make object! b
get third b ; == 1

While, we still get:

a: [print 'ok a: 1]
get third a ; == [print 'ok a: 1]
b: copy a
get third a ; == [print 'ok a: 1]

Sorry, just a paste problem, AltMe is not exactly comfortable as 
far as cut and paste goes.

what does 'third mean on a block?

Posting once again, to not confuse anybody:

a: [print 'ok a: 1]
get third a ; == [print 'ok a: 1]
b: copy a
get third b ; == [print 'ok a: 1]
make object! b
get third b ; == 1
get third a ; == [print 'ok a: 1]

To not bee too critical, here is a session from the R3 console using 
Geomol's code, which reveals an iconsistency in the R3 == function:

>> b: [print 'ok a: 1]
== [print 'ok a: 1]

>> b2: copy b
== [print 'ok a: 1]

>> make object! b
ok
== make object! [
    a: 1
]

>> b = b2
== true

>> b == b2
== true

>> (third b) == (third b2)
== false

Regarding your 

this being a bug" - how that can be a bug of the language is beyond 
my understanding, when I know that it was intended."

*sigh* :)

How do you know, it was intended? You may know, because you've discussed 
it with Carl. How would other than you know?


When I say "bug", I might mean "design flaw". Have you considered 
that? If it was intended and can be considered a design flaw, why 
not just call it a bug then?


Never mind. As I expect, you won't eat your words about this being 
simple, I don't expect a reasonable answer anyway. :)

And regarding the "time waste", some readers discovered something 
new, so it was not a time waste for them

Regarding the "design flaw" - as I said, the MAKE OBJECT! [...] expression 
modifies the block, but it is easy to define the SAFE-OBJECT fucntion 
which does not modify the block. Thus, it is not a design flaw at 
all. It might be considered a design flaw only if we weren't able 
to define such a function.

And regarding the 

time waste", some readers discovered something new, so it was not 
a time waste for them"
That's right, I did not know that MAKE OBJECT modifies the block.

The

http://www.rebol.net/wiki/Bindology


article discusses this as well (together with other subjects I found 
interesting), but, I have to admit, that it is probably not a reading 
for a "faint of heart"

>> o: context [a: "x"]
>> p: copy o []
>> append get in o 'a "y"
>> ? p ; a == "xy"

when I change 'a in O, it changes in P as well.

which means o/a and p/a "points" to the same series! I think.
But;
>> same? in o 'a in p 'a
== false

Why?

Your question is equivalent to this one:

a: "x"
b: a
append a "y"
b ; == "xy"
same? 'a 'b ; == false

Oh shame on me! I forgot to GET the values.. Thank you.

One more question, I use COPY on objects to be able to use same series! 
values in different objects, is that right?
I mean pointing to the same series inside different objects.

In R2 I do like that:
>> o: context [a: ""]
>> p: context [b: get in o 'a]
>> append p/b "*"
>> o/a
== "*"

Geomol, your model is one based on "scope". REBOL's model does not 
have such concept, thus, it is "simpler" (less concepts). You have 
a different definition of "simple", which seems closer to "intuitive" 
to me. That's fine with me, but, there's no point in arguing using 
different terms. What me and Ladislav call "simple" is a different 
thing, and it seems Carl agrees with us; changing REBOL your way 
would not be "simple" in our (me, Ladislav, Carl, etc.) sense.

I do have a situation where I need to safely and deeply copy an object, 
namely in the undo system, I am building for a program.

Now, before you suggest a fourth type of equal test, maybe you should 
reconsider your statement, that this is a simple part of the language?

 - Ah, so now you are saying that the problem is that REBOL's MOLD 
 function does not *show* the binding of words?


This has nothing to do with simplicity, rather, it has to do with 
being intuitive. make object! changing the binding of words inside 
your B block is not intuitive, i agree. Intuition is not very useful 
when programming; still, there are many programming languages that 
try to be intuitive. I think REBOL is the *least* intuitive, especially 
if you have learned something about programming already.

«When I say "bug", I might mean "design flaw".» - then call it design 
flaw. I will call it a designed feature, as it turns out to be very 
useful in practice. There are many alternative languages out there 
if what you want is intuitive behavior, for some definition of "intuitive".

Gabriele, I'm afraid, the consequence of such complicated rules is, 
that most programmers will put in COPY/DEEP many places in the code 
in front of blocks. By "most programmers" I mean every REBOL programmer 
except maybe 3.


I don't follow you, when you say, it's an intentional "optimization" 
and then argue, it's a useful feature, we can't live without.

then call it design flaw


When I first saw it, I didn't know, it was intentional behaviour. 
To me, it looked clearly as a bug, so I called it a bug.

Gabriele, if we continue with design flaws related to binding, the 
following is to me in that category:

>> blk: [x]
== [x]
>> x: 1
== 1
>> context [x: 2 append blk 'x]		; 1st alternative x

>> use [x] [x: 3 append blk 'x]		; 2nd alternative x just to show 
different ways to do this
== [x x x]
>> blk
== [x x x]
>> reduce blk
== [1 2 3]


I came to think of this from your comment on scope. To me, REBOL 
does have scope, it's just different from most languages. In REBOL, 
every word belong somewhere, and three times the same word in a block 
can belong to three different places. That's the scoping rules. Now 
I want to save and load that block:


>> save/all %/tmp/ex1.r blk	; using /all , even if it makes no difference 
here, but this questions /all, doesn't it?
>> blk: load %/tmp/ex1.r
== [x x x
]
>> reduce blk
== [1 1 1]


So doing that changes everything. This design flaw (you may call 
it a "design feature") can be the cause of so much confusion and 
program failures, that I might even call it a "bug". ;)

'This design flaw (you may call it a "design feature") can be the 
cause of so much confusion and program failures, that I might even 
call it a "bug". ;)' - that is (IMO) neither of "design flaw", "design 
feature", "bug". I think, that it is a problem, which you might help 
to solve if you come with a good idea ;-)

Typing into the console (REBOL prompt) can be considered the same 
as appending to a block. If I type the same word several times, each 
has the same meaning. So the block should define the binding, not 
each word.

But, how that can help you with the above issue is a mystery

In your last example here, blk is created outside the context block. 
What I suggest is, that when you append x to blk, it doesn't matter, 
where you do that. The block defines the binding. So reducing blk 
in your example should give [1 1], and reduce load mold blk should 
also give [1 1]. Appending words to a block should mean that: appending 
words.

- "The block defines the binding".
It's against Rebol's first law. 
AFAIK binding (context) is a property of words. Series have not.

the consequence of such complicated rules

 - I don't understand where the complication is. Should writing a: 
 [...] also do a copy? Should everything do a copy? You're arguing 
 that sometimes REBOL should copy things, sometimes not. *That* is 
 a list of complicated rules.

BIND modifying the block is a useful feature at times. For example, 
the copy that has been added "for security reasons" in many places 
makes a number of "tricks" harder to do.

MOLD missing words context: where did I ever say this was a feature? 
As Ladislav said, this is just a non-trivial problem, because to 
solve it you may have to save the whole interpreter state. (One of 
your X there is bound to system/words, if you save that you basically 
save everything.)

So the block should define the binding, not each word.
 - that kills dialecting.


Geomol, really, have a look at Scheme. It works exactly like you 
want... REBOL works differently for a reason.

Ladislav, if you try follow my thoughts, you can figure that out 
yourself.


Steeve, maybe that law is a design flaw, that causes many problems? 
Like the example returning "bug", which started much of this conversation.


Gabriele, ... Gabriele, you strengten my tolerance, and thank you 
for that. "that kills dialecting" I've seen you writing that before, 
and it puzzles me every time. (Well, probably different understanding 
again.) Thank you for suggesting Scheme, but I don't have time to 
dig into a new language right now.

Should we let it rest?

Gabriele, it hard to have a conversation, when you go to extremes 
like in the following:


I don't understand where the complication is. Should writing a: [...] 
also do a copy? Should everything do a copy? You're arguing that 
sometimes REBOL should copy things, sometimes not. *That* is a list 
of complicated rules.


Do REBOL copy things sometimes today? Like in function definitions:

make function! spec body


Maybe REBOL should copy in the example, we discuss, maybe it's a 
bad idea. The complication (for me and most likely others) in the 
above example is, when I read it, I would expect some output from 
my intuition. The actual output is different, and it's really hard 
to see, why that output is intentional.

None of these copy by default for three reasons:

- You can't uncopy something that's been copied, but you can copy 
something that hasn't been copied yet.

- MAKE doesn't take options that can't fit in its argument(s), so 
optional behavior can only happen if the spec says so.

- Efficiency means avoiding copying, particularly in a non-compiled 
language. That's why a so many functions are modifying.

Yes, and there is no reason, why such a rule could not be held for 
e.g. CONTEXT, to follow the suit as well

Yup. The reason that CONTEXT currently doesn't copy is the same as 
why MODULE doesn't copy: They are generally used for one-off creations, 
based on large specs that are rarely reused, and inefficient to deep-copy. 
We could easily make them copy, but it would continue to be a bad 
idea for those reasons.

Doing it that way shrinks the startup time and memory quite a bit. 
There's a lot of the loading process that is dedicated to reducing 
code copying.

We all know you can make REBOL do just about anything. We also know 
there are a few things that trip people up (e.g. copying series values 
defined in funcs). My questions for John are: 


1) Has this behavior ever been behind a bug in any of your REBOL 
code? If so, what was the context and what was the impact (e.g., 
how did you work around it)?


2) If you got your wish, what would the consequences be? i.e., how 
would it change REBOL?

More confusion?

>> body: [a + b]
== [a + b]
>> f: make function! [a b] body
>> pick :f 2
== [a + b]
>> same? body pick :f 2
== false
>> insert body '-
== [a + b]
>> body
== [- a + b]
>> pick :f 2
== [a + b]
>> f 1 2
== 3


To me, MAKE function! seem to copy the body block. What are the arguments, 
that the body block isn't copied?

Gabriele, that can't be true. See:

>> b: [a]
== [a]
>> blk: []
== []
>> insert/only blk b
== []
>> blk
== [[a]]
>> same? b pick blk 1
== true

Gregg: "1) Has this behavior ever been behind a bug in any of your 
REBOL code? If so, what was the context and what was the impact (e.g., 
how did you work around it)?" - you should not have asked this question, 
since the answer is already present above

Geomol, I meant PICK when done on a function! value.

ok, no, you're right and that was R3. R2 copies on make function!. 
to me, *this* is a bug. or rather, either make should always copy 
or it should never do it. having exceptions is silly.

(always copy would make sense only if rebol could do copy on write 
- which is a bit tricky. given the way rebol works "never copy" makes 
much more sense, then you add copy to helpers like FUNC etc. Then, 
we can discuss whether CONTEXT should have a copy, and imho it should 
not because this "bug" never happens in practice.)

Ok, now we're getting somewhere. A question is raised, if MAKE should 
copy arguments given to it. This isn't the bug, as I see it, and 
I'll explain that a bit later.


But first, if MAKE disn't copy the body block when making a function, 
then we would be able to change the function by changing the original 
block. Like:

>> b: []   
== []
>> f: make function! [] b
>> f
>> insert b 42
== []
>> f


After the last call to f, we would get the result 42, if the body 
block wasn't copied. This is not desirable to me. Is it to you guys?

Then the MAKE object! . The block given to make this time is also 
copied, as this shows:

>> b: [a: 1]
== [a: 1]
>> o: make object! b
>> third :o     
== [a: 1]
>> same? b third :o
== false
>> append b [c: 2]
== [a: 1 c: 2]
>> third :o
== [a: 1]


So the block is copied, and then that's not the reason, the example 
from Ladislav's Bindology returns "bug".

Let's look at the example again. My version of the example is this:

f: func [x] [
    get in make object! [
        a: "ok"
        if x = 1 [
            a: "bug!"
            f 2
            a: "ok"
        ]
    ] 'a
]

I can pick the inner-most block this way:

>> b1: pick pick pick :f 2 5 7
== [
    a: "bug!" 
    f 2 
    a: "ok"
]

Now I run the example and pick the block again:

>> b2: pick pick pick :f 2 5 7
== [
    a: "bug!" 
    f 2 
    a: "ok"
]
>> same? b1 b2
== true

It's the same block.

I ran the example before b2 was picked with:

>> f 1
== "bug!"


So, running the example, which makes the object doesn't change the 
block (other than binding) and MAKE object! makes a copy of the block. 
The conclution to me is, that MAKE rebinds the block before copying 
it, where it should do that after making its copy, andt that is a 
bug.

Sorry for a couple of long posts, but this takes room to explain.

Also, if MAKE object! didn't copy the block argument, then the code 
in the block would still be in the object, and this is not desirable. 
That is, the object would hold all this information:

[
    a: "ok" 
    if x = 1 [
        a: "bug!" 
        f 2 
        a: "ok"
    ]
]

Instead of just [a: 1].

Sorry, instead of just [a: "ok"].

MAKE object! makes a copy of the block

 I gave a proof it does not make a copy. Interesting, how much you 
 try to reinvent the wheel, taking into account, that the correct 
 explanation to your results is available from public sources.

A copy of the MAKE OBJECT! block is actually never made, as this 
example shows:

b: [a: 1 "this is the block"]
o: make object! b
third o


good luck with reinventing the wheel instead of reading publicly 
availalbe sources that explain what is going on

So we're back to, it isn't a bug, that MAKE doesn't copy the block, 
when making objects. It's intended behaviour. And MAKE does copy 
the block, when making functions, and that is intended behaviour 
too. And the SECOND function doesn't try to create a block, when 
used on functions:

>> f: does []
>> same? second :f second :f
== true

while THIRD does do that, when used on objects.

Gregg, about your questions.


1) Has this behavior ever been behind a bug in any of your REBOL 
code? If so, what was the context and what was the impact (e.g., 
how did you work around it)?


I guess, you mean series inside functions. I'm not for everything 
should do a copy, as Gabriele imply. The problem with series in functions 
is only a problem, because functions in REBOL isn't functions in 
the traditional understanding. They are semi-closures. If they were 
functions, the local values would just be on the stack. Because the 
locals live on, this was a problem for me years ago. First I solved 
it by putting COPY in series definitions, then I in many cases changed 
to just do a CLEAR, like in:

local-block: clear []


Now with the discovered behaviour regarding objects, I find the binding 
rules so complicated, that I would forget, how it works in two weeks. 
I will remember, that I have to be very careful, when making objects 
inside functions, especially if it's recursive functions. The consequence 
for me is, that I will probably put COPY/DEEP in, when making objects. 
As I won't start new big projects in REBOL, I will probably not do 
this a lot in practice.

The second question was:


2) If you got your wish, what would the consequences be? i.e., how 
would it change REBOL?


When making an object in REBOL, I think of it as making a context. 
When making a function, I also assiciate this with making a context. 
If the rules were somehow similar regarding the two different contexts, 
it would be easier or more "simple", as I see it.


If your question was about binding, that I suggest blocks should 
define the binding and not each word, then that's a change, I find 
interesting but can't see the full consequences of. I think, it would 
work, and work well.

 And the SECOND function doesn't try to create a block, when used 
 on functions:
 - again, not exactly, in R3 this has changed

...Because the locals live on, this was a problem for me years ago. 
First I solved it by putting COPY in series definitions...

 - sorry to chime in, but I simply have to. The issues you mention 
 (series in functions, extent of function locals) are not related. 
 For example, the extent of function locals has changed a bit in R3, 
 while the issue with series remains unchanged.

Regarding the "MAKE FUNCTION! does not copy" versus the "BODY-OF 
function does copy" there are very good reasons why this is the best 
alternative:


1) MAKE FUNCTION! is a "lower level" approach, which should give 
the greatest flexibility. Such flexibility is achieved by not copying 
the body, which allows a custom function generator using MAKE FUNCTION! 
to make some additional adjustments to the function after the function 
has been created by MAKE FUNCTION!. An example code using this advantage 
has been committed by me to rebol.org.


2) Since the BODY-OF function does copy, a user may give a "sensitive" 
function as an argument to a "less trusted" code without having to 
fear that the "less trusted" code would modify it to achieve undesirable 
effects. This is highly practical, and not a limitation, since the 
"original body" of the function can be made available if the creator 
of the function wishes.

What about MAKE block! ? Does that include a copy? Will it in R3?

John, it sounds like where you get confused, or think of things as 
bugs or design flaws, is when having your REBOL "That's funny!" moments, 
borne of deep tinkering. Aside from the "copy series in funcs" behavior, 
which I think bites many people at some point, your issues don't 
come from writing application code in REBOL and bumping up against 
REBOL's behavior. Rather, it seems that REBOL's implementation and 
design don't match your expecations in these cases, and you really 
want it to. :-)


The reason I asked about consequences is because you may want a change 
that affects other users negatively. Imagine REBOLers as being in 
one of two groups. Group A is the gurus. They have internalized REBOLs 
design, understand it deeply, and use BIND and recursive PARSE rules 
without fear. That group is very small. Group C contains everybody 
else, which includes people that don't know about using /local with 
funcs, and suggest REBOL should use  = for "assignment". They have 
never used USE, BIND, or many other functions, because they aren't 
sure how they work. Some of them know a little about series references, 
so they always use COPY to be safe. (Yes, group B exists too, but 
they are much more like C than A).


If REBOL were meant only for A users, it would be very different. 
As a designer, it seems pragmatic to make it so things work well 
for the B and C users who, when they hit a problem that requires 
advanced understanding, will work around issues with the bits they 
understand (and adding many COPY calls), no matter how inelegant. 
Group A users may suffer at their expense, but I'm OK with that, 
because I'm not one of them.

What about MAKE block! ? Does that include a copy? Will it in R3?
 - this is a funny question. The

    make block! []


expression does make a copy of the block given, both in R2 and in 
R3. The reason is quite simple: if it did not make a copy of its 
argument it would not make a block at all.

As you may verify, all MAKE calls actually make a new value, so it 
would be a violation of that rule

Right, and I asked this question to test a general view, if MAKE 
should involve copy or not.

MAKE BLOCK! 10 does not make a copy of anything, yet it makes a new 
block as wished

Can FIND find the datatype block! among blocks in a block? Boy, does 
that sound like a strange question? An example:

>> find reduce [[] [] block!] block!     
== [[] [] block!]


That's not the result, I'm after. I want FIND to return [block!], 
but that doesn't seem to be possible. Is there a trick?

Yeah, I was thinking along the same line, doing it in two steps. 
If one wants to make a mezzanine SWITCH, it'll be slow, I guess.

A sidenote about SWITCH: I often find myself needing a switch, where 
I look for datatypes, like:

	switch type? value reduce [
		integer! [...]
		word! [...]
	]


It works, but only if I include the REDUCE, else the words in the 
block are just words. I was thinking, if SWITCH should have a refinement 
telling it to reduce the block, or something. Do you have same kind 
of switch as me?

that returns the type as a word. it seems to be made precisely for 
this scenario.

well, if the block is reduced elsewhere, that would be a problem.

I have got a question of soon-to-join-us-here reboller, asking about 
the possibility to launch new rebol process, using lowered security.

launch "some-script.r" works
lanuch "--secure allow --script some-script.r" does not work

I think I might use 'call instead?

Composing a lit-path:

>> f: [b d e f]
== [b d e f]
>> i: 2
== 2

It would be nice that instead of this:

>> compose 'f/(i)
== f/(i)

you would get:

== f/2

lit-path is a series, so I think the argument is sound for the latter 
result.

It gets rid of a workaround, where I must store a path, where some 
values in the path can't be determined until storage, the moment 
where COMPOSE needs to act. The workaround is to create the path 
as a block, and then TO-PATH it on use.

A fast way is:
>> to path! reduce ['f i]
== f/2

(Maybe the fastest?)