Hi Joel,
I think there's a big problem when the docs use a vague term like "convert
to a string," since there are several ways that values may be converted to
strings.
As Andrew Martin noted, the cause of the strange behavior seen by JOIN is
INSERT's behavior (also seen with APPEND).
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.
>> to+form: func[v][print to string! :v print form :v]
>> to+form pi
3.14159265358979
3.14159265358979
>> to+form %file.ext
file.ext
file.ext
>> to+form to binary! "binary"
binary
#{62696E617279}
>> to+form first [abc/def/ghi]
abcdefghi
abc/def/ghi
>> to+form ["abc" "def" "ghi"]
abcdefghi
abc def ghi
These differences correspond exactly to the behavior of INSERT, APPEND and
JOIN:
>> append "" to binary! "binary"
== "binary"
>> append "" reduce [to binary! "binary"]
== "#{62696E617279}"
>> append "" first [abc/def/ghi]
== "abcdefghi"
>> append "" [abc/def/ghi]
== "abc/def/ghi"
>> append "" ["abc" "def" "ghi"]
== "abcdefghi"
>> append "" [["abc" "def" "ghi"]]
== "abc def ghi"
Eric
>Just a brief follow-up after checking the new docs...
>
>[EMAIL PROTECTED] wrote:
>>
>[...code samples snipped...]
>>
>> INSERT shouldn't use FORM when inserting a BINARY!. I'm sending
>> this to feedback too (I don't remember if I had already signaled
>> this to feedback...).
>>
>
>Page 7-3 (225 of 574) begins by saying
>
> This chapter will introduce functions that convert REBOL values
> into strings. These functions are used often ... They include:
>
>followed by Table 7-2, titled "String Conversion Functions". In
>that table join is described as "convert values with no spaces".
>
>Later on, page 7-4 (226 of 574) states:
>
> The join function takes two arguments and concatenates
> them into a single series.
>
> The data type of series returned is based on the value of the
> first argument. When the first argument is a series value,
> that series type is returned.
>
>and then proceeds to give examples of computing string! , file! ,
>and url! values via join invocations.
>
>The next page goes on to say:
>
> When the first argument is not a series, the join converts
> it to a string first, then performs the append.
>
>Finally the following page (7-6, 228 of 574) says
>
> When the second argument to join is a block, the values of
> that block are evaluated and appended to the series returned.
>
>This is not a smack-in-the-kisser blunt as I would like, but I
>think it means this (*WARNING* *MY NON-OFFICIAL READING*):
>
> Type of Type of Type of
> 1st arg 2nd arg result Treatment of args
> ----------- ----------- ----------- --------------------------
>1) any-string! not block! arg 1 type arg 2 value converted to
> string and appended to
> copy of arg 1 value
>
>2) any-string! any-block! arg 1 type arg 2 values converted to
> strings and appended to
> copy of arg 1 value
>
>3) not
> any-string! any string! join to-string arg1 arg2
> (now guaranteed to be one
> of the first two cases)
>
>If I'm correct, the behavior with a binary! first argument is
>actually the intended, documented behavior, as the binary! type
>is subsumed under the any-string! type.
>
>-jn-
>
>P.S. "I'm not a language lawyer, but I play one on the 'Net!" ;-)
>
> Isn't it fun having a spec?!?!
