Thanks, Larry! I'll check it out!
-jn-
[EMAIL PROTECTED] wrote:
>
> Hi Joel
>
> The version I have is a free package from U-Wisconsin called Xlisp-Stat. It
> is a modified version of Xlisp with fast statistics, graphing functions, and
> direct calls to LinPack code. It was written by Luke T
.
Larry
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 30, 1999 6:27 AM
Subject: [REBOL] "logical" value referencing ... Re:(15)
> [EMAIL PROTECTED] wrote:
> >
> > Scheme or XLisp typical modern Li
[EMAIL PROTECTED] wrote:
>
> Scheme or XLisp typical modern Lisp dialects, share many features with
> REBOL, good book SICP
>
On the subject of XLisp in particular: The last time I looked, the
most recent version of XLisp I could find on the Net was a few years
old. It appeared that David
On 12/30/1999 at 12:31 AM [EMAIL PROTECTED] wrote:
{{
value reference: The relationship between a word and the value it
references.
series reference: The relationship between a series value and its
underlying data.
}}
Isn't a "series reference" just a
On 12/29/1999 at 1:55 PM [EMAIL PROTECTED] wrote:
{{
Any suggestions for other candidate languages, Ted (or anybody)?
}}
In terms of a worker's language, and all things remaining equal, I'd
start with Javascript, since this will be a necessary complement to
serious Web work with REBOL for some ti
Subject: [REBOL] "logical" value referencing ... Re:(13)
> [EMAIL PROTECTED] wrote:
> >
> > Also, in the orignal Essay, there was mention of using the
> > model/diagram to compare REBOL and other languages on a common ground.
> > If that is still a goal, I would sugges
[EMAIL PROTECTED] wrote:
>
> You are certainly correct in pointing out that pointers and indexes can be
> converted into each other. But you do have to be careful:
>
> I am sure you agree with me that if i is an index into a buffer,
>
> int i; char buf[10], *p;
>
> then trying to access the el
[EMAIL PROTECTED] wrote:
>
> Also, in the orignal Essay, there was mention of using the
> model/diagram to compare REBOL and other languages on a common ground.
> If that is still a goal, I would suggest that another language be
> brought into the model/diagram sooner than later, to be sure it is
Hi Elan,
>From one of your latest posts, I've concluded that our differences on what is
and isn't reference are quite minor, after all (except for my woeful lack of
background). I agree on the overall framework you proposed under the terms
"explicit reference" and "automatice reference". I was t
On 12/28/1999 at 11:40 PM [EMAIL PROTECTED] wrote:
{{
I am concerned with understanding, and being able to describe and
predict, the behavior of REBOL expressions using concepts and terms
that are common in the field of computer programming
}}
Personally, I liked your original suggestion of an a
Hi Joel,
You are certainly correct in pointing out that pointers and indexes can be
converted into each other. But you do have to be careful:
I am sure you agree with me that if i is an index into a buffer,
int i; char buf[10], *p;
then trying to access the element at buf[i] is quite somethi
[EMAIL PROTECTED] wrote:
>
> We are concerned with a terminology that is designed to
> conceptualize the REBOL programming language...
>
No.
I am concerned with understanding, and being able to describe and
predict, the behavior of REBOL expressions using concepts and terms
that are common in
[EMAIL PROTECTED] wrote:
>
> In C pointers and indexes are different ways
> >to get at, peek into, observe, manipulate, or eavesdrop on, the
> Nevertheless it would not be a good idea for a C programmer to
> confuse an index with a pointer, nor would it be advisable for
> someone, who wants to pr
Hi Eric,
I have a moment, so here is another piece of the puzzle.
You wrote:
> 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 ha
Hi Eric,
you appear baffled by my use of the term "dereference". I hope the
following quote will help.
Note the sentence:
"Is it important to clear large blocks of data before
DEREFERENCING them?"
> Quote Begins Here <<
From: [EMAIL PROTECTED]
Hi B
Hi,
sorry for disagreeing with you:
not silly.
Ladislav
>
> 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 m
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
At 06:14 PM 12/27/99 -0600, you wrote:
>[EMAIL PROTECTED] wrote:
>>
>> Reference in REBOL has a specific meaning. It describes a process that
>> occurs when a set-word! type value is evaluated.
>>
>
>Words certainly can refer to values.
>However, that's not the only
>way the concept of "refere
[EMAIL PROTECTED] wrote:
>
> Hi Elan,
>
> (I think Joel may have used the phrase "the empty string" as a
> concept rather than meaning "the unique empty string in the
> example".)
>
That's a completely reasonable interpretation of what I wrote. I
actually meant to say "an empty string", which
[EMAIL PROTECTED] wrote:
>
> >1) At translation time the text which begins with (sans formatting)
> >
> >[a: "" b: copy "" ;...etc...
> >
> >is translated into a block.
> >The second element of that block is
> >initialized to refer to the empty string, as is the fifth elemen
[EMAIL PROTECTED] wrote:
>
> Reference in REBOL has a specific meaning. It describes a process that
> occurs when a set-word! type value is evaluated.
>
Words certainly can refer to values. However, that's not the only
way the concept of "reference" is used in the REBOL documentation
available
Hi Joel,
we appear to agree on the role of load in the translation process. Glad to
see that the translation process itself is now public knowledge. Looking
forward to more comments.
Elan
Hi Eric,
you have a problem with the fact that REBOL's visual representation of
values in the REBOL console is ambiguous. I had a long exchange about that
with Ladislav. We were able to sort out things at the time.
In the message you comment on, I am NOT talking about how REBOL displays a
litera
[EMAIL PROTECTED] wrote:
>
> Throughout my explanations I try to remain true to the terminology
> introduced in the final release of the User's Guide (not the beta
> manual), the REBOL Dictionary and REBOL itself. Jeff like to point
> out that REBOL is its own meta-language.
>
The good folks a
Hi Elan,
I've read your 1400+ line refutation of Joel's explanation of a function. I
agree with much of what you say, but there is one point I don't think is
quite right:
>2.3 Conclusion:
>2.3.1 An empty literal string does not reference "the empty string" because
>a string! value does not have
Hi Joel,
this response was written on Thursday last week. At the time the message I
am responding to was your latest message to the list. Since then you have
sent a few other messages.
Text begins here ===>
R Stands For Relative!
I decided to review your messages bottom up (the latest mes
[EMAIL PROTECTED] wrote:
>
> Very cool! I'm going to spend some quality time reviewing your response and
> get back to you on that on Monday.
>
I'm looking forward to your thoughts.
>
> For now, have a happy, restful and peaceful holiday. And everyone else as
> well.
>
The same to you!
-jn-
ur mind
>
> str: ""
>
> is self-modifying, whereas
>
> if not value? str [str: copy ""]
>
> isn't?
>
> Elan
>
> >
> >Hi, Russell,
> >
> >only one change and you have got a non-SMC, which is preferrable
> >
>
Hi Joel,
you quoted me:
>> The line in which 'b was created wasn't changed. Most dramatically, it
>> continues to be the exact same line you commented on as
>>
>> >the creation of B
>> >is "dynamic" as opposed to A, where the creation is "static"
>>
> ...
>> Let me see an explanation that main
[EMAIL PROTECTED] wrote:
>
> Hi Ladislav,
>
> you wrote:
...
> >
> >Let's get to the above example, but let's use a little bit different code:
> >
> >f: func [/local a b] [ a: "" b: copy "" for i 1 6 1 [append a i append b i]
> >print a print b]
> >>> f
> >123456
> >123456
> >>> f
> >123456123
[EMAIL PROTECTED] wrote:
>
> Hi Ladislav,
>
> you wrote:
...
> >
> >Let's get to the above example, but let's use a little bit different code:
> >
> >f: func [/local a b] [ a: "" b: copy "" for i 1 6 1 [append a i append b i]
> >print a print b]
> >>> f
> >123456
> >123456
> >>> f
> >123456123
[EMAIL PROTECTED] wrote:
>
> Ex2:
> a: [""]
> b: copy a
> change/only a "x"
> a
> b
>
> >> a: [""]
> == [""]
> >> b: copy a
> == [""]
> >> change/only a "x"
> == []
> >> a
> == ["x"]
> >> b
> == [""]
> You see, that by changing A we didn't change it's copy B.
>
> Ex3:
> a: [""]
> b: copy a
> in
[EMAIL PROTECTED] wrote:
>
> can't resist to show you a few examples of Rebol code (just for fun, don't
> be afraid).
>
> Ex1:
>
> f: func [/local a][
> do func [] [
> a: ""
> ]
> insert a "1"
> ]
>
> Results:
> >> f
> == ""
> >> f
> == ""
>
> interesting, isn't it?
>
Inv
Short summary:
1) Series literals are just initializers. Once you set something to
refer to them, they are subject to modification.
2) Applying 'reduce to a string returns the same string.
3) Applying 'reduce to a block returns a different block.
[EMAIL PROTECTED] wrote:
>
...
> I dis
my engineers' software,
a statement that "It works" was a danger signal. I much preferred "It works
the way anyone reading the code would expect."
Russell [EMAIL PROTECTED]
- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursda
quot;
>> >> f
>> == "111"
>> >> b
>> == "111"
>> >> source f
>> f: func [/local a][a: b insert a "1" b]
>> >>
>> I started by defining a global variable, 'b, referencing a null string.
>> In
that...).
your's Ladislav
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 22, 1999 9:00 PM
Subject: [REBOL] "logical" value referencing ... Re:(9)
> Hi Ladislav,
,0>
> At 04:01 AM 12/22/99 -0800, I w
ot;1"
>> f
== "11"
>> f
== "111"
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 23, 1999 1:37 AM
Subject: [REBOL] "logical" value referencing ... Re:(10)
> Hi Elan. This is not
but note that the source for
'f has not been changed.
Somehow, this makes me a lot more comfortable about the results with
f: func[/local a][a: "" insert a "1" a]
in which case repeated executions change the "" to "1" "11" etc.
Russell [EMAIL
Hi Ladislav,
At 04:01 AM 12/22/99 -0800, I wrote. And I should have been in bed fast
asleep. Sorry for taking up so much unnecessary bandwidth. My imagination
was running wild.
Two points I'd like to make:
in 1. I comment on the unlikelyhood of there being a "return context".
in 2. I provide a
At 11:37 PM 12/21/99 +0100, you wrote:
>Hi, I had a problem to find your post and respond to it (sorry).
Tell me which one you couldn't find and I'll be happy to email you a copy
off list.
>
>just want to point out some errors made by you:
>
>1) In Rebol A and B don't mean the same as you sugges
Hi, I had a problem to find your post and respond to it (sorry).
just want to point out some errors made by you:
1) In Rebol A and B don't mean the same as you suggest: 'a and 'b, which is
misleading.
2) You are inferring: "In REBOL it is a property of literal strings that
they are global and
t
Ted>> It's important to note that a series returns its current position
as a ~copy~ of the index value, but the rest of the series is returned
as a reference. This behaviour is designed so that you can easily
create two indexes into the same series.
To followup my own post, I should add that if y
joel.neely@fedex>> clear b
The problem with CLEAR has been classified as a bug, and is being
handled under ticket #1593. I'm told the REBOL language fully supports,
and even encourages, multiple references to the same series, but the
REBOL interpreter needs to be fixed.
>> My reading of the dict
Hi Ladislav,
you wrote:
>can't resist to show you a few examples of Rebol code (just for fun, don't
>be afraid).
Ladislav, can't resist to show you a few comments I have regarding your
examples of REBOL code (just for fun, don't be afraid).
>Ex1:
>
>f: func [/local a][
>do func [] [
>
Hi Ladislav,
a note: the way you commentend on the last few messages makes it very
difficult (for me, maybe others) to identify what is part of the original
email being commented on and what is your comment (see below). It's also
difficult to detect where your comments begin.
It would make it m
Hi Ladislav,
you wrote:
>
>I think that the effort to find an adequate terminology is quite reasonable.
Absolutely.
>It can't be considered as the opposite of being simple.
Certainly, searching for an adequate terminology is not the opposite of
being simple. The search can result in a simple
[EMAIL PROTECTED] wrote:
> Ahoj, Petre, hezke vanoce (Hi, Peter, Merry Christmas)
Ooo, diky, totez preju Tobe :-)
> can't resist to show you a few examples of Rebol code (just for fun, don't
> be afraid).
>
> Ex1:
>
> f: func [/local a][
> do func [] [
> a: ""
> ]
> insert
[EMAIL PROTECTED] wrote:
>
> 2. With respect to the example above:
> a: "1234"
> b: next a
>
> you often refer to 'b as a "series referencing the shared or sharable data
> storage". This is incorrect for two reasons.
>
> 1. It is incorrect because 'b is a word...
> Whenever REBOL evaluates 'b, i
[EMAIL PROTECTED] wrote:
>
> If I'm not mistaken, the whole point of your approach in this email series
> ;-) is that you are trying to be able to formulate that in
>
> a: "1234"
> b: next a
> c: next b
>
> a, b and c reference the same series at different positions. You would like
> to invent
Ahoj, Petre, hezke vanoce (Hi, Peter, Merry Christmas)
can't resist to show you a few examples of Rebol code (just for fun, don't
be afraid).
Ex1:
f: func [/local a][
do func [] [
a: ""
]
insert a "1"
]
Results:
>> f
== ""
>> f
== ""
interesting, isn't it?
Ex2:
a: [""]
b:
[EMAIL PROTECTED] wrote:
> Let's consider now another version of the Mystery Function that has
> been discussed in this thread.
>
> >> container: ["" "x"]
> == ["" "x"]
>
> This word just holds a block of data. The first element of the block
> is a reference to an empty string; the se
[EMAIL PROTECTED] wrote:
>
...
>
> Therefore my feeling is that the problem you formulate in order to
> propose a solution is one you just happily constructed.
>
The problem I observed (not formulated) was the amount of discussion,
and apparent confusion, over the behavior of REBOL in cases su
[EMAIL PROTECTED] wrote:
>
> I find it much easier to understand to call
> "123456" - the series, and
> 'a / 'b - indexes into the series
>
> To me this seems to show better the difference between actions on
> the index ('next, ...) and on the series (insert, ...)
>
A small qualm I have there
Sorry to take so long in replying...
[EMAIL PROTECTED] wrote:
>
> I believe that in essence we differ on whether the two example functions,
> next and insert (and with them all other series related functions), can be
> fully, and can only be explained by reviewing how they apply to your case
> i
[EMAIL PROTECTED] wrote:
>
> On 12/16/1999 at 12:17 AM [EMAIL PROTECTED] wrote:
> [...]
> > On the other hand, I prefer to keep the vocabulary needed to
> > describe REBOL to a minimum. I also like to exploit the similarity
> > of principles, to keep the volume of information needed to reason
>
Merry Christmas and Happy New Millenium to you, Russell,
You discovered a rather special property of REDUCE:
a: ""
same? a reduce a
insert reduce a "1"
print a
Results:
>> a: ""
== ""
>> same? a reduce a
== true
>> insert reduce a "1"
== ""
>> print a
1
a: []
same? a reduce a
insert reduce a "
Hi Ladislav
Russell [EMAIL PROTECTED]
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 17, 1999 4:32 PM
Subject: [REBOL] "logical" value referencing ... Re:(9)
> Hi, Russell, you wrote:
>
> But I must admit
[EMAIL PROTECTED] wrote:
>
> Hi Elan.
> > Hi Russell,
> > The function:
> > >> f: func [/local a] [a: "" insert a 1 a]
...
>
> But I must admit I'm "flabbergasted" at how the function 'f as defined
> immediately above, works on repeated
> applications...
>
> It appears that the interpreter is m
[EMAIL PROTECTED] wrote:
>
> Hi Joel,
>
> I see that (so far) you chose to ignore my invitation in a previous
> message, to comment on whether the logic of my argument is acceptable
> to you. My question was addressed personally to you and not
> anonymously to the list.
>
> I conclude that sinc
On 12/17/1999 at 1:04 PM Elan <[EMAIL PROTECTED]> wrote:
> Much ado about nothing? Perhaps.
Much ado, but * not * about nothing.
One of the striking things about REBOL is that it moves from the
general to the specific, where other languages, I think, may move from
the specific to the general.
Hi, Elan.
You said:
[Offending part deleted...]
I think that your terminology introduces grave mistakes in reflecting on
how REBOL behaves and constitutes a source for confusion.
If I'm not mistaken, the whole point of your approach in this email series
;-) is that you are trying to be able to
Hi, Russell, you wrote:
But I must admit I'm "flabbergasted" at how the function 'f as defined
immediately above, works on repeated
applications. You proposed some ingenious "debugging" approaches, but I
discovered another. Look at this
console stuff:
>> f: func [/local a] [a: "" insert a 1 a]
Hi Joel,
I see that (so far) you chose to ignore my invitation in a previous
message, to comment on whether the logic of my argument is acceptable to
you. My question was addressed personally to you and not anonymously to the
list.
I conclude that since you have otherwise demonstrated a friendl
Hi Petr,
>hmm, it has a value ... so, if "" and [] are not considered being
datatypes, it
>is very strange, and as comparison to other languages I know (well, very few
>:-), pretty uncommon, that we assign some word to the value, rather than
value
>to the word
I'm not quite sure I understoo
Hi Elan.
Russell [EMAIL PROTECTED]
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 16, 1999 11:18 PM
Subject: [REBOL] "logical" value referencing ... Re:(7)
> Hi Russell,
>
> You translated the repeated
THANK YOU! I wish I could have said it so well (and succinctly!)
-jn-
[EMAIL PROTECTED] wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > both 'a and 'b refer to the same string, but to different positions
> within that string? Isn't it valid to say that 'a and 'b are not the
> same series, but that
Hi, Rebols,
allow me to correct myself. SUBSERIES? should preferrably be:
; Find out if A is a sub-series of B
subseries?: func [a [series!] b [series!]] [
(same-headed? a b) and ((index? a) >= (index? b))
]
Now some statements:
1. There are some functions in Rebol like CHANGE, APPEND, IN
[EMAIL PROTECTED] wrote:
> Hi, Rebols,
>
> proposing a terminology. Example:
>
> a: [1 2 3]
> b: tail a
> c: [1 2 3]
> d: []
>
> Everybody knows that there are differences between relations A <=> B and
> C<=>D.
> What about using the notion SAME-HEADED like this:
>
> same-headed?: func [a [seri
[EMAIL PROTECTED] wrote:
> When you look at the function's code, you may think that the instructions
> above are incorrect. Isn't 'a assigned as a reference to an emtpy string
> each time the function is evaluated? No. A literal string is global and
> therefore the originally empty literal stri
Hi, Rebols,
proposing a terminology. Example:
a: [1 2 3]
b: tail a
c: [1 2 3]
d: []
Everybody knows that there are differences between relations A <=> B and
C<=>D.
What about using the notion SAME-HEADED like this:
same-headed?: func [a [series!] b [series!]] [
same? head a head b
]
Examp
Hi Eric,
you wrote interesting stuff:
>
>If you ask REBOL, any-string! is a datatype! value.
>
>>> datatype? any-type!
>== true
This works better (for this particular example ;-):
>> datatype? any-string!
== true
That's the problem. type? any-string! indeed returns datatype! However,
any-string!
Hi Russell,
You translated the repeated evaluation of the function into repeated
assignments of a word as a reference to an empty string.
The function:
>> f: func [/local a] [a: "" insert a 1 a]
>> f
== "1"
>> f
== "11"
>> f
== "111"
does not translate the way you did. When the expression
inser
Hi Elan,
Those were the words of [EMAIL PROTECTED]:
> Hi Ingo,
>
> without wanting to sway opinions one way or the other. You wrote:
>
> >Thus insert? / tail? would work on the series at the variables index,
> >empty? / append would work on the series at a whole. That seems consistent
> >to me,
Hi Joel
Those were the words of [EMAIL PROTECTED]:
<...>
> For clarity of communication, and ease of learning by newcomers,
> I'm simply proposing that:
>
> A) each language concept should have one unique name/term
>(although explanations and tutorials obviously will use a
> variety of
Hi Joel,
you wrote:
>
>a: next "123456"
>b: next next a
>
>I suggest that there are three entities of interest:
>
>i) one which we get at via the variable 'a
>ii) one which we get at via the variable 'b
>iii) one which we can't get (directly) but which corresponds to a
> copy of th
[EMAIL PROTECTED] wrote:
> both 'a and 'b refer to the same string, but to different positions
within that string? Isn't it valid to say that 'a and 'b are not the
same series, but that each is a series referring to the same string (or
whatever we want to call the data storage in this example)?
See below:
Russell [EMAIL PROTECTED]
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 16, 1999 6:17 AM
Subject: [REBOL] "logical" value referencing ... Re:(5)
> On 12/16/1999 at 12:17 AM [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
>
> Based on the above, we can say that
> 1. A series IS a data storage into which we may insert data.
> 2. A series HAS a current position at which the data storage
>is accessed
>
In THEORY, a series is a data storage and a "current position"
within that storage.
I
Another fragment in the continuing dialogue.
[EMAIL PROTECTED] wrote:
>
> My problem with what you are doing here is not so much where you are
> heading. It is the reason you give for heading there. You see, you
> formulate two different things,
>
> 1. inserting a value into a series and
> 2. r
Elan raised several interesting points. To minimize message size,
I'll split up my part of the conversation.
[EMAIL PROTECTED] wrote:
>
> ...
> Sure you can use make on datatype! values. It's just any-string! is
> not a datatype! value.
>
The interpreter thinks that it is.
>> help dataty
Elan writes:
>Regarding the any-string! problem: REBOL's error message is incorrect,
>since make does support datatypes. Any-type! should not be categorized by
>type? as being of type datatype! (which is the reason for the erroneous
>error message):
>
>>> type? string!
>== datatype!
>>> s: make
On 12/16/1999 at 12:17 AM [EMAIL PROTECTED] wrote:
[...]
> On the other hand, I prefer to keep the vocabulary needed to describe
> REBOL
> to a minimum. I also like to exploit the similarity of principles, to
> keep
> the volume of information needed to reason about REBOL to a minimum. If
> we
>
So, to reflect conceptually,
" ... the block exists on its own, and [the variable] simply refers to
[a position] of the block."
And as Elan pointed out, a series (which is also a block) can be
represented, for discussion purposes, like this:
series: use [current-position] [
current-positio
Hi Ingo,
without wanting to sway opinions one way or the other. You wrote:
>Thus insert? / tail? would work on the series at the variables index,
>empty? / append would work on the series at a whole. That seems consistent
>to me, not to words, that seem to mean different things (empty?/tail?) wh
Hi -jn-
At 11:32 AM 12/15/99 -0600, you wrote:
>BORING PREFACE:
>
>Perhaps I should clarify my purpose. My 25+ year career in computing
>(including 12 years teaching math and computing science) has routinely
[snip]
With all due respect ... ;-)
>ACTUAL REPLY:
>
>[EMAIL PROTECTED] wrote:
>> ...
HEAD)?
-Ted.
*** REPLY SEPARATOR ***
On 12/15/1999 at 3:15 PM [EMAIL PROTECTED] wrote:
See below:
Russell [EMAIL PROTECTED]
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 15, 1999 11:42 AM
Subject: [REBOL
Those were the words of [EMAIL PROTECTED]:
> See below:
>
> Russell [EMAIL PROTECTED]
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, December 15, 1999 11:42 AM
> Subject: [REBOL] "logical&qu
See below:
Russell [EMAIL PROTECTED]
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 15, 1999 11:42 AM
Subject: [REBOL] "logical" value referencing ... Re:(3)
[skip]
> Personally, I'm also trying to be
> in which "the series" returned by 'append is clearly different from
"the series" referred to by 'b.
If you are trying to get the "big picture" of the series, compare the
results of "head a" and "head b".
A and B are different entry points to the same series.
The confusing part is that the "
Russell [EMAIL PROTECTED]
- Original Message -
From: Russell Yost <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 15, 1999 12:12 PM
Subject: Re: [REBOL] "logical" value referencing ... Re:(2)
> See below:
> Russell [EMAIL PROTECT
BORING PREFACE:
Perhaps I should clarify my purpose. My 25+ year career in computing
(including 12 years teaching math and computing science) has routinely
involved learning new programming languages to tackle a project-du-jour.
My experience is that when I have trouble getting my head around so
>I explained it already to two people, and saved them probably several
tens of minutes of frustration ... Maybe more examples coud be found
...
Perhaps REBOL.ORG could add a "Help Page" library to go with the script
library.
Of course, it will also be grand when REBOL exposes the FeedBack
Knowl
> A series is a block; a block is a series.
Quite right, I misspoke. All series are blocks, but not all blocks are
series.
> but if you alter the sequence, a series that refers to it may get
sick
The index points to the nth element, not to element n. This is how
series are designed. As another
Hi Joel!
You wrote:
>Perhaps I should have addressed my comments to the documentation
>team, rather than the general mailing list. However, it seemed (and
>still seems) to me that some confusion arises from lumping all of
>these operators together as operating on series values, when they
>are
[EMAIL PROTECTED] wrote:
> The first edition of _Programming_Perl_ (Wall/Schwartz) had a
> section called "Common Goofs for Novices", which I found VERY helpful
> in building a mental model of Perl. Later writings included hints
> for people coming from c, shell scripting, etc. I've seen the
[EMAIL PROTECTED] wrote:
>
> A series is a block; a block is a series.
>
No. Consider the following:
>> argument: "I don't think so!"
== "I don't think so!"
>> type? argument
== string!
>> series? argument
== true
>> block? argument
== false
>> any-block? ar
At 05:00 PM 12/13/99 -0500, you wrote:
>So it is important to remember that the variables point to the nth
>element of the series, not to the element itself.
>
>I agree that it would seem convenient to have something like a pointer
>to an element, that moved when it moved (without looking it up ag
Consider this, Joel.
A series is a block; a block is a series.
Blocks can store anything, even other blocks, or nothing.
Blocks can store code or data.
A block exists in it's own right. The REBOL variables are simply an
(arbitrary) index into the block. The block does not contain a position
[EMAIL PROTECTED] wrote:
>
> Just to back-up Elan's post:
>
> "The change, insert, remove, and clear functions directly affect the
> series provided as the first argument. If you have other variables that
> refer to the same series, after the operation they may no longer
> reference the same val
1 - 100 of 102 matches
Mail list logo
