World: r3wp

I just hope he saw that the model wasn't good enough.

(also he apparently listened to my comments :-))

anyhow, with guides we are also no longer depending on MAX-SIZE.

Hello, jumping in

re the %rebol.r and %user.r files:
* I do not use %rebol.r for anything

* I use %user.r to set up my personal preferences on every machine 
so, that it looks like I expect it to: defining my personal "absolutely 
necessary" functions

Ladislav (continued from Rebol vs. Scheme), FUNCTOR currently isn't 
being used by any mezzanine code, so if we want to change it now 
is the time. If we go with your initialization block idea:

- The initialization would have to be performed at function creation 
time, not first call.

- The init block would be only the starting spec for the static object, 
not  the final spec. We'd need to still do the search-for-setwords 
that FUNCT does, or there'd be no point to including FUNCTOR.
- I'd suggest that the parameters be in spec, init, body order.

I essentially support Pekr's opinion about %user.r with the following 
exception:

* REBOL should be unable to overwrite %user.r when started in the 
default security mode (security reasons)

functor: func [

   "Defines a user function with all set-words collected into a persistent 
   object (self)."

    spec [block!] "Help string (opt) followed by arg words (and opt type 
    and string)"
    init [block!] "Initialization block of the persistent object"
    body [block!] "The body block of the function"
][

    make function! reduce [copy/deep spec bind/set/copy body make object! 
    init]
]


We decided to not use the term "static locals" since it would be 
confusing to people not familiar with C languages.

re Functor:

* in my opinion it does not make sense to initialize static local 
variables during function call, since they are static and therefore 
supposed to persist, so the only time suitable for the initialization 
seems to be the function creation time

* the initialization (IMO) can perfectly serve another purpose: all 
initialized (during function creation) variables shall be static, 
while the other variables shall be dynamic IMO

If the terminology does not look good, then we may probably say "persistent" 
instead of "static" meaning that the values persist during calls 
unless explicitely changed

...but if we use the term "persistent" instead of "static", what 
would be used instead of "dynamic"?

Dynamic. Local variable capture is half the point of the function, 
so making the set-words in the body persistent too is a must.

So a functor, with no variables initialized would basically not be 
a functor. You could evolve a functor with many static variables 
gradually towards a normal function with no static variables.

(with Ladislav's initialization idea.)

Ladislav, the reason we are asking about how people use %user.r is 
so that we make sure that alternate facilities exist to do what people 
did with %user.r, but safely. The old behavior of %user.r will be 
going away in R3 for security reasons. However, we have your uses 
covered by our plans:
- Preferences will be handled by the new %user.r
-You can include your must-use functions in a module.

making the set-words in the body persistent is a must

 - let me disagree with this. I think, that the INIT block is a must, 
 since the function cannot initialize the static variables as noted 
 above. OTOH, every variable not initialized during the function creation 
 time should be automatically dynamic, since it does not make much 
 sense to have it uninitialized when using it as static

Back to FUNCTOR, that and FUNCT are most often going to be used where 
the user will only specify the body, not the init or spec.

FUNCT sounds perfectly logical and usable as is, but I really cannot 
imagine the usage of a persistent value that cannot be initialized 
at function creation time

They could be initialized at first call. We already have facilities 
to do what you describe.

it simply does not make sense to me

(You mean *specifically* initialized, with the initialization block; 
they could be initialized to NONE..)

aha, during first call - how does the user find out which call is 
the first one?

VALUE?

I agree with Ladislav, using conditional code (eg. using VALUE?) 
is kind of ugly.

Actually, we are going to make a DEFAULT function, but that is one-value-at-a-time 
until DO/next works.

...the VALUE? looks inefficient and (IMO) not the proper way. Why 
should I check always something, that can be done properly just once?

Remember that the user won't be specifying the init block most of 
the time, just the body. Internal code would specify the init.

You mean the init block would be built automatically from the body 
block?

FUNCT and FUNCTOR are for defining handlers, though FUNCT is also 
used a lot in mezzanine code. The user would only specify the body 
block.

when I used a static local variable, I always initialized it at the 
function creation time using my Lfunc. I am sure I wouldn't touch 
a function with static locals not having proper initialization.

, but YMMV

We can initialize them to NONE if you like, but having them be unset 
was deemed more valuable from a debugging standpoint.

well, I do not like NONE (debugging purposes) either

I see no fault with Ladislav's proposed init block.

So far FUNCTOR hasn't really been used, so now is the time to change 
it if we are going to do so. The variable capture is a must though, 
since it will be used where the spec can't be specified by the user.

Oh, now I see what you meant about handlers.

yes, that can be used, but I suggest the uninitialized variables 
to be captured as dynamic, while the initialized be captured as static

does that make sense?

(I mean for your planned use)

In general R3 is moving towards specifying handlers as code blocks 
passed to FUNCT or FUNCTOR with standard specs specified internally. 
This is their reason for existence.

BBL, have a meeting :)

So how would a user, when specifying a handler, which becomes the 
functor body, specify that a given variable is to be static, and 
that another variable is to be dynamic?

If FUNCTOR scans the given body block and treats all variables the 
same, then that control is lost by the user. Are we happy to lose 
that control?

Maybe FUNCTOR should have the initialization block like Ladislav 
suggests, and a more specific "handler-func" function be created 
for the specific handler use Brian is talking about?

if you are asking me, then the static variables may be captured from 
the INIT block, all other from the body, but it looks, that BrianH 
intended to have all variables static in a Functor, except for the 
variables from the SPEC block

Why couldn't the init block be inside the body block, in first position?

(.... maybe not such a good idea..)

yes, then it might be better to use the same approach as the MAKE 
funtion in R3 seems to use

I need to sleep on that...

Ladislav, great to see you back!!!  Now, tell us where have you been 
and why gone so long?

One thing to remember is that these function-building functions will 
be called a lot, so fast-and-simple is better than complex.