Mailing List Archive: 49091 messages

# Bug! - 'second on object containing ONE hash! has TWO hash! !!

### [1/6] from: al::bri::xtra::co::nz at: 5-Oct-2000 19:40

>> o: make object! [h: make hash! []] >> o/h
== make hash! []
>> second o
== [ make object! [ h: make hash! [] ] make hash! [...]]
>> append o/h 1
== make hash! [1]
>> second o
== [ make object! [ h: make hash! [1] ] make hash! [...]]
>>
I'm fairly sure that this line: make hash! [...] shouldn't be present in 'o. Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

### [2/6] from: kgd03011:nifty:ne:jp at: 6-Oct-2000 12:36

Hi Andrew, Are you pulling our leg? Remember 'self ?
>> o: make object! [h: make hash! []] >> second o/self
== [ make object! [ h: make hash! [] ] make hash! []]
>> second o/self/self
== [ make object! [ h: make hash! [] ] make hash! []]
>> o/self/self/self/self/self/self/h
== make hash! [] This is with the non-experimental REBOL/Core. It's interesting that /View thinks it's necessary to put the ... indicating recursion when there's no recursion involved. Maybe THAT's a bug. Eric

### [3/6] from: larry:ecotope at: 5-Oct-2000 20:53

Hi Andrew Well, the TWO hash is not a problem and has always been this way. Remember that every object! has the reference 'self as its first element. Second returns a block with the values of every set-word in the object including the complete object as the value of 'self. Probe avoids showing the value of 'self. It is interesting that second shows the actual hash as having the value [...] which is the new indicator for a recursive block, hash, list, object, etc. Probe shows the actual value, as does
>>mold second second o
It would be nice to hear from RT as to whether the [...] in your example is the intended behavior. In any case, everything about the object and it use is functional, it can be saved, loaded, etc. You can bind to the hash, etc. BTW The same thing happens with when you put a block, list, or another object in the outer object. Here is a related fun puzzle ;-)
>> b: [1 2]
== [1 2]
>> b/2: b
== [1 [...]]
>> save %junk.txt b >> b2: load %junk.txt
== [1 [...] ]
>> second b
== [1 [...]]
>> second b2
== [...]
>> first second b
== 1
>> first second b2
== ... So it is possible to create a block which cannot be saved and loaded. This may be a bug in load. Only RT knows what lurks in the heart of REBOL. ;-) Cheers -Larry PS You can make a recursive block which cannot be saved and loaded. ----- Original Message ----- From: <[Al--Bri--xtra--co--nz]> To: <[list--rebol--com]> Cc: <[list--rebol--com]> Sent: Thursday, October 05, 2000 8:40 PM Subject: [REBOL] Bug! - 'second on object containing ONE hash! has TWO hash! !!

### [4/6] from: larry:ecotope at: 5-Oct-2000 21:14

Hi Eric Well, you beat me to it again. Just a quick comment. You wrote
> >> o/self/self/self/self/self/self/h > == make hash! [] > > This is with the non-experimental REBOL/Core. It's interesting that /View > thinks it's necessary to put the ... indicating recursion when there's no > recursion involved. Maybe THAT's a bug.
The line:
>>o/self/self/self/self/self/self/h
certainly indicates recursion. What is curious is that the ... shows up for the value block of the hash and has never showed up for the obvious recursive self-reference of 'self. I would be interested in your comments on the puzzle I gave in my own response to Andrew, if it ever appears on the list. See you -Larry

### [5/6] from: al:bri:xtra at: 5-Oct-2000 22:15

Eric wrote:
> Hi Andrew,
Hi, Eric!
> Are you pulling our leg? Remember 'self ?
>> o: make object! [b: make block! [] b2: make block! [] b3: make block! []] >> print mold second o
[ make object! [ b: [] b2: [] b3: [] ] [] [] []]
>> > This is with the non-experimental REBOL/Core. It's interesting that /View
thinks it's necessary to put the ... indicating recursion when there's no recursion involved. Maybe THAT's a bug. I was sure I hadn't seen this behaviour before, but it does seem to be in old Core as well. It _is_ unexpected to me, as I had believed that 'second on a object returned the object's code. second seems to return the storage? of the object:
>> print mold second o
[ make object! [ b: [1] b2: [2] b3: [] ] [1] [2] []] Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

### [6/6] from: kgd03011:nifty:ne:jp at: 6-Oct-2000 15:36

Hi Larry,
>It is interesting that second shows the actual hash as having the value >[...] which is the new indicator for a recursive block, hash, list, object, >etc. Probe shows the actual value, as does > >>>mold second second o > >It would be nice to hear from RT as to whether the [...] in your example is >the intended behavior.
It seems the algorithm for detecting recursive blocks is a little too simple-minded. When REBOL is representing a value, anytime it re-encounters the same block, the contents of that block are replaced with [...] . So some things have become a little weird: /Core 2.3 :
>> head insert/only/dup [] [] 5
== [[] [] [] [] []] /View 0.10.38 :
>> head insert/dup/only [] [] 5
== [[] [...] [...] [...] [...]] But if you have the same block alternating within another block the ... don't show: /View 0.10.38 :
>> b: [[1] [2]]
== [[1] [2]]
>> bb: []
== []
>> insert/dup bb b 4
== []
>> bb
== [[1] [2] [1] [2] [1] [2] [1] [2]] Of course these really are the same blocks:
>> b/1/1: 3
== [3]
>> bb
== [[3] [2] [3] [2] [3] [2] [3] [2]]
>Here is a related fun puzzle ;-) > >>> b: [1 2] >== [1 2] >>> b/2: b >== [1 [...]]
I'm not quite sure what the puzzle is ... The ... here is only an artifact used to prevent stack overflow. AFAIK this hasn't been possible until the recent experimental releases. It causes a stack overflow with /Core 2.3 .
>>> save %junk.txt b >>> b2: load %junk.txt
<<quoted lines omitted: 8>>
>>> first second b2 >== ...
The ... here is now a word!
>So it is possible to create a block which cannot be saved and loaded. This >may be a bug in load. Only RT knows what lurks in the heart of REBOL. ;-)
Lots of things get converted to words when you save and load them: TRUE, FALSE, NONE and all the datatypes. Of course you can often reduce a block to get the original values back. '... doesn't usually have any value, and even if LOAD or REDUCE recognized this as a recursed block, it would often be impossible to tell at what level a block was being recursed. Also, LOAD has never been able to deal with the distinction between blocks that are the same, and those that are merely equal. Both same and identical blocks wind up as merely equal. And now there will be some same blocks reloaded with an extraneous word in them.
>Cheers >-Larry
<<quoted lines omitted: 4>>
>the value block of the hash and has never showed up for the obvious >recursive self-reference of 'self.
As you explained to Andrew, mold avoids representing 'self and its value. With the ... convention, you could represent an object as: make object! [ self: make object! [ ... ] a: "some value" ] but that would make problems for LOAD. Eric

Notes
• Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted