Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Problem with try [ open/direct/binary tcp://... ] Re:(2)

From: rebol:techscribe at: 4-Oct-2000 2:00

Hi Eric, you point out that INSERT (and APPEND and JOIN) appear to use FORM to convert values contained in blocks, whereas they use TO STRING! to convert values which are not contained in blocks. If you observe how TO STRING! processes values contained in blocks, you will find that TO STRING! itself acts no different from FORM with respect to blocks. If the functions you inspect use nothing but TO STRING! to convert values (string! or block! values), then the results will be exactly the ones you observed. Some of your results are unexpected because REBOL does not use a symmetrical conversion model. The question is, is that good? [KGD03011--nifty--ne--jp] wrote:
> It seems that INSERT uses FORM to convert values contained in blocks before > inserting them, and TO STRING! to convert values which aren't contained in > blocks. Most of the time the results of TO STRING! and FORM are the same, but > there are several differences. >
[snipped examples displaying similarities and differences between FORM and TO STRING!]
> These differences correspond exactly to the behavior of INSERT, APPEND and > JOIN: > > >> append "" to binary! "binary" > == "binary" >> to string! to binary! "binary"
== "binary"
> >> append "" reduce [to binary! "binary"] > == "#{62696E617279}"
Here you conclude that REBOL appears to be using FORM instead of TO STRING!, because a block is being converted. However, TO STRING! does the exact same thing:
>> to string! reduce [to binary! "binary"]
== "#{62696E617279}"
> >> append "" first [abc/def/ghi] > == "abcdefghi" >> to string! first [abc/def/ghi]
== "abcdefghi"
> >> append "" [abc/def/ghi] > == "abc/def/ghi"
Again you note the similarity to using FORM. However, TO STRING! acts no different:
>> to string! [abc/def/ghi]
== "abc/def/ghi"
> >> append "" ["abc" "def" "ghi"] > == "abcdefghi" >> to string! ["abc" "def" "ghi"]
== "abcdefghi"
> >> append "" [["abc" "def" "ghi"]] > == "abc def ghi" >> to string! [["abc" "def" "ghi"]]
== "abc def ghi" In all cases TO STRING! behaves as FORM would with respect to blocks. Nevertheless the results are surprising in some instances. That is because one would expect that REBOL uses a SYMMETRICAL CONVERSION model, which it doesn't. What I mean is: A SYMMETRICAL CONVERSION MODEL in REBOL would look something like this: 1. In REBOL data always occurs in association with a datatype. The combination of data with a datatype is a value. 2. CONVERSION means disassociating some data from its current datatype and associating it with a different datatype, while leaving the data unmodified. Its value representation changes because it is now associated with a different datatype. 3. CONVERSION INTEGRITY means that converting a value to a different datatype and back to the original datatype must result in the same value it originally had. The reason is that the data was not modified during the conversion. REBOL does not follow this symmetrical conversion model. REBOL's conversion does not maintain CONVERSION INTEGRITY. REBOL's CONVERSION implementation is not always symmetrical. This means that in some instances REBOL does not limit itself to modifying the datatype associated with the data that is being converted, instead, the data itself is modified as well. Some of the examples you show show REBOL supporting symmetrical conversion. For instance
>> binary-block: reduce [to binary! "binary"]
== [#{62696E617279}]
>> to string! binary-block
#{62696E617279} and
>> to block! to string! binary-block
== [#{62696E617279}] The final result of converting the string representation of the data contained in the block binary-block is a block containing the same data. That is appropriate. 5. I think it is reasonable to expect that REBOL's conversion routines maintain CONVERSION INTEGRITY. Unfortunately that is not true. Examples:
>> to string! ["abc" "def" "ghi"]
SHOULD RETURN ~~ {"abc" "def" "ghi"} INSTEAD IT RETURNS == "abc def ghi" Therefore
>> to block! to string! ["abc" "def" "ghi"]
results in == [abc def ghi] i.e. a block of words, whereas CONVERSION INTEGRITY would require it to return == ["abc" "def" "ghi"] a block containing strings, which was what the original block contained. Another example is
>> to block! to string! [["abc" "def" "ghi"]]
which returns == [abc def ghi] Under a symmetrical model this should result in == [["abc" "def" "ghi"]] What happens is that during the string conversion [["abc" "def" "ghi"]] was converted to "abc def ghi", whereas following a symmetrical model it should have been converted to {["abc" "def" "ghi"]}. Only the outer block should have been replaced by a string. Instead the element of the outer block (a block containing three strings) was stripped, and in addition the three strings contained in the block were converted to character sequences. Additional space characters were inserted, separating the character sequences that were originally strings. Is REBOL's current implementation of ASYMMETRICAL CONVERSION, i.e. a conversion that permits the modification of the data and does not limit itself to modifying the representation of the data by associating the data with a different datatype, more useful - albeit occasionally surprising - than a symmetrical conversion would be?