r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Robert
11-Nov-2010
[6072x2]
Excuses

 is the total wrong word and interpretation. We had this topic over-and-over 
 again: A lot say "Rebol is bad because it's not open-source.", well 
 I want to ask: "How many of you have contributed to the parts that 
 you can work on now?"
Taling is easy, doing is hard.
Pekr
11-Nov-2010
[6074]
And doing is different than designing imo, and that is my point - 
some things should still be under the supervision of RT, especially 
things that need to be designed very carefully and precisely. I have 
nothing against various experiments done by the community ....
BrianH
11-Nov-2010
[6075x3]
My list of what needs to be fixed/done before we can consider beta, 
in CureCure tickets: #539 (likely as definitional return), #851, 
#1509, #1515, #1518, #1519, #1520, #1742, #1743, maybe #1744, #1758, 
#1759. Plus all the PROTECT bugs. There isn't a single one of those 
that isn't more important than tasking or a new codec model.
And yes, I even have the numbers memorized. That is how important 
they are.
And now you can add #1760 to that list.
Pekr
11-Nov-2010
[6078]
OK, so will you talk those tickets with Carl? Because - I might surprise 
you, but I prefer consistency and bugs fixed, instead of new features 
added (of course if adding those features later will not break things 
:-)
BrianH
11-Nov-2010
[6079x2]
And #1521 (which is a side-effect of #1509 getting fixed).
I'll try to get in touch with Carl over this.
Ladislav
14-Nov-2010
[6081x2]
This one is a poll question everyone should not have trouble to answer. 
In R2, the USE function initialized the local values to #[unset!] 
for better user protection. In R3 (implementation quirk) the local 
USE variables are initialized to #[none!]. Which alternative do you 
prefer?
I, personally, do not mind much, but, depending on the result of 
this poll, I intend to adjust my policy when judging other cases, 
e.g. new functions, that are not yet implemented.
Henrik
14-Nov-2010
[6083x2]
I think it should be the same, as if you were to use those values 
local to a function. Aren't they set to #[none] there too?
I sometimes have a tendency to write code like:

use [blah] [...body...]

and later move that code to:

func [/local blah] [...body...]

and it would be nice not to have to change the body.
Ladislav
14-Nov-2010
[6085x2]
Aha, OK, so 1 for the current R3 implementation.
thanks
Oldes
14-Nov-2010
[6087x2]
+1 hanrik
(henrik)
Ladislav
14-Nov-2010
[6089]
USE3:USE2 = 2:0
Oldes
14-Nov-2010
[6090]
But I have no problems with #[unset!] as well. But as Henrik says, 
better to be consistent with the function initialization.
Henrik
14-Nov-2010
[6091]
As long as they use the same start value, I'm OK with either #[unset!] 
or #[none].
Ladislav
14-Nov-2010
[6092x2]
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)
Henrik
14-Nov-2010
[6094]
yes. the end-goal would be to not need to change the body.
Ladislav
14-Nov-2010
[6095]
thanks, leaving the score as is, but making a note for myself
Anton
14-Nov-2010
[6096]
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?)
Ladislav
14-Nov-2010
[6097x4]
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
Anton
14-Nov-2010
[6101x2]
Aha, that makes sense.
I have a slight preference for unset!, but the consistency argument 
overpowers it.
Ladislav
14-Nov-2010
[6103x2]
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)
Anton
14-Nov-2010
[6105]
... 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. :)
Andreas
14-Nov-2010
[6106]
+1 for consistency between /local and USE. Do not care much if the 
initialisation value used is none! or unset!.
Ladislav
14-Nov-2010
[6107]
So, assuming that it is "impossible to change the FUNC variable initialization 
convention", I count: USE3:USE2 = 4:0
Kaj
14-Nov-2010
[6108]
Please don't make REBOL into Haskell ;-)
Ladislav
14-Nov-2010
[6109x2]
Am I to understand, that some of the USE3/USE2 variants would do 
that?
Or, did you mean another property?
BrianH
14-Nov-2010
[6111x3]
+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.
Ladislav
14-Nov-2010
[6114]
USE3:USE2 = 5:0
Sunanda
14-Nov-2010
[6115]
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
BrianH
14-Nov-2010
[6116x4]
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.
Sunanda
14-Nov-2010
[6120]
Thanks, Brian, That was quick -- you know your error codes!
BrianH
14-Nov-2010
[6121]
Only the top dozen most important ones.