Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Newbie Q: Cropping text

 [1/24] from: kimm2:mcmaster:ca at: 3-Jul-2002 15:49


What line of code in REBOL will crop text? (Without loops) For example, I want the first 3 characters in the string "asdfghjkl". Result should be: "asd". Thanks! Matt

 [2/24] from: chris:ross-gill at: 3-Jul-2002 17:39


Hi Matt,
> For example, I want the first 3 characters in the string "asdfghjkl". > > Result should be: "asd".
If you want to 'crop' a string! or any kind of series!, use copy --
>> copy/part "asdfghjkl" 3
== "asd" - Chris

 [3/24] from: lmecir:mbox:vol:cz at: 4-Jul-2002 0:27


Hi Matt, do you mean something like: copy/part "asdfghjkl" 3 ; == "asd" -L ----- Original Message ----- From: "Matthew Kim" <[kimm2--mcmaster--ca]> To: <[rebol-list--rebol--com]> Sent: Wednesday, July 03, 2002 9:49 PM Subject: [REBOL] Newbie Q: Cropping text What line of code in REBOL will crop text? (Without loops) For example, I want the first 3 characters in the string "asdfghjkl". Result should be: "asd". Thanks! Matt

 [4/24] from: belymt:saunalahti:fi at: 4-Jul-2002 0:56


At 15:49 3.7.2002 -0400, you wrote:
>What line of code in REBOL will crop text? (Without loops) > >For example, I want the first 3 characters in the string "asdfghjkl". > >Result should be: "asd". >> A: "this is a string" >> B: copy/part a 3 >> print B
thi Ok?

 [5/24] from: chalz:earthlink at: 4-Jul-2002 1:02


Here's a variant. Suppose I only want characters 2 through 5? Or 3 until the end? Or I want to remove those selections? Personally, I have a hard time working with series! with next and skip and tail and so forth. A pointer to a list element which I cannot see irritates me.

 [6/24] from: g:santilli:tiscalinet:it at: 4-Jul-2002 12:48


Hi Charles, On Thursday, July 04, 2002, 7:02:50 AM, you wrote: C> series! with next and skip and tail and so forth. A pointer to a list element C> which I cannot see irritates me. Ok, so you need: right: func [series [series!] elements [integer!]] [ copy skip tail series negate elements ] left: func [series [series!] elements [integer!]] [ copy/part series elements ] mid: func [series [series!] start [integer!] length [integer!]] [ copy/part at series start length ]
>> right "abcdefg" 3
== "efg"
>> left "abcdefg" 3
== "abc"
>> mid "abcdefg" 3 3
== "cde" Adapt REBOL to you, not the opposite. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [7/24] from: greggirwin:mindspring at: 4-Jul-2002 10:35


Hi Charles, Only one question left to be answered: << Or I want to remove those selections? >> set-mid: func [series [series!] new-data start [integer!] /part len [integer!]][ len: any [len length? new-data] head change/part at series start new-data len ] --Gregg

 [8/24] from: kimm2:mcmaster:ca at: 4-Jul-2002 23:07


All I gotta say is... You guys/gals are good! :thumbs up: Thanks for the awesome help! Matt

 [9/24] from: brett:codeconscious at: 4-Jul-2002 18:15


To Matt: There is also:
>> parse/all "asdfghjkl" [copy text 3 skip to end]
== true
>> probe text
"asd" == "asd" To Charles: copy/part at series 2 next at series 5 copy at series 3 remove/part at series 2 next at series 5 remove at series 3
> Personally, I have a hard time working with > series! with next and skip and tail and so forth. > A pointer to a list element which I cannot see irritates me.
I don't understand what you mean. That is, what do mean by see? I suppose you could say that REBOL does not make pointers an explicit datatype, and I reckon that is a good thing. It is good because pointers are often easily mishandled and cause nasty memory errors. Not only that but they are a difficult concept to learn in the first place. However, pointers are a useful concept with great flexibility. REBOL maintains that flexibility in the series! datatype while at the same time avoiding the problems that pointers have. It does it by abstracting the pointer concept through providing a reference and operations on the reference. This frees us as REBOL users from having to know about the underlying physical storage - a wonderful thing. We can forget about pointers too (unless you have to talk to a C DLL). I admit that my learning about REBOL series was intially a bit hard too. After a while it became more natural to me. One issue for me was the two aspects of series: (a) they store a sequence of items (b) they have a current index. These two aspects allow you to think of series in two ways (a) the whole of a sequence (b) a position within a sequence. Now I find I think in terms of (a) or (b) according to what is more appropriate for my task. Much better than being limited to one way of thinking. Sometimes the words I use reflect which of the two aspect I'm thinking in E.g (a) Accounts, site-list (b) current-position. Regards, Brett.

 [10/24] from: anton:lexicon at: 6-Jul-2002 3:22


