Bug! - 'second on object containing ONE hash! has TWO hash! !!
[1/6] from: al::bri::xtra::co::nz at: 5-Oct-2000 19:40
Bug! - 'second on object containing ONE hash! has TWO hash! !!
REBOL/View 0.10.35.3.1 30-Sep-2000
Copyright 2000 REBOL Technologies. All rights reserved.
>> 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 ?
It even does a similar thing in old Rebol/Core:
REBOL 2.2.0.3.1
Copyright (C) 1998-1999 REBOL Technologies
REBOL is a Trademark of REBOL Technologies
All rights reserved.
Finger protocol loaded
Whois protocol loaded
Daytime protocol loaded
SMTP protocol loaded
POP protocol loaded
HTTP protocol loaded
FTP protocol loaded
NNTP protocol loaded
Script: "REBOL Extended Definitions" (3-Sep-1999/17:55:08)
Script: "User Preferences" (26-Jan-2000)
>> 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