[EMAIL PROTECTED] wrote:
>
> Hello Joel (part 2),
>
> Okay, now for a lot of picky little comments.
>
That's OK... I have good tweezers, too! ;-)
>
> >>>> essay/1
>
> 1.
>
> >This model uses the non-REBOL term "entity" to refer to a specific
> >data structure that represents a particular REBOL value. This was
>
> I understand your use of the term entity to include all REBOL values.
> I'm not sure if there's any advantage to using "entity" instead of just
> "value". To me that is a distinction that could be relegated to a
> discussion of the implementation of REBOL.
>
> I'm wondering if you mean by "entity" an instance of a value that exists
> somewhere in memory? I think that is an important distinction, but I
> prefer "instance" for this meaning.
>
I do intend for "entity" to refer to a specific data structure in memory
that represents a value. I deliberately chose not to use the term
"instance" (although I've actually used that term conversationally)
because it implies some other things to folks with an OO background.
To go further, I tried to use a somewhat unusual word to call attention
to the fact that this is not standard REBOL terminology.
> 2.
>
...
> >"any-string" and "any-block" pseudotypes; the first for any value
> >that can be understood as *** a sequence of characters *** (such as
> >"string") and the second for sequences of REBOL values of any type.
>
> This is a really minor error, and one that I made in an early response to
> (I think) your first post on series. There's just one exception I know of:
>
> >> type? #{FF}
> == binary!
> >> any-string? #{FF}
> == true
...
>
> Each element of binary! values has only a character's worth of data, but
> they're typed as integers. The basic idea of any-string! values is, of course
> unaffected.
>
You've got a point. I think I'd rather deal with that exception AS
an exception, rather than reword to "understood as a sequence of 8-bit
integers that are most frequently interpreted as characters" or some
such awful phraseology. I'm open to suggestion.
> 3.
>
...
>
> Does a zero-length string sequence have a position in use? My preference
> would be to say not. But of course it has an end position. I would prefer
> to describe the end position as the one <<following>> the last position
> in use, or (better) as the position following the last element of the
> sequence. That would make the following easier to understand:
>
> >> a: "1234"
> == "1234"
> >> length? a
> == 4
> >> index? tail a
> == 5
Good suggestion. Maybe it would be even better just to go ahead and
call
it the "tail position", defined similar to one of your wordings above.
That would certainly simplify the description of 'tail and 'tail? even
further (assuming I get around to including them at some point).
>
> >>>> essay/2
>
> 4.
>
> >A word (variable) can be "set" to any REBOL value. This simply
> >means that the word *** is associated with *** the value in a way that
> >allows it to be retrieved as needed. The effect of evaluating
> >the REBOL expression:
>
> The concept of binding is so fundamental to REBOL, and the way REBOL is
> described, that it really should be introduced right here.
>
My only excuse is that the essay was on the REBOL series, and not on
the whole language, as discussed under my FOCUS goal in the previous
email. But, you're right. Binding is fundamentally important, and is
high on my list of things to make sure I can explain.
>
> >>>> essay/3
>
> >The 'next function produces a series entity referrings to the same
> >sequence as the argument series, with the index increased by one
> >(unless the index is already *** past the end of the sequence ***, in which
> >case the result's index is the same as the argument's index.)
>
> Your wording here seems to suggest that you can have an index to some
> arbitrary position past the end of a sequence. I would prefer "at the end of
> the sequence" or "at the tail of the sequence".
>
That's a good suggestion (especially in view of the earlier one about
better language for "end of sequence"). Thanks!
> >>>> essay/4
>
> 5.
>
> I think you probably chose to describe APPEND before INSERT because the
> behavior of APPEND seems less complex.
>
Exactly right.
>
> Unfortunately for the learning curve (but fortunately, I believe, for
> programming convenience), the behavior of INSERT is much more typical
> of the built-in functions that manipulate sequences.
>
If I had been trying to write an introduction to the whole language,
there are several things I would have done in a different order. As
it was, I wanted to include "just enough" about side-effect-producing
functions to show how they fit into the model. So, I made a conscious
decision to let that issue drive the presentation.
>
> 6.
>
> >The last position is now occupied by an *** anonymous block *** with
> >an index of 2.
>
> For me, the word anonymous is so strongly associated with Perl in this
> sort of usage, that I would prefer to avoid it altogether.
>
Hmmm. It never occurred to me that I would be invoking something "off
the
Wall"... groan...
Actually, I've used the term "anonymous" for years, with more of a
LISP-ish than Perl-ish connotation in my own mind. E.g., I would say
that the following interaction defines and immediately invokes an
anonymous function:
>> do func [a][a + a + 1] 4
== 9
>
> Anonymity is really a non-issue in REBOL. For example:
> ... So, if we're going to talk about
> anonymous blocks, we might as well talk about anonymous integers as
> well, or any other value that can be contained within a sequence.
>
Actually, I used the term precisely because I believe it to be a non-
issue (odd as that may seem). I just wanted to re-emphasize that REBOL
data types are first-class, and don't have to be referred to by a
"variable" to have all of their attributes and behaviors. The reason
we don't talk about anonymous integers is that we already are used to
thinking of them as existing independently, so it doesn't require
any emphasis to do so.
>
> (I kind of get the feeling that you may be mixing up "block as sequence" and
> "block as series" - perhaps you're relying too much on the sequence/series
> terminology, which doesn't provide an automatic way of disambiguating all the
> series types.)
>
I don't think so. See above. Maybe my use of the word just didn't
carry the implication I was hoping for.
>
> >>>> essay/6
>
> > a: [1 "st" 2 "nd"]
> > b: a
> [snip]
> > c: copy a
> >
> >should *** duplicate the sequence *** referred to by a.
...
>
> 7.
>
> I think it's misleading to say "duplicate the sequence". Try this:
...
> COPY doesn't duplicate a sequence; it constructs a new sequence
> from a series value.
>
Good point. I need to re-word.
>
> 8.
>
> By "atomic" values do you mean "scalar" values as discussed in the
> documentation?
>
I've been wrestling with that one for quite a while, actually. So
let me say something complicated to duck the issue ;-). I borrowed
the term "atomic" from other languages, and used it just to imply
that the value is simple enough that we don't worry about internal
structure or references when talking about it.
I'm used to the idea of integer and floating-point numbers, boolean
(logic) values, and characters falling into this category. However,
'date!, 'time!, and 'money! are described as being composite values:
>> a: make date! [24 12 1999]
== 24-Dec-1999
>> a/1
== 1999
>> a/2
== 12
>> a/3
== 24
>> a/4
== none
>> first a
== 1999
>> a/year
== 1999
so I suspect that the REBOL term "scalar" DOESN'T mean quite the
same thing. At the moment, it's just a hand-waving excuse for
drawing
{{block! 1 *}}
|
V
<< 1 * 2 *>>
| |
V V
{{string! 1 *}} {{string! 1 *}}
| |
V V
<<#"s" #"t">> <<#"n" #"d">>
instead of
{{block! 1 *}}
|
V
<< * * * *>>
| | | |
V | V |
1 | 2 |
V V
{{string! 1 *}} {{string! 1 *}}
| |
V V
<<#"s" #"t">> <<#"n" #"d">>
>
> 9.
>
> I'm sorry I've spent so much effort on quibbling...
>
The fact that you waded through several hundred lines of dense
prose and ASCII art (and then took the trouble to respond so
quickly and clearly) is so flattering that I didn't notice a
single quibble! I assure you that your kind compliments,
suggestions, and pointed questions are all equally welcome.
Thank you very much!
Happy holidays!
-jn-
