World: r3wp
[!REBOL3]
older newer | first last |
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. |
older newer | first last |