World: r3wp

+1 hanrik

(henrik)

USE3:USE2 = 2:0

But I have no problems with #[unset!] as well. But as Henrik says, 
better to be consistent with the function initialization.

As long as they use the same start value, I'm OK with either #[unset!] 
or #[none].

they use the same start value

 - so, I understand it, that what you actually want is the consistency 
 between "initialization of function locals" and "initialization of 
 USE locals"

(not minding much what value it actually is)

yes. the end-goal would be to not need to change the body.

thanks, leaving the score as is, but making a note for myself

Good argument, Henrik.

Ladislav, you wrote "the USE function initialized the local values 
to #[unset!] for better user protection."

Better protection than what? Or what is the protection? (Or do you 
just mean USE creating locals is the protection?)

Sorry, improving the formulation:


In R2, the USE function initialized the local values to #[unset!] 
for better user protection against uninitialized variables (variables 
not initialized by the user).

At least I have been told, that was the main reason for the existence 
of the #[unset!] value

Which means, that a variable being intitialized to #[unset!] behaves 
like being "uninitialized"

I hope it is clear now

Aha, that makes sense.

I have a slight preference for unset!, but the consistency argument 
overpowers it.

Which means, if I understood you well, that your favourite behaviour 
is:

    use [a] [type? get/any 'a] ; == unset!

as well as

    do has [a] [type? get/any 'a] ; == unset!

, the current behaviour

    use [a] [type? get/any 'a] ; == none!

and

    do has [a] [type? get/any 'a] ; == none!

being the second best only?

and

type?

(sorry for the cut'n paste mess at the end)

... Yes... but, if on a scale of 0 to 100, where 0 is unset! is my 
exclusive favourite and 100 is none! is my exclusive favourite, then 
my preference is about 49, with an uncertainty of ±10.
So I don't think my vote should count for much. :)

+1 for consistency between /local and USE. Do not care much if the 
initialisation value used is none! or unset!.

So, assuming that it is "impossible to change the FUNC variable initialization 
convention", I count: USE3:USE2 = 4:0

Please don't make REBOL into Haskell ;-)

Am I to understand, that some of the USE3/USE2 variants would do 
that?

Or, did you mean another property?

+1 for R3's USE. Uninitialized variables aren't really as much of 
a problem when:
- They are declared right there where you can see them.

- They are initialized to a known value that you can rely on or test 
for.

And if we are really concerned with initializing the values, we can 
just use LET, even if we have to add it ourselves.

Oh, and -1 for "change the FUNC variable initialization convention". 
The same arguments apply to function variables.

USE3:USE2 = 5:0

Is this simply a variant of known existing issues; and, if so, is 
it what R3 intends?

    if all [return none][print "I was printed"]
        R3: ==I was printed
        R2: == ** Throw Error: Return or exit not in function

Ditto with BREAK, EXIT

Crap, that affects IF too? I'll write up a ticket.

Wait, no, that is just #1509.

Nope, right the first time.

Darn, I had to look at the types-of to be sure. It's #1509.

Thanks, Brian, That was quick -- you know your error codes!

Only the top dozen most important ones.

Ah, there will _always_ be a top 12.

Am I to understand, that some of the USE3/USE2 variants would do 
that?

Just a joke, because the talk here is awfully mathematic, while REBOL 
is based more on English

The words of REBOL are based on English. The semantics are based 
on math (though not always arithmetic).

Ah, so I was right that you would like REBOL to become Haskell

Haskell is based on some of the same math, but mostly different math. 
More lambda calculus, less (I don't remember the name for the math 
of languages with state modification).

Brian: "And if we are really concerned with initializing the values" 
- actually, I am not. I am more like one of those wanting to have 
it the same way in functions as well as in other locals. (like Henrik, 
Oldes, Anton, Andreas). That is currently the same in USE, which 
I do not object against. This way, only object (and module) fields 
are currently initialized to #[unset!], although in the newly proposed 
LET we can choose. BTW, it looks to me, that it is good, that LET 
can accept any-word!, i.e. be more flexible than USE.

On the other hand, I am not sure, whether it is a good idea to allow 
empty VARS block in LET - that looks like a user error to me.

(if I do not need any local variables, then I do not need to call 
the function creating them)

Empty vars or values blocks, like all of the other assignment-related 
characteristics of LET, serves the same purpose that they do in SET. 
Remember, a lot of the time LET will be used on data, not just inline 
words and values. Sometimes you want to screen for #[unset!], because 
being screened for is the whole point to that datatype, so setting 
it should be an option like it is with SET. Other times the words 
will be collected from the body, such as with COLLECT-WORDS/set. 
It is not necessarily an error if there are no words - it depends 
on the programmer's intention.

Doing a block with set-words set to a local context and initialized 
to none: let collect-words/set block none block. Still correct if 
there are no set-words.

Yeah, working with any-word! is good. I first read any-type!, so 
that is why I rehashed the unset argument, sorry.

My note to the "rehashed #[unset!] argument": I like the "The whole 
point of #[unset!] is to trigger errors" formulation. Nevertheless, 
it is broken in a big way by USE and function contexts. Only any-object 
contexts adhere to this convention now, so it is an error to write.:

context [
    print a
    a: 1
]

, while a corresponding

use [a] [
    print a
    a: 1
]

would be an error in R2, but not in R3 anymore, while

do has [a] [
    print a
    a: 1
]

was not an error even in R2.


Therefore,  "The whole point of #[unset!] is to trigger errors" is 
true, but, as demonstrated, the #[unset!] value is sneakingly losing 
its point to the extent, that it is becoming negligible. BTW, this 
is one more "arms race", which a protection measure is losing when 
confronted with the freedom of a programmer to write code he likes 
to write. The previous victim of this race in the datatype space 
seems to be the #[none!] value (at least to me).


I do not object, since due to the changes the #[unset!] value is 
becoming more of an annoyance, than a useful bug protection. And, 
there are other benefits, like increased compatibility between USE 
and functions, exactly as the discussion revealed, as well as the 
fact, that the protection was never as useful as it was planned to 
be.

What I see as the only problem of #[unset!] losing this arms race 
is the fact, that we will still have "debris" in programs like GET/ANY, 
SET/ANY, LET/ANY, even after the resons to have them become sneakingly 
nonexistent.

Yeah, but I'm still glad to have unset for exactly the reason it 
was intended for. Though the new unset in R3 is the unbound variable, 
which is even more useful.