Hello Joel (part 2),
Okay, now for a lot of picky little comments.
>>>> 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.
2.
>One of the most important pseudotypes in REBOL is "series",
>which comprises any datatype that can be understood as a sequence
>of values. The series pseudotype is subdivided into the
>"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
>> length? #{FF}
== 1
>> type? first #{FF}
== integer!
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.
3.
>The underlying sequence may also be modeled as a compound entity;
>it contains the actual data values and two additional attributes:
>an *** "end" position (last position in use), *** and an "allocation size"
>(last position which could be used without requiring additional
>memory management activity).
[snip]
>The REBOL documentation refers to *** "the end of a series" *** (e.g. in the
>description of 'tail). For this model, that phrase is viewed as
>verbal shorthand for "the end position of the sequence referrenced
>by the series". This is a reasonable abbreviation, as a series is
>refers to only one sequence, which has only one end position.
Should we say that the "end" position is the last position <<in use>>?
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
>> last a
== #"4"
>> last tail a
** Script Error: Out of range or past end.
** Where: last tail a
>>>> 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.
>>>> 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".
>>>> essay/4
5.
I think you probably chose to describe APPEND before INSERT because the
behavior of APPEND seems less complex. 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. Also, APPEND is as you know just a simple mezzanine function, a
shortcut for HEAD INSERT TAIL. I think it would be more useful in the long
term to tackle INSERT first, and then explain how APPEND modifies the
behavior of INSERT.
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. How about: "a block
value not directly bound to any word". Anonymity is really a non-issue in
REBOL. For example:
>> b: [1 2 3 [4 5 6] 7 8 9]
== [1 2 3 [4 5 6] 7 8 9]
>> a: fourth b
== [4 5 6]
Did the block value in the fourth position of the outer sequence suddenly
stop being anonymous when we bound it to 'a ? 'a of course is now bound to a
different (but identical) value instance. 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.
(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.)
>>>> essay/6
> a: [1 "st" 2 "nd"]
> b: a
[snip]
> c: copy a
>
>should *** duplicate the sequence *** referred to by a. Note that this
>sequence includes both *** "atomic" values (1 and 2) *** and series values
>(which refer to the two strings). Duplicating all of these (atomic
>values and references, but NOT the sequences) leaves
7.
I think it's misleading to say "duplicate the sequence". Try this:
>> a: [1 "st" 2 "nd"]
== [1 "st" 2 "nd"]
>> c: copy skip a 2
== [2 "nd"]
>> head a
== [1 "st" 2 "nd"]
>> head c
== [2 "nd"]
COPY doesn't duplicate a sequence; it constructs a new sequence from a series
value.
8.
By "atomic" values do you mean "scalar" values as discussed in the
documentation?
9.
I'm sorry I've spent so much effort on quibbling, and not enough on praising.
Not that you have any use for praise from the likes of me! Let me just say
that your series essay has been the first comprehensive discussion of REBOL
I've seen on this list with such consistent organization, and clarity of
presentation. I only wish my responses above could rise to the same level!
Take care,
Eric