I made a little demo which may help understanding series a bit easier for beginners. do http://www.lexicon.net/anton/rebol/demo/demo-series.r or through the Rebol desktop: Rebol.com/Sites/Anton/Demo/demo-series.r (the arrow looks a bit strange on the last full release of rebol, because I fixed it for the latest beta release. Don't worry, like this it will be fixed for the next full release.) Anton.

 [11/24] from: chalz:earthlink at: 7-Jul-2002 23:56


> To Charles: > > > Personally, I have a hard time working with > > series! with next and skip and tail and so forth. > > A pointer to a list element which I cannot see irritates me. > > I don't understand what you mean. That is, what do mean by see?
For instance, in C, I would have something like int idx; wherein I could use array[idx]; and move around by increasing and decreasing the index marker. How can I optically see where 'next will put me without evaluating it? How can I find out where REBOL believes itself to be in a series! ? Does REBOL think it's at the first value, the second, the third, etc? How can I find out?
> I suppose you could say that REBOL does not make pointers an explicit > datatype, and I reckon that is a good thing. It is good because > pointers are often easily mishandled and cause nasty memory errors. Not > only that but they are a difficult concept to learn in the first place.
Oddly enough, my first encounter with C was at WPI in Worcester, MA, in a programming class in which we were taught C. Once I got used to * and &, I honestly had no trouble with pointers. Well, understanding them. Zipping along and hitting '&' by accident when I wanted '*' occurred and such, but still...
> However, pointers are a useful concept with great flexibility. REBOL > maintains that flexibility in the series! datatype while at the same
<<quoted lines omitted: 3>>
> to know about the underlying physical storage - a wonderful thing. We > can forget about pointers too (unless you have to talk to a C DLL).
Well, since I don't have /Command, that is a moot point ;) Still, I like to know where REBOL is, or thinks it is. I like to be able to have some sort of index instantly available to me like that. Yes, I know, I can use pick series 3, but when I use 'next and 'skip and whatnot.... I get lost. And when REBOL modifies the source data when I really only wanted to look, that irritates me to death, especially when I'm still learning such manipulations.
> I admit that my learning about REBOL series was intially a bit hard > too. After a while it became more natural to me. One issue for me was
<<quoted lines omitted: 5>>
> way of thinking. Sometimes the words I use reflect which of the two > aspect I'm thinking in E.g (a) Accounts, site-list (b) current-position.
I'm still going to have to work on this more. I can see very often where REBOL is easier, particularly for new coders to learn. But it strikes me that people who've been coding for a while in languages like C run up against brick walls. ;) And I never ever liked using <> to mean "not equal". :P Thanks for your help, Brett. --Charles

 [12/24] from: atruter:hih:au at: 8-Jul-2002 16:27


> Does REBOL think it's at the first value, the second, the third, etc?
How can I find out?
>> a: ["a" "b" "c"]
== ["a" "b" "c"]
>> length? a
== 3
>> a: next a
== ["b" "c"]
>> index? a
== 2 Regards, Ashley

 [13/24] from: g:santilli:tiscalinet:it at: 8-Jul-2002 10:43


Hi Charles, On Monday, July 08, 2002, 5:56:12 AM, you wrote: C> For instance, in C, I would have something like int idx; wherein I could use C> array[idx]; and move around by increasing and decreasing the index marker. How idx: 3 series/:idx C> can I optically see where 'next will put me without evaluating it? How can I C> find out where REBOL believes itself to be in a series! ? Does REBOL think C> it's at the first value, the second, the third, etc? How can I find out? index? series C> I'm still going to have to work on this more. I can see very often where C> REBOL is easier, particularly for new coders to learn. But it strikes me that C> people who've been coding for a while in languages like C run up against brick C> walls. ;) And I never ever liked using <> to mean "not equal". :P Thanks for C> your help, Brett.
>> !=: get first [ <> ] >> 1 != 2
== true Adapt REBOL to yourself... :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [14/24] from: brett:codeconscious at: 8-Jul-2002 18:53


Hi Charles,
> > > Personally, I have a hard time working with > > > series! with next and skip and tail and so forth. > > > A pointer to a list element which I cannot see irritates me. > > > > I don't understand what you mean. That is, what do mean by see? > For instance, in C, I would have something like int idx; wherein I
could use
> array[idx]; and move around by increasing and decreasing the index marker.
How
> can I optically see where 'next will put me without evaluating it?
Hmm. C. My first attempt at C, a twenty line program, crashed my machine in spectacular style. I don't really know C, but if my memory serves correctly array[idx] is roughly equivalent to AT array idx in REBOL, except that array[idx] is a memory location and AT array idx is a series! (a "smart value"). AT - Returns the series at the specified index. NEXT is like using AT array 2 If you want to get information out you can use PICK array idx, and to put it in you can use POKE array idx value. So you can use an absolute style of referencing if you want to (presuming array is at its head).
> How can I > find out where REBOL believes itself to be in a series! ? Does REBOL
think
> it's at the first value, the second, the third, etc? How can I find out?
INDEX? - Returns the index number of the current position in the series.
> Still, I like to know where REBOL is, or thinks it is. I like to be
able to
> have some sort of index instantly available to me like that. Yes, I know,
I
> can use pick series 3, but when I use 'next and 'skip and whatnot.... I
get
> lost. And when REBOL modifies the source data when I really only wanted
to
> look, that irritates me to death, especially when I'm still learning such > manipulations.
No, I doubt that REBOL modifies the source data. Forgive me if I am wrong here but I think you might be referring to this sort of expression: sequence: next sequence The evaluation of this expression should be understood in three steps. I'll try to explain further with examples and use block! for the series!. sequence: [1 2 3 4 5] The line above has two values a set-word! and a block! So somewhere in REBOL's memory a series of values 1, 2, 3, 4, 5 has been created, and is represented by a block! datatype. Subsequently, during evaluation, the word Sequence is set to refer to the new block! (series!) value. But the word is not referring to 1 2 3 4 5, it refers to a block! which has an index and a reference to the sequence of values. Now compare the previous example with this: char-sequence: next [a b c d e] This line has three values - a set-word!, a word! and a block!. When this line is evaluated, again a block! series of values will be created, this time of five words (a, b, c, d, e). The block! will be at its head (head? returns true). Then NEXT is evaluated and it takes the block as input. NEXT returns a different block! value - that is the new block! has a different index to the original but retains a reference to the same sequence of elements. Finally in the evaluation, char-sequence is set to refer to this new block! and if you perform INDEX? on char-sequence afterwards, you will get the value 2 returned. If you performed FIRST HEAD char-sequence you would get the value 'a returned. So now this next expression of six values a: next b: next c: next sequence: [a b c] If you print sequence you will find the original data intact. If you print c you will see "[b c]" this is because the index of the block! that B refers to is equal to 2. If you print b you will see "[c]" this is because the index of the block that A refers to is equal to 3. If you print a you will see "[]" this is because the index of the block that A refers to is equal to 4 and is at the tail of the sequence. Executing REMOVE B will change the underlying data sequence, but each block! that A, B and C refer to do not change. Now if you try printing A you will get an error message. This is because A's index is past the tail of the series. But A can still be used try printing HEAD A. So in this last example I have made four seperate references to the same underlying data series and each of these is referred to by a different word (A, B, C and Sequence). So now, at last :^) I make my point. In effect, when you use NEXT you get a new value returned to you than what you gave it and not something that is modified. But the thing you get back shares the same underlying sequence of values as the input series to NEXT. And when you issue: sequence: next sequence instead of: next-bit: next sequence you are effectively choosing to discard the original reference.
> I'm still going to have to work on this more. I can see very often
where
> REBOL is easier, particularly for new coders to learn. But it strikes me
that
> people who've been coding for a while in languages like C run up against
brick
> walls. ;)
This was a significant issue for me. Just prior to learning REBOL a lot of my commercial experience was using a compiled language and I had not met functional languages before. The hardest things for me were to accept the descriptions of REBOL evaluations in the documentation at face value and to stop looking at lines of code (compiled in my mind) and instead look at values and expressions being evaluated one ofter the other.
> Thanks for your help, Brett.
My pleasure. I hope the descriptions above are useful and not uselessly wordy! Brett.

 [15/24] from: anton:lexicon at: 8-Jul-2002 19:22


There is also 'at, to set the position: a: ["a" "b" "c"] a: at a 2 ; also try negative values a ; == ["b" "c"] a: head a ; == ["a" "b" "c"] Anton.

 [16/24] from: joel:neely:fedex at: 8-Jul-2002 9:01


Hi, Charles, You've already gotten specific answers from other folks (INDEX?, AT, HEAD, etc...) so please allow me to wax philosophical for a moment or two. Charles wrote:
> For instance, in C, I would have something like int idx; wherein > I could use array[idx]; and move around by increasing and
<<quoted lines omitted: 3>>
> it's at the first value, the second, the third, etc? How can I > find out?
First, a couple of background ideas: - I used to tell my students that (aside from the practical value of getting paid ;-) there is no point in learning another programming language unless it somehow changes the way you think. - My dad, a retired aero-space engineer, was known for asking a question that I've found extremely useful in software design: In order to what? Low-level languages, such as c, lead us to conceptualize what we're doing in terms of the mechanics of doing it. Higher-level languages, such as REBOL, LISP, SQL, ... tend to focus our attention on *what* we're doing, rather than the mechanics of a specific approach. In my own development as a programmer, I found it very liberating -- but initially uncomfortable -- to "let go" of the familiar details and focus on purposes & goals rather than details & mechanisms. Despite over thirty years in programming (during much of which time I've known this principle) I still catch myself from time to time giving too much attention to the mechanics. The application of all that metaphysical musing is this: REBOL gives me several different ways to navigate through the structures that my programs have built up. Choosing which one to use is (for me, at least) usually a matter of thinking about my purposes, and deliberately ignoring everything else. If you'll pardon the simple analogy: - Suppose I'm working in a grocery store, and my manager hands me a box of soup cans with the instruction to put them on a display shelf, I can do that without knowing how many cans there are in the box. I just take the cans, one at a time, and place each can in the "next" available space. - If his instructions were instead to refill the shelf with as many cans as would fit, and then tell him how many cans were required, I can simply add one to a count (starting with zero before the first can) as I place each one, then report the final value of the count. It doesn't matter which end of the box (or the shelf) I start from, nor whether the box had already been opened and partially used. I could go on with more hypotheticals, but my point is that there are many situations where the units (cans) are interchangeable in some sense, so I simply don't need to keep up with any notion of position. total: count: zero foreach item someblock [ if number? item [ total: total + item count: count + 1 ] ] either zero? count [ print "No numbers found" ][ print ["Average of numbers is" total / count ] If the above is evaluated, then the numbers in the remaining portion of SOMEBLOCK will be averaged. "Remaining portion" may be the whole block, or it may be what's left after some other operation. (The box had already been opened and partially used for some other purpose, or -- to switch metaphors -- a search may have been made for the section of the block meeting some criterion.) The point is that unless the concept of position is critical to my current purpose, my thinking will likely benefit from doing away with that concept on my "palatte" of ideas for painting my picture of what I'm doing. To a certain extent I think of this as like writing a sonnet or composing a minimalist typographical design: the elegance seems often to arise from a deliberate choice to work within specific self-imposed constraints.
> Still, I like to know where REBOL is, or thinks it is. >
This one has already been addressed by others, but let me add an extra bit of philosophy: Sometimes (in low-level langugages) we need to keep up with our position in an array because we need to process an element in a context that includes its neighboring values. For example, a simple smoothing algorithm might calculate the average of each value with its immediate neighbors, giving us something like for (i = 1; i < N - 1; ++i) { b[i] = (a[i-1] + a[i] + a[i+1]) / 3.0; } However, if I think about the above bit of code in The Language That Must Not Be Named, I realize that I'm just using the index expressions i-1 i i+1 to encode the idea of neighboring elements. I can do the same thing in REBOL without reference to absolute position, but to relative position just as well, in a variety of ways: b: make block! NN: (length? a) - 2 c: a loop NN [append b (first c) + (second c) + (third c) / 3.0] as one example.
> I like to be able to have some sort of index instantly available > to me like that. >
If that's what you want, it's certainly OK (and already answered by others on the list), but I'd suggest taking some time to think through some common tasks you perform and consdider *whether* and *why* you really *need* some of the ideas you're used to using. I get great fun from discovering ways to do without something that I thought I had to have!
> I'm still going to have to work on this more. I can see very > often where REBOL is easier, particularly for new coders to learn. > But it strikes me that people who've been coding for a while in > languages like C run up against brick walls. ;) >
Learning to think differently takes work and time, but the rewards are definitely there (speaking from personal experience)! -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [17/24] from: alexander:johannesen:bekk:no at: 8-Jul-2002 17:26


Hi people, Joel wrote:
> Learning to think differently takes work and time, but the > rewards are definitely there (speaking from personal experience)!
Thanks for sharing those thoughts, Joel. Very true stuff. I'm a newbie to Rebol myself, trying to grasp its methods and functions, and I - as many others - have some trouble letting go of a lot of functional and data-centric methodology in order to get a better understanding of the ways of Rebol and focusing on the result instead of the task. I'm pressed in the fact that I *understand* that Rebol is the Right Choice(TM) for many problems I try to solve, yet find myself held back by my maybe simple mind and ability to think a couple of steps ahead. Rebol offers me a lot I need and want, but I can't seem to get into the bare facts of how to do things right. I find the lack of a coding standard both a weakness and a great; it makes it harder for *others* to understand your code, but it really makes it easier for *you* to understand your own code. Now, a concrete question to round off with; does anybody know of any really good tutorials (or somesuch)? I find the original examples from the rebol.com site fair enough, but they are so simple that they are of little practical value. Does there exsist more advanced examples, books and / or tutorials? Kind regards, Alexander -- http://shelter.nu/

 [18/24] from: joel:neely:fedex at: 8-Jul-2002 12:42


Hi, Alexander, [alexander--johannesen--bekk--no] wrote:
> Now, a concrete question to round off with; does anybody > know of any really good tutorials (or somesuch)? I find the > original examples from the rebol.com site fair enough, but they > are so simple that they are of little practical value. Does there > exsist more advanced examples, books and / or tutorials? >
There are some articles, examples, etc. (from a variety of folks) at http://www.rebolforces.com/ HTH! -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [19/24] from: joel:neely:fedex at: 8-Jul-2002 12:41


Note to self: Proffredd befour hittyng sind! Joel Neely wrote:
> > b: make block! NN: (length? a) - 2 > c: a > loop NN [append b (first c) + (second c) + (third c) / 3.0] >
Should have read b: make block! NN: (length? a) - 2 c: a loop NN [ append b (first c) + (second c) + (third c) / 3.0 c: next c ] -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [20/24] from: chalz:earthlink at: 9-Jul-2002 0:33


FAH!! My apologies for the previous post, wherein no text was added :/
> >> !=: get first [ <> ] > >> 1 != 2 > == true > > Adapt REBOL to yourself... :-)
Yeahbut, if you do that too often, your code won't be portable, unless you include your custom definitions in every script you submit, or include a list of other scripts people need to run yours, etcetc.. ;)

 [21/24] from: chalz:earthlink at: 9-Jul-2002 0:24



 [22/24] from: chalz:earthlink at: 9-Jul-2002 1:45


Cool! At last! ;)
>> do http://www.lexicon.net/anton/rebol/demo/demo-series.r
connecting to: www.lexicon.net ** Script Error: This script needs view or better to function correctly ** Near: do http://www.lexicon.net/anton/rebol/demo/demo-series.r
>>
I think I'm going to save any further reading about series! and such until later, when I'm more fully awake and don't have a sleeping cat stopping me from note taking. Thanks all! --Charles

 [23/24] from: chalz:earthlink at: 9-Jul-2002 1:35


