Hi Elan,
I think you've got us all mystified. You said to Joel:
>You also quote excerpts that demonstrate the use of the verb "to refer" in
>a context where something is being referred to. This class of quotes does
>not make any statement about WHAT IS DOING the referring. What use are
>quotes that demonstrate that values can be referred to, even though they
>are not words? I never claimed that values being referred to must be words.
>I said that only words are references, and only words can be dereferenced:
>>> help get
>Gets the value of a word.
>Arguments:
> word -- Word to get (any-word)
>Refinements:
> /any -- Allows any type of value, even unset.
I can't for the life of me see how the help for GET says anything about the
technical meaning of the word of the term "refer" or "reference", given that
the word isn't used at all. Then when you go on to prove that string values
cannot refer by showing that strings cannot be used as an argument to GET,
my confusion is compounded many-fold. Where does it say that only words can
be dereferenced? I haven't even seen the term "dereference" in the
documentation.
Maybe this will help me understand what you're thinking. How do you explain
what happens here?
>> string: "abcdefghij"
== "abcdefghij"
>> b: [] loop 5 [append b string string: next string]
== "fghij"
>> b
== ["abcdefghij" "bcdefghij" "cdefghij" "defghij" "efghij"]
>> unset 'string
>> remove first b
== "bcdefghij"
>> b
== ["bcdefghij" "cdefghij" "defghij" "efghij" "fghij"]
Here's an interesting use of the term "reference" from the
User's Guide 2.2.0 [DRAFT 2] (sersearch.html)
Search Constraints
The /part refinement takes one argument, a range to search.
This can be a numeric range, or series. When a series is
used, find/part uses the count of elements between the
current index of the search series and the current index of
the series argument as the range to constrain to. The
series used as the range argument must reference the same
series that's being searched.
You'll see that a "series" is said to reference a "series" - not terribly
clear wording, but given that they haven't had time to fully consider Joel's
proposals I'd say it's a forgivable lapse.
The behavior described here may be illustrated as follows:
>> a: "this is a string to be searched"
== "this is a string to be searched"
>> find a "string"
== "string to be searched"
>> find a "search"
== "searched"
>> find/part a "string" find a "search"
== "string to be searched"
>> find/part a "search" find a "string"
== none
In the final statement here,
find a "string"
returns a reference to A which constrains the find/part to a portion of A
which doesn't include the substring "search"
Here's another example, from sercopy.html:
Copying Embedded Series With the /deep Refinement
The /deep refinement forces copy to copy all series values
within a block.
When copying series values in a block, the reference to the
series is copied, not the series itself. Modifications to
series in a copied block will modify the series in the copy.
It implies quite clearly that references can exist within a block.
BTW, you may have spotted Joel's solution to my puzzle, which I confess is a
silly variation of one of Ladislav's puzzles.
See you,
Eric
