World: r3wp

Really? We use it every chance we get in the mezzanines. Except where 
inappropriate, of course. It makes functions look cleaner.

That's because I'm still developing with sdk 2.7.7

And as far as I can tell, the stuff you wrote has never been properly 
documented

Which has FUNCT.

2.7.6 .... I meant

I didn't see any compelling reason to upgrade to 2.7.7

and there were a number of reports, including one from Carl, to say 
that 2.7.7 sdk was broken

Nor would I suggest it, even though 2.7.6 has known problems. You 
can grab the rest from R2/Forward anyways. I would suggest waiting 
to upgrade until 2.7.8.

Where exactly is R2/forward documented/?

In the source. But only the changes from R3 need to be documented. 
For the most part the R3 documentation should apply.

The whole point to R2/Forward was to replicate R3 behavior. And it 
does so wherever possible or practical.

R3 is alpha .. it seems to me a little odd to expect R2 users to 
have to look at R3 documentation for R2 functionality

Not all of R3 is alpha. Some of it is quite settled.

At the time of the last R2 release the documentation was being reorganized 
and no third-parties had access to it. So I couldn't update the documentation.

Can that be fixed ?

As for R2/Forward, the documentation is in the source because part 
of the purpose of the source is to document R3's and R2's behavior, 
through comparison. It should have more docs, but without the context 
that the source provides it is difficult to understand what the docs 
mean. The source is written to be readable too.

The source is where?

It can be fixed, but I don't have the time to work on extra docs 
at the moment. I wrote a lot of documentation in the R2/Forward source, 
and it has the advantage of being tied to the specific version of 
the code that it refers to.

Chat, #837, in the community libraries section.

Community/Libraries/R2-Forward

talk about obscure ...

It's not obscure, it's where community libraries go. If you are qualified 
to help with R2/Forward development, you are already participating 
in R3 development.

It works with 2.7.*, and likely earlier. My eventual goal is to make 
it work all the way back to 2.5.0, since that is the last R2 version 
on many platforms.

If you are qualified to help...
 - like that guy Graham, for instance.

I am talking about a user, one we want, who downloads view 2.7.7 
from RT's website.  He naturally wants to find documentation for 
some of the new functions.  So, it seems that you're suggesting that 
it's okay to make them sign up to devbase just to get the docs

And of course he has to know he has to do this ... and where in devbase 
to find them.

No, I was saying that 2.7.8 would include a DevBase client, but plans 
changed.

Regarding the values of "refinement arguments" - I still miss more 
opinions, than just Max's.

On one hand is the fact, that we have lots of code using this.


On the other hand is the fact, that it is a beginner's gotcha being 
incompatible with the help string of the VALUE? function, as well 
as with the behaviour of the interpreter in other, quite similar, 
cases.

If it can be changed in R3, I think that unset! makes more sense.

For unused /local values. For unused refinements I think they must 
be #[none] to be able do code like:
f: func[/switch][ if switch [ true ] ]

why unset! ?  If you've defined them, presumably the intention is 
to use them

The gotcha is not whether a variable is "defined", but whether it 
has been set.

Nevertheless, if we have a comprehensive documentation mentioning 
this, we can easily use either, since for every experienced user 
it is easy to remember that "unused refinement arguments" are set 
implicitly to #[none]

I tend to like them being NONE, but I'm not strongly opposed to using 
UNSET instead

thanks

I'm with Gabriele on that.

I am strongly in favor of optional function arguments being none 
by default. When combined with type tests that prohibit the none! 
type, it allows you to easily use data flow analysis to handle the 
control flow of the different options. You have to realize that none 
is a non-value too. The main difference between none! and unset! 
is that unset! is usually chosen when a non-value is an error, and 
none! is chosen when it is less likely to be an error. And for function 
arguments, not choosing an option is normal behavior.

Oldes, /local is just another function option, nothing special. It's 
only treated specially by the HELP function, not by function evaluation.

I thought I posted my opinion, but I prefer none. I only use unset, 
intentionally, in exceptional cases.

Ladislav, I don't have to "remember" that optional arguments are 
#[none] by default: Most of my code absolutely depends on it. Handling 
unset values is a big hassle, on purpose. I don't want to go through 
that hassle for a normal situation, just for exceptional situations. 
We are supposed to use unset! to trigger errors.

none none none...

my opinion is optionnal though

but not unset

Apparently the option was taken :)

steeve.... ;-)

Thanks, Gregg, for reminding me, I somewhat missed that your previous 
post mentioned your preference

So, currenlty I am having 9 opinions. Hoping, that I can get even 
more.

My opinion is none

None for me!