World: r3wp

We only back-port stuff when its behavior is settled. Not all of 
R3 is alpha. FUNCT has been consistent for 1.5 years.

As have all of the other backports. There are almost no backports 
that haven't been solid since before modules were introduced.

yes in this case, the functionality doesn't change, only a word label, 
its a much less tedious process.

Unfortunately, we don't seem to be able to come up with a better 
name anyway :)

This is why R2/Forward is still 2.100.80.* whrn R3 is 2.100.102.

whrn
 is an example of the typo I was mentioning.

Happens all the time.

We need that 5-second rule for editing AltME messages. I do that 
a lot myslf.

Another example is renaming SINGLE? to LAST? - a good idea, but likely 
to be done as adding the name LAST?, not removing the name SINGLE?.

yes its like empty? and tail?  I coudn't live without one or the 
other, though one is more stringent...  last? and single?  should 
follow the same path.

As I said in that ticket, the strictness is an absolute feature.

Funct may have been there for 1.5 years .. but I haven't started 
using it ...

( much )

It's in the network protocols ...

but then I can just put at the top funct: :funx

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