World: r3wp

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!

None - add an /any refinement to value? (consistent with 'get)

chris, your /any refinement would likely always return true.

when rebol encounters (loads) a word with never encountered before, 
its automatically added to the globals and its is set to unset!  


so just the fact that you've actually put the word in a script, even 
if its never explicitely been explicitely managed by code yet, will 
force the value to be unset!

ex: 
>> ['!!!!!!!!]
>> probe copy/part ( sort first system/words ) 10
[! !!!!!!!! != !== * ** + ++ - --]


so you see, even using it as a lit-word, its already in the system 
words, so asking for an /any, will always return true.

Hi Chris, how a /any refinement to value shall influence the behaviour?

Max, I was thinking kind of the opposite, though it'd break the current 
usage of value?  (in truth it needs another function probably, but:

>> apple: none
== none
>> value? 'apple
== false
>> value?/any 'apple
== true
>> value?/any 'orange
== false  ; in /core at least

AFAIK, your last example would trigger true no matter how we try 
to define it, cause the fact that you wrote 'orange and loaded it, 
it is defined as unset!  ' :-/


the reason is that words actually are just integers internally, and 
loading a word adds it to that list, so it can be used later.  this 
is why word comparison is so fast, its just comparing two integers.

Chris, we have another function already: DEFAULT. It converts none 
or unset to a default value. This deals with the most common case 
of what to do when you have uninitialized values. The other cases 
are handled by ASSERT/type or conditional functions, though conditional 
functions won't work without extra help if we make optional function 
args unset by default (the extra help being UNSET?, VALUE? or get-words 
and op tricks, the hassle I was talking about earlier).

I have a host-kit, that allows multline commands.

I am thinking, if it makes sense to extend it to mulitiline strings.
How far is the console mode for R3?