[REBOL] RFF: empty? for blocks Re:(7)
Maybe so. It's sad an extra layer of logic has to be added across the board to deal with outlying cases. If my understanding of how REBOL works is correct, it's not a matter of an extra layer of logic. The current layer of logic is simply defective. I don't believe that the seminal variable actually owns the block, and so all pointers to the block should be able to tell when the block has been truncated, and robustly return NONE. This is the documented behaviour. IMHO, I don't believe the developers would want us to quietly "make do" and workaround this early in the game. And, it's very possible that once the code is fixed, the documentated behaviour will not degrade performance (because this is how REBOL was designed to work). Heck, fior all we know, the bug and it's side-effects could be slowing things down. So I would vote to change the meaning of empty? to head tail? I think that's why there is a synomyn " head tail?" just sounds topsy-turvey. Though, empty? being a snyomyn for "head tail? would be consistent with the way append works, which is basically the same as "insert tail". If I reverse the example, clearing list2 instead of list, I get the correct behavior: list: [1 2 3 4] == [1 2 3 4] list2: next list == [2 3 4] clear list2 == [] list2 == [] list == [1] In this example list is still at the head. The bug doesn't occur when the other variable is at the head or the tail. Try list: [1 2 3 4] == [1 2 3 4] list2: HEAD list == [1 2 3 4] list: NEXT list == [2 3 4] ... -Ted.
[REBOL] RFF: empty? for blocks Re:(2)
By the Dictionary: "empty? This is a synonym for TAIL? The check is made relative to the current location in the series." Most of the problems here seem to be semantics. When we create a series, we (usually) assign a variable to a location in that series. But the variable and the series are two separate things. The variable and the series are two separate things. The variable and the series are two separate things. This is important: The variable and the series are two separate things. Using a variable in a Core series operation does not automatically change it's value (or index). All the operations return a new value (or index) that you can use, or ignore. The original, seminal variable is not an automatic "cursor" into the series. It has no special privileges, and any other variable pointing to the series will work just as well (right down to the bugs). The variable and the series are two separate things. As mentioned by others, the proper way to determine if an entire series is empty is to test the series from its head empty? head aSeries It's very important to understand that this does not test whether "aSeries" is empty. aSeries is not itself a series, it is an index to a position in a series.This is a subtle but crucial point, and explains why the series operations work the way they do. " ... the block exists on its own, and that colors simply refers to the head of the block." In other languages, we would usually have to use extra punctuation to "dereference" a pointer to another variable, but REBOL handles this all automatically (and consistently!). Every series is a movie, and all the variables only frames. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/
[REBOL] RFF: empty? for blocks Re:(5)
On 13-Dec-99, [EMAIL PROTECTED] wrote: There is one painful exception that does not fit in this metaphor. That is the reported case: list: [1 2 3 4] list2: next list clear list list2 == [2 3 4] Here list2 should not report [2 3 4]. It should report []. Since the movie contains zero frames, list2 should not recall that there were frames at the time it was assigned the value: next list. To accomplish that, list2 must negotiate its value with the movie when it reports the frames it is assigned to. If it only sticks to its own offset into the block that was cleared, it apparently finds the old values because they were not physically removed. List2 becomes painfully aware that the movie was modified when it tries to respond to stuff like length?: length? list2 ** Script Error: Out of range or past end. ** Where: length? list2 It seems to me the problem is the command "clear". Consider the analogous sequence in Scheme : (set! list1 '(1 2 3 4)) #[undefined] : list1 (1 2 3 4) : (set! list2 (cdr list1)) #[undefined] : list2 (2 3 4) : (set! list1 '()) #[undefined] : list1 () : list2 (2 3 4) : (length list2) 3 Note that in Scheme there is no destructive command "clear", instead list1 has to be "set!" to the empty list, which is a new empty list and leaves list2 unaffected. Shouldn't "clear" work the same way? i.e. create a new empty list. Brent Meeker
[REBOL] RFF: empty? for blocks Re:(7)
If one insists on establishing two words referring to the same data, then before one clears one he should 'unset the other. Personally, I'd like a determination from REBOL Tech on whether "using two words to refer to the same data" is bad practice, or whether we're just encounting bugs in some of the series functions, particularly CLEAR. The examples in the docs do seem to encourage using multiple variables, and imply the only time we should get errors is when using "The functions first, second, third, fourth, fifth, and last" (use PICK instead). Everything else is suppose to return NONE or an empty block. In further testing, I'm finding that CLEAR seems to work properly if the other variables are at the head or tail, but not when they are set to another index. *** REPLY SEPARATOR *** On 12/12/1999 at 3:29 PM [EMAIL PROTECTED] wrote: REBOL's clear and Scheme's clear are not analogous. REBOL's clear doesn't clear the stored data, it "disconnects" 'list (your example) from it and eventually the garbage collector reclaims the unused memory where the data is stored. REBOL's 'clear is a lot faster, especially for large series. If you want list2 to reference the same data, but copied to a fresh location, use copy, i.e., list2: copy next list. This allows you to mess with 'list without affecting 'list2. If one insists on establishing two words referring to the same data, then before one clears one he should 'unset the other. Perhaps 'unset should be used in place of 'clear. Here's some diddling around with unset. list1: [1 2 3 4] == [1 2 3 4] list2: next list1 == [2 3 4] unset [list2] list2 ** Script Error: list2 has no value. ** Where: list2 list1 == [1 2 3 4] list2: next list1 == [2 3 4] unset [list1] list2 == [2 3 4] head list2 == [1 2 3 4] list1 ** Script Error: list1 has no value. ** Where: list1 unset[list2] list2 ** Script Error: list2 has no value. ** Where: list2 Note unset-ing list1 doesn't seem to bother list2 Russell [EMAIL PROTECTED]
[REBOL] RFF: empty? for blocks Re:(6)
It seems to me the problem is the command "clear". Consider the analogous sequence in Scheme The sequence in Scheme is not analogous. It is analogous to the following in REBOL: list: [1 2 3 4] list2: copy next list Elan
[REBOL] RFF: empty? for blocks Re:(2)
Hi Eric, Clearing from the head of the data while you've got other pointers farther along in the series doesn't make sense, which is no doubt why this bug has taken so long to be discovered. Oh well, different things make sense to different people. I think that the evaluation of a sequence of legal expressions should not result in an error. Isn't that a necessary formal criteria of the language definition? Elan
[REBOL] RFF: empty? for blocks Re:(3)
Hi Elan I agree. There is definitely a bug. And it is much worse than just getting an error message. a == [[1 2] [3 4]] b == [[1 2 3] [3 4 5]] a: [1 2 3 4] == [1 2 3 4] b: next a == [2 3 4] clear a == [] c: make block! form b == [2 3 4] head c == [2 3 4] d: make block! b Gives pop-up window: Fatal System Error **Crash(Should not happen) - Corrupt datatype 62 Notice that form is able to recover the information in b into a normal block c. Jim said this is a bug in FORM. It should recognize that the length of b has changed. This is logged as a bug at REBOL tech. I also submitted the fatal system error and it was verified by Bo. Error messages for valid statements are a problem, but certainly the interpreter should not crash with a sytem error. I believe the bug lies deeper in the system. FORM is misled because the system itself has lost track of whats going on. Comments? Larry :) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 12, 1999 6:19 PM Subject: [REBOL] RFF: empty? for blocks Re:(2) Hi Eric, Clearing from the head of the data while you've got other pointers farther along in the series doesn't make sense, which is no doubt why this bug has taken so long to be discovered. Oh well, different things make sense to different people. I think that the evaluation of a sequence of legal expressions should not result in an error. Isn't that a necessary formal criteria of the language definition? Elan
[REBOL] RFF: empty? for blocks Re:(5)
Wow. You may never know just how right on the money the above statement is! It is a very good analogy.In fact, in the same sense, all of REBOL is a movie, and all variables are frames of the big REBOL movie. :-) There isone painful exception that doesnot fit in this metaphor. That is the reported case: list: [1 2 3 4] list2: next list clear list list2 == [2 3 4] Looks like a bug to me. [ . . . ] I believe that the "cheapest" way for handling it correctly is to have every word that references a series negotiate the legality of its offset before it attempts to access the series at that offset and it should report some indication that its offset into the series is illegal whenever that is the case. Maybe so. It's sad an extra layer of logic has to be added across the board to deal with outlying cases. -jeff
[REBOL] RFF: empty? for blocks Re:(6)
Hi Jeff,
Maybe so. It's sad an extra layer of logic has to be added
across the board to deal with outlying cases.
I was thinking the exact same thing. Do you thing it will introduce a
signficant overhead? Can leaving it as is be justified with the additional
overhead it would introduce?
Is more needed than saying something like:
list: [1 2 3 4]
list = current-index: 1
data: data-structure
data-structure= block-frame: address
length: 4
if (current-index(list) = date-structure-length) {
return (access_block(list))
} else { return -1 }
(Stylized C, I don't even remember what C looks like. Haven't looked at or
typed anything but REBOL for some time now. Yikes.)
Elan
[REBOL] RFF: empty? for blocks Re:(4)
Hi Jerry, What do you think of this sequence of legal expressions? a: 1e150 print a * a Print a * a * a 1E+300 ** Math Error: Math or number overflow. ** Where: Print a * a * Numbers are defined together with a range that informs you about their limit (see the User's Guide). I don't think that this example is really relevant to the bug that had been uncovered in this thread. Elan
[REBOL] RFF: empty? for blocks Re:(4)
See? I guess you have to use 'copy to be sure. Thanks, Rachid, but the original idea was to have duplicate pointers to the same block. Copying would defeat that purpose. Coincident with the empty thread, consider this: list1: [1 2] == [1 2] list2: next list1 == [2] empty? list2 == false clear list1 ==[] empty? list1 == true empty? list2 ** Script Error: Out of range or past end. ** Where: empty? list2 Again, REBOL allows us duplicate pointers but does not synchronize them properly when one pointer clears the list. *** REPLY SEPARATOR *** On 12/11/1999 at 6:52 AM [EMAIL PROTECTED] wrote: Hello Ted, Here's something else that I find confusing: list: [ 1 2 3 4 ] == [ 1 2 3 4 ] list2: next list == [ 2 3 4 ] clear list == [] list2: == [ 2 3 4 ] next list2: ** Script Error: Out of Range or Past End About every other operation I try with list2 errors. Exceptions are that I can assign it to another variable and print it. Suddenly I remembered, list2 is nothing more than the location of 'next list, so the printing thing I can't explain, but take a look at this: pnt1: [1 2 3 4 5] == [1 2 3 4 5] pnt2: next pnt1 == [2 3 4 5] replace pnt1 4 6 == [1 2 3 6 5] print pnt2 2 3 6 5 See? I guess you have to use 'copy to be sure. Regards, Rachid
[REBOL] RFF: empty? for blocks Re:(5)
See below: Russell [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, December 11, 1999 4:16 AM Subject: [REBOL] RFF: empty? for blocks Re:(4) See? I guess you have to use 'copy to be sure. Thanks, Rachid, but the original idea was to have duplicate pointers to the same block. Copying would defeat that purpose. Coincident with the empty thread, consider this: list1: [1 2] == [1 2] list2: next list1 == [2] empty? list2 == false clear list1 ==[] empty? list1 == true empty? list2 ** Script Error: Out of range or past end. ** Where: empty? list2 Again, REBOL allows us duplicate pointers but does not synchronize them properly when one pointer clears the list. I'm guessing 'clear probably doesn't "clear" the data referenced by list1 and list2, but manipulates the position pointer info carried by list1, "polluting" the position info in list2. But isn't it expecting a lot, or causing a lot of overhead, to require list1 to know about all the other words referring to the same data? Every such word would have to know about all the others?? Or am I not getting this?
[REBOL] RFF: empty? for blocks Re:(6)
But isn't it expecting a lot, or causing a lot of overhead, to require LIST1 to know about all the other words referring to the same data? Good question -- How should we expect these operations to perform when more than one variable points to the same series? The docs say: "It is crucial for you to realize that the block exists on its own, and that COLORS simply refers to the head of the block." http://www.rebol.com/users.html#Traversing So, it's not a matter of LIST1 (or COLORS) knowing about the other variables pointing to it. Both LIST1 and all other variables point to a block which exists independently of LIST1. (Just as a person exists independantly of an email address or Social Security Number.) We're also warned that: "The change, insert, remove, and clear functions directly affect the series provided as the first argument. If you have other variables that refer to the same series, after the operation they may no longer reference the same value within the series." http://www.rebol.com/users.html#Modifying and that "If a series function attempts to access a value that is beyond the head or tail of a series, it will return none to indicate that there was a problem." http://www.rebol.com/users.html#Dealing So it seems the expected response of several of the examples posted should have been: == none or == false rather than == ** Script Error: Out of range or past end. *** REPLY SEPARATOR *** On 12/11/1999 at 11:22 AM [EMAIL PROTECTED] wrote: I'm guessing 'clear probably doesn't "clear" the data referenced by list1 and list2, but manipulates the position pointer info carried by list1, "polluting" the position info in list2. But isn't it expecting a lot, or causing a lot of overhead, to require list1 to know about all the other words referring to the same data? Every such word would have to know about all the others?? Or am I not getting this?
[REBOL] RFF: empty? for blocks Re:
Hi Rachid, EMPTY? and TAIL? really are the same: same? :empty? :tail? == true I think you may be confusing TAIL, which returns a pointer to just past the last element of a series, and TAIL? and EMPTY? which return true if a pointer to a series is past the last element. My example was weird because I just wanted to construct a series and set a pointer to its tail in one step - of course I don't normally do that. It's easy enough to set TEST-BLOCK back to its head with: test-block: tail [1 2 3 4 5] == [] test-block: head test-block == [1 2 3 4 5] index? test-block == 1 So, while TEST-BLOCK might not be in the best of health, it isn't all that sick either. But, if you use FORALL or traverse a series in some other way, it often happens that you'll end up with words bound to pointers to the ends of series. Sometimes I use a construct like: while [not tail? pointer][ either [] [pointer: remove pointer][pointer: next pointer] ] where I delete elements I don't want and skip elements I want to keep. At the end of this loop, if I want to find out if I have any elements left I have to do, if empty? head pointer [] where, as Robert said, it would be nicer to just get by with, if empty? pointer [] See you, Eric Original message Hi Eric, Empty? isn't a synonym for tail?, as far as I know. Your example is a weird construction, because if I try to test empty? with tail I do this: test: [1 2 3] == [1 2 3] tail test == [] empty? test == false Why do you do: test-block: tail [1 2 3 4 5] It strikes me strange to define 'test-block with the index at the tail. It influences 'test-block from the get-go: test-block: tail [1 2 3 4 5] == [] index? test-block == 6 head test-block == [1 2 3 4 5] index? test-block == 6 While: test: [1 2 3] == [1 2 3] index? test == 1 tail test == [] index? test == 1 The index is set to 6 no matter what, and I don't think that's "healthy" for a block. =) Regards, Rachid
[REBOL] RFF: empty? for blocks Re:(3)
[EMAIL PROTECTED] wrote: Good idea. empty?'s current functionality is supplied by the word tail? We don't lose functionality by modifying the word empty?. Another option would be to supply a word really-empty? ;-) Yup. Something like: really-empty?: func [s [series!]] [empty? head s] I think :empty?'s behaviour is understandable: length? tail series will always return 0. So empty? tail series should return true... Ciao, /Gabriele./ o) .-^-. (--o | Gabriele Santilli / /_/_\_\ \ Amiga Group Italia --- L'Aquila | | GIESSE on IRC \ \-\_/-/ / http://www.amyresource.it/AGI/ | o) `-v-' (--o
[REBOL] RFF: empty? for blocks Re:(5)
Larry, Jim, others, This has been entered! On 9-Dec-1999/13:49:41-8:00, [EMAIL PROTECTED] wrote: Hi Larry, This is a bug in FORM that should notice that the length of the block has been changed. I trust that Bo will log it... ;-) - jim At 10:40 AM 12/9/99 -0800, you wrote: Hi Ted You have been raising some interesting questions in recent posts. Adding another twist: a: [1 2 3 4] == [1 2 3 4] b: next a == [2 3 4] clear a == [] next b ** Script Error: Out of range or past end. ** Where: next b c: make block! form b == [2 3 4] next c == [3 4] head c == [2 3 4] So the values in b are still there and can be recovered into a new block and accessed normally! I hope someone can explain this to us. Larry:-) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 09, 1999 2:42 AM Subject: [REBOL] RFF: empty? for blocks Re:(2) Here's something else that I find confusing: list: [ 1 2 3 4 ] == [ 1 2 3 4 ] list2: next list == [ 2 3 4 ] clear list == [] list2: == [ 2 3 4 ] next list2: ** Script Error: Out of Range or Past End About every other operation I try with list2 errors. Exceptions are that I can assign it to another variable and print it. The exceptions are what confuse me. After clearing list, why does list2 print anything at all? Is this part of the garbage collection bug people mention? (Is the infamous garbage collection bug documented yet?) *** REPLY SEPARATOR *** snip- -- Bohdan "Bo" Lechnowsky REBOL Adventure Guide REBOL Technologies 707-467-8000 (http://www.rebol.com) Download the REBOL Messaging Language for all Platforms
[REBOL] RFF: empty? for blocks Re:(3)
Hello Ted, Here's something else that I find confusing: list: [ 1 2 3 4 ] == [ 1 2 3 4 ] list2: next list == [ 2 3 4 ] clear list == [] list2: == [ 2 3 4 ] next list2: ** Script Error: Out of Range or Past End About every other operation I try with list2 errors. Exceptions are that I can assign it to another variable and print it. Suddenly I remembered, list2 is nothing more than the location of 'next list, so the printing thing I can't explain, but take a look at this: pnt1: [1 2 3 4 5] == [1 2 3 4 5] pnt2: next pnt1 == [2 3 4 5] replace pnt1 4 6 == [1 2 3 6 5] print pnt2 2 3 6 5 See? I guess you have to use 'copy to be sure. Regards, Rachid
[REBOL] RFF: empty? for blocks Re:(2)
Hi Eric, Empty? isn't a synonym for tail?, as far as I know. Your example is a weird construction, because if I try to test empty? with tail I do this: test: [1 2 3] == [1 2 3] tail test == [] empty? test == false Why do you do: test-block: tail [1 2 3 4 5] It strikes me strange to define 'test-block with the index at the tail. It influences 'test-block from the get-go: test-block: tail [1 2 3 4 5] == [] index? test-block == 6 head test-block == [1 2 3 4 5] index? test-block == 6 While: test: [1 2 3] == [1 2 3] index? test == 1 tail test == [] index? test == 1 The index is set to 6 no matter what, and I don't think that's "healthy" for a block. =) Regards, Rachid
[REBOL] RFF: empty? for blocks Re:
[EMAIL PROTECTED] wrote: Hi, I would like to propose that empty? should be useable with blocks and return true if the block doesn't contain an element. empty? [] == true Ciao, /Gabriele./ o) .-^-. (--o | Gabriele Santilli / /_/_\_\ \ Amiga Group Italia --- L'Aquila | | GIESSE on IRC \ \-\_/-/ / http://www.amyresource.it/AGI/ | o) `-v-' (--o
[REBOL] RFF: empty? for blocks Re:(2)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 09, 1999 3:10 AM To: [EMAIL PROTECTED] Subject: [REBOL] RFF: empty? for blocks Re: empty? is kind of confusing, since it's just a synonym for tail? and doesn't really tell you if there are no elements in the block, as there might be some before the index point: Hi, that's the point (!!) and that's why I don't use empty? blind less with blocks. You can always use: empty? head test-block == false to find out if test-block is really empty. Well, I would like to avoid this and that's why I would like to see that empty? works on the whole block and not in relation to the index point. Robert
[REBOL] RFF: empty? for blocks Re:(3)
[EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 09, 1999 3:10 AM To: [EMAIL PROTECTED] Subject: [REBOL] RFF: empty? for blocks Re: empty? is kind of confusing, since it's just a synonym for tail? and doesn't really tell you if there are no elements in the block, as there might be some before the index point: Hi, that's the point (!!) and that's why I don't use empty? blind less with blocks. You can always use: empty? head test-block == false to find out if test-block is really empty. Well, I would like to avoid this and that's why I would like to see that empty? works on the whole block and not in relation to the index point. Hmm, I am not sure it would be good, as REBOL is full of references. block: ["A" "B" "C" "D" "E"] blk: at block 3 ["C" "D" "E"] for me, blk is starting from "C", ending with "E", and it's OK, even empty should return false ... What's was more confusing for me is print head blk, it returns ["A" "B" "C" "D" "E"] and I was pretty nervous about it during my beginnings with REBOL, as we clearly said blk should point "at block 3". So tail blk should return "E", while head blk should return "C" imho. Maybe also possibility to double-index would be nice as it would not require us to use copy/part :-) blk: at/double block 3 4 ["C" "D"] - result is still just pointing to original block, while it's 'last element is "D" instead of "E" The problem is 1) I don't know if it's easy achievable and even if it would find practical usage for us 2) it's limited to function as 'at e.g., but maybe even 'next or so could be refined ... Just my thoughts, you can easily ignore them :-) Cheers, -pekr- Robert
[REBOL] RFF: empty? for blocks Re:(3)
Hi, what you uncovered here is very interesting indeed. Have you reported it as a bug? Once can summarize your observation like this: list: [1 2 3 4] == [1 2 3 4] list2: next list == [2 3 4] list2 == [2 3 4] head list2 == [1 2 3 4] clear list == [] list2 == [2 3 4] head list2 == [] 1. When list is cleared, the memory it occupies is not nulled out. 2. List2 accesses list's memory storage directly at the offset it saves for itself (i.e. current index set to two). 3. Whenever you do something that modifies something about list2, list2 appears to consult with list's settings and discovers that list has been cleared and acts accordingly: list: [1 2 3 4] == [1 2 3 4] list2: next list == [2 3 4] clear list == [] insert list2 100 ** Script Error: Out of range or past end. ** Where: insert list2 100 That's drastic. Elan At 05:42 AM 12/9/99 -0500, you wrote: Here's something else that I find confusing: list: [ 1 2 3 4 ] == [ 1 2 3 4 ] list2: next list == [ 2 3 4 ] clear list == [] list2: == [ 2 3 4 ] next list2: ** Script Error: Out of Range or Past End About every other operation I try with list2 errors. Exceptions are that I can assign it to another variable and print it. The exceptions are what confuse me. After clearing list, why does list2 print anything at all? Is this part of the garbage collection bug people mention? (Is the infamous garbage collection bug documented yet?) *** REPLY SEPARATOR *** On 12/9/1999 at 11:10 AM [EMAIL PROTECTED] wrote: Robert, empty? is kind of confusing, since it's just a synonym for tail? and doesn't really tell you if there are no elements in the block, as there might be some before the index point: test-block: tail [1 2 3 4 5] == [] empty? test-block == true head test-block == [1 2 3 4 5] You can always use: empty? head test-block == false to find out if test-block is really empty. See you, Eric
[REBOL] RFF: empty? for blocks Re:(2)
At 03:10 PM 12/9/99 +0100, you wrote: [EMAIL PROTECTED] wrote: Hi, I would like to propose that empty? should be useable with blocks and return true if the block doesn't contain an element. empty? [] == true Good idea. empty?'s current functionality is supplied by the word tail? We don't lose functionality by modifying the word empty?. Another option would be to supply a word really-empty? ;-) So you could say: if empty list2 [really-empty? list2] Elan
[REBOL] RFF: empty? for blocks Re:(3)
Hi Ted You have been raising some interesting questions in recent posts. Adding another twist: a: [1 2 3 4] == [1 2 3 4] b: next a == [2 3 4] clear a == [] next b ** Script Error: Out of range or past end. ** Where: next b c: make block! form b == [2 3 4] next c == [3 4] head c == [2 3 4] So the values in b are still there and can be recovered into a new block and accessed normally! I hope someone can explain this to us. Larry:-) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 09, 1999 2:42 AM Subject: [REBOL] RFF: empty? for blocks Re:(2) Here's something else that I find confusing: list: [ 1 2 3 4 ] == [ 1 2 3 4 ] list2: next list == [ 2 3 4 ] clear list == [] list2: == [ 2 3 4 ] next list2: ** Script Error: Out of Range or Past End About every other operation I try with list2 errors. Exceptions are that I can assign it to another variable and print it. The exceptions are what confuse me. After clearing list, why does list2 print anything at all? Is this part of the garbage collection bug people mention? (Is the infamous garbage collection bug documented yet?) *** REPLY SEPARATOR *** snip-
[REBOL] RFF: empty? for blocks Re:(4)
Hi Larry, This is a bug in FORM that should notice that the length of the block has been changed. I trust that Bo will log it... ;-) - jim At 10:40 AM 12/9/99 -0800, you wrote: Hi Ted You have been raising some interesting questions in recent posts. Adding another twist: a: [1 2 3 4] == [1 2 3 4] b: next a == [2 3 4] clear a == [] next b ** Script Error: Out of range or past end. ** Where: next b c: make block! form b == [2 3 4] next c == [3 4] head c == [2 3 4] So the values in b are still there and can be recovered into a new block and accessed normally! I hope someone can explain this to us. Larry:-) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 09, 1999 2:42 AM Subject: [REBOL] RFF: empty? for blocks Re:(2) Here's something else that I find confusing: list: [ 1 2 3 4 ] == [ 1 2 3 4 ] list2: next list == [ 2 3 4 ] clear list == [] list2: == [ 2 3 4 ] next list2: ** Script Error: Out of Range or Past End About every other operation I try with list2 errors. Exceptions are that I can assign it to another variable and print it. The exceptions are what confuse me. After clearing list, why does list2 print anything at all? Is this part of the garbage collection bug people mention? (Is the infamous garbage collection bug documented yet?) *** REPLY SEPARATOR *** snip-
[REBOL] RFF: empty? for blocks Re:(5)
These problems can be avoided by always using 'copy to create a new copy of the original data. a: [1 2 3 4] == [1 2 3 4] b: copy next a == [2 3 4] clear a == [] next b == [3 4] I've found this a good practice. If 'copy isn't used, b is another word pointing to the same data with a changed pointer. But it looks like a bug if clearing a doesn't also clear the pointer. Maybe the 'clear operation doesn't clear the data but only affects the pointer? Anyhow, 'copy is the way to avoid trouble, in my experience. Russell [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 09, 1999 2:55 PM Subject: [REBOL] RFF: empty? for blocks Re:(4) Now duly reported to feedback, with Larry's addendum. *** REPLY SEPARATOR *** On 12/9/1999 at 10:10 AM [EMAIL PROTECTED] wrote: Hi, what you uncovered here is very interesting indeed. Have you reported it as a bug? -- Ted Husted, Husted dot Com, Fairport NY USA. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/
[REBOL] RFF: empty? for blocks Re:
Robert, It does, doesn't it? empty? [] == true On 8-Dec-1999/16:30:03+1:00, [EMAIL PROTECTED] wrote: Hi, I would like to propose that empty? should be useable with blocks and return true if the block doesn't contain an element. Robert M. Muench, Karlsruhe, Germany == ask for PGP public-key == When do you want to reboot today? Use the free portable GUI Library OpenAmulet from http://www.openip.org -- Bohdan "Bo" Lechnowsky REBOL Adventure Guide REBOL Technologies 707-467-8000 (http://www.rebol.com) Download the REBOL Messaging Language for all Platforms
[REBOL] RFF: empty? for blocks Re:
Robert,
It seems to me it already does:
empty? []
== true
empty? [1 2 3]
== false
empty? {}
== true
empty? { }
== false
Jerry