First off, my thanks to everyone demonstrating The Way Things Work. I don't get to work in REBOL all that much anymore, so what knowledge I had of it has dwindled, and I find myself looking at older code of my own and thinking, "Why did I do that? It works, but *how* does it work?"
> char-sequence: next [a b c d e] > This line has three values - a set-word!, a word! and a block!. When this
<<quoted lines omitted: 7>>
> get the value 2 returned. If you performed FIRST HEAD char-sequence you > would get the value 'a returned.
Whoah. That.... damn. That's just screwed up. So if I POKE a new value into the original sequence, the char-seq gets changed as well. Wow. Time to make prodigious use of COPY, it looks like. *whistles*
> So now this next expression of six values > a: next b: next c: next sequence: [a b c]
<<quoted lines omitted: 4>>
> same underlying data series and each of these is referred to by a different > word (A, B, C and Sequence).
AAAAAIIIIIEEEE!!!!! *gun shot*
> > Thanks for your help, Brett. > > My pleasure. I hope the descriptions above are useful and not uselessly > wordy!
Heh. No, not too wordy. However, I am now frightened of REBOL ;) CarlS is certainly a madman ;) --Charles

 [24/24] from: brett:codeconscious at: 9-Jul-2002 18:44


Hi Charles,
> First off, my thanks to everyone demonstrating The Way Things Work. I
don't
> get to work in REBOL all that much anymore, so what knowledge I had of it
has
> dwindled, and I find myself looking at older code of my own and thinking,
Why
> did I do that? It works, but *how* does it work? > > > char-sequence: next [a b c d e] > > > > This line has three values - a set-word!, a word! and a block!. When
this
> > line is evaluated, again a block! series of values will be created, this > > time of five words (a, b, c, d, e). The block! will be at its head
(head?
> > returns true). Then NEXT is evaluated and it takes the block as input.
NEXT
> > returns a different block! value - that is the new block! has a
different
> > index to the original but retains a reference to the same sequence of > > elements. Finally in the evaluation, char-sequence is set to refer to
this
> > new block! and if you perform INDEX? on char-sequence afterwards, you
will
> > get the value 2 returned. If you performed FIRST HEAD char-sequence you > > would get the value 'a returned. > Whoah. That.... damn. That's just screwed up. So if I POKE a new
value
> into the original sequence, the char-seq gets changed as well. Wow. Time
to
> make prodigious use of COPY, it looks like. *whistles*
Not screwed up at all :^) C'mon Charles, you were the one that mentioned pointers! C represents strings with a pointer to char, and if you want to make a duplicate of a string in C you have to use strcpy or whatever it is called. And you could have two pointers to the same string in C. So yes, there is only one sequence of elements, and yes COPY has a very good purpose. However, this whole pointer description is avoided in REBOL docs because it is not really required - it is only useful for old-language programmers ;^) REBOL uses word! as a symbol. You can set a word to a value but that does not mean that the word has the datatype of the value - only the value has that, the word is simply a reference to the value. And as I mentioned before more than one word could refer to the same thing, and the same word over time can refer to values of completely different datatypes.
> > So now this next expression of six values > > a: next b: next c: next sequence: [a b c] > <snip> > > Now if you try printing A you will get an error message. This is because
A's
> > index is past the tail of the series. But A can still be used try
printing
> > HEAD A. So in this last example I have made four seperate references to
the
> > same underlying data series and each of these is referred to by a
different
> > word (A, B, C and Sequence). > AAAAAIIIIIEEEE!!!!! *gun shot*
<<quoted lines omitted: 3>>
> > wordy! > Heh. No, not too wordy. However, I am now frightened of REBOL ;)
CarlS is
> certainly a madman ;)
:^)) Actually I feel safer using REBOL than all the other languages I programmed with over nearly two decades. The expectations and assumptions we bring to a new situation colour it in a certain way but it may not be the "reality" or the way we'll see the situation in time. My little bit of philosophy for the day. :^) Regards, Brett.

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted