AltME groups: search

If you don't want to be hit by the pick 0, you can stay at head position 
of the series cannot you?

You can stay at the beginning of the series if you add the base offset 
to every calculated index reference. Bad idea in REBOL, too slow, 
but maybe Red's optimizer will be smart enough to undo that calculation. 
How many algebraic transformations will the optimizer be able to 
handle?

Keep in mind though that another occasion when you use computed indices 
with PICK/POKE is when you do stuff like s/(x) or s/(x): val, since 
path references for series should be using PICK/POKE internally.

One occasion where you use computed indexes is when you do C-style 
fake multidimensional array access. As with C, however, the math 
tends to be 0-based because of the modulus, so a 0 hole really hurts 
here. You can do these calculations much more easily if your base 
series position is 2 (or plus 1 * (dimension - 1) for each dimension) 
because the 0's go back one.

As someone who is at say level 5 on the btiffin rebol scale what 
I am about to suggest may be stupid - if so be gentle :) Could we 
not create a different structure other than a series (an array or 
a matrix etc) that is 0 based and index driven and works like in 
most other languages for those who need that kind of usage?  Or could 
we introduce for series an index manipulation system such as this:s1/index: 
4, add s3/index 2, subtract s2/index 2, inc s3/index, dec s2/index, 
++ s1/index, s1/index: s1/index + off etc.

Negative indices being back from the tail of the series: please, 
no, never.

 - yes, this needs some analysis to find out what may be wrong about 
 that idea. The starting point may be that the series tail is "ephemeral" 
 in a sense as I noted, while the head is not ephemeral at all.

Indeed, any modification of a series changing its length, in the 
middle of a loop over a "reversed" view of that series, would most 
probably provoke errors.

Ladislav, we don't need analysis on negative indices being back from 
the tail of the series. The concept only makes sense if you are only 
able to refer to a series from its head, thus negative indexes don't 
really have a meaning if you see the series as linear, so you decide 
to give negative indexes a meaning by looking at the series as a 
loop where the end wraps around to the beginning and vice-versa. 
If you are able to refer to a series frome a base position of somewhere 
other than at its head then you already have a meaning for negative 
indexes, and don't need to make up another.

Note that with R3-style bounds checking, the none value is considered 
to be roughly the same as a hole in the data. PICK past either end 
returns none. That means that PICK 0 returning none is basically 
a statement that there is a hole in the middle of the series that 
is just before the current position, and moves along as the series 
position moves along. Now, try to come up with a way to explain to 
newbies that this phantom hole in a series makes sense, or is a good 
idea.

At least triggering an error is easier to explain, it means that 
0 doesn't exist, like we're programming in Roman. It's (slightly) 
better than the 0 index existing but referring to a hole in the series 
(R2-style behavior).

Well, really difficult to settle, any way you think abou the topic. 
I can think about 0 as about in-between, non real value - like Max 
mentioned vectors, simply first element in series to the left, or 
to the right. Then I can think about 0 as about real value - if I 
look outside, there is -1C temperature. And in order to get to 1C 
temperature, 2 grades are needed, hence 0 is real value here. And 
finally - if I will have some real series in front of me, e.g. 10 
ppl, I can pick first, second, first to the right, first to the left 
(-1), hence no zero or negative index here ...

btw - will Red have range! datatype? And would it influence the way 
we look into series, positioning, indices, etc?

Range! datatype: I would like to add one, but it needs preliminary 
study on how it can affect series semantics.

Here is a new proposition for solving the "PICK issue":

1) Forbid <= 0 indexes.


2) Add a PICK-BACK action that will take only positive integers, 
PICK-BACK series 1 would return the first element on the left of 
current series position.


3) As PICK-BACK is not a very nice and concise name (I like actions 
to be named with a single word), an op! alternative would be provided: 
<- (opening angle-bracket followed by a dash aka "ASCII arrow")

Examples:
    >> series: next [A B C]
    >> pick-back series 1
    == A
    >> series <- 1
    == A
    >> series <- 2
    == none			;-- to be consistent with out-of-bound PICK


For path notations options in such scenario, I'm open to propositions. 
So what are the pros/cons of such solution?

As for naming wouldn't a refinement be better?

pick/back series pos-int

first to left

: that's how I read `series/-1` in R2...So if it's just a matter 
of making an implicit convention explicit, better just add a statement 
in the documentation than pay the cost of an additional datatype, 
no?

I think that such computation could be decorrelated from how you 
finally access the series element with the result of the computation.

R3 was optimized AFAIU specifically for this (extremely?) rare use-case 
over the very common cases for what R2 is optimized for (typically 
`series/-1`). So, could we find, at least one! use-case, where you 
need to compute indexes over current position (where R3 convention 
would prove to be better than R2).

Note also that in the PICK/BACK scenario, negative integers become 
available for a new possible usage, like addressing a series from 
tail (if that makes sense in a REBOL-like language). I know Brian 
is fully against that, but we need objective arguments to reason 
upon. "From tail" indexes are still a toy idea for me, until we can 
list all the pros/cons and see if it is an helpful addition or a 
bad idea.

My Understanding of Series:

A contiguous collection of boxes sequentially numbered in ascending 
order starting at 1.
Each box can contain any rebol value
The head of a series is always box number 1

The last item in a series is always in box number (length? series)
The tail of a series is always box number (length? series) + 1

Any series can have multiple words referencing any box in that series 
resulting in a sub-series (but not a copy)

index? series - always returns the box number of the value referenced 
by series

Evaluating a word referencing a series returns the series from box 
number (index? series) up to and including box number (index? tail 
series)

index? is the only rebol word that directly uses the box numbers 
of the series

All other rebol words that manipulate series are relative to the 
box number of the word referencing the series

A series is empty when: equal? head series tail series => true – 
or – when all boxes are empty

Examples:

s1: [a b c d e f g h i j]  => creates 10 boxes numbered 1 to 10 from 
the left with a in box 1 and j in box 10 – unseen is box 11 which 
is 'tail as seen by: index? tail s1

s2: at s1 3 => references s1 starting from box 3 of s1 - [c d e f 
g h i j]

s3: at s2 4 => references s1 starting from box 6 of s1 - [f g h i 
j] which is item 4 of s2

probe index? s1 => 1
probe index? s2 => 3
probe index? s3 => 6


probe head s3 => [a b c d e f g h i j] - showing that s3 references 
the same series as s1

probe pick s1 2 => 'b
probe pick s2 2 => 'd
probe pick s3 2 => 'g


probe s3/-2 - this is shorthand for back back s3 or pick s3 -2 (the 
negative number simply means move back twice) => 'd

probe tail s1 => []
probe tail s2 => []
probe tail s3 => []

forall s2 [prin first s2] print => cdefghij
forall s3 [prin first s3] print => fghij

probe index? tail s1 => 11

Possible SOLUTION:

So, what is missing? Words that directly manipulate the box numbers 
(index)? – so maybe we need something like this:

s1/index: 4 => sets the index of s1 to 4 and causes word s1 to reference 
the series starting from box 4

add s3/index 2 => adds 2 to the index of s3 causing s3 to reference 
the box 2 places further on => 'h

add s2/index -2 or subtract s2/index 2 => subtracts two from s2's 
index causing s2 to now reference box 1

You can now use any mathematical operations on the index of a word 
referencing a series as long as it results in an integer in range

If index? series > (length? series) + 1  or index? series < 1 then 
an "index out of bounds" error should result
Zero is a non-issue because it has no meaning in a 1 based series

This kind of shorthand: s1/-3 becomes redundant - but if kept still 
means: back back back s1

I honestly think there is so much confusion over this because we 
are trying to merge together two different "concepts". Concept 1 
is a series which is traversed as in Rebol 2 and whre s/-2 is shorthand 
for back back s. Concept 2 is a 0 based sequence which is traversed 
via index manipulation. The concepts need to be kept seperate even 
if they are applied to the same set of contiguous boxes. The only 
way to do this as far as i can see is to develop a set of index manipulation 
functions in addition to the existing series traversal functions. 
The concepts can then be easily taught to newbies and gurus can mix 
and match to their hearts content.

There is no 0 by convention - that is what defines the "concept" 
of  series traversal. Arrays are traversed by index manipulation 
whether 0 based or not..

Yes but Frst s and Pick s 1 are series functions - not index manipulation 
functions - different concepts - first s in index system would be 
s[i]

if s is at box 4 in the original series then pick s 1 returns the 
contents of box 4 not box 1

It's just a dialect for going in the opposite direction

 - it is not, in fact. (PICK SERIES INDEX) is just an evaluation of 
 a function, not a "dialect"

Now, try to come up with a way to explain to newbies that this phantom 
hole in a series makes sense, or is a good idea.

 - yes, a good illustration from a beginner/documentation/education 
 POV. Also, what is exactly as bad even for experienced users is that 
 it disrespects arithmetic making simple index arithmetic (ADD INDEX 
 OFFSET) not usable.

It's just a dialect for going in the opposite direction" - it is 
not, in fact. (PICK SERIES INDEX) is just an evaluation of a function, 
not a "dialect""

False. PICK SERIES INDEX is usually evaluated as DO dialect. It could 
also be evaluated as any other dialect

SERIES/-1 is not even function evalutation in the DO dialect, it's 
path evaluation

My Understanding of Series:
A contiguous collection of boxes sequentially 
numbered in ascending order starting at 1.

 - this is correct only for series I would call "Head Series", i.e. 
 such series that are their own heads.

Here is a task I consider relevant:


1) define a function obtaining a series S and an index I and yielding 
an index J such that PICK S I would be equivalent to PICK HEAD S 
J
1a) do the task in R2
1b) do the task in R3
1c) do the task in R4 with zero-based indexing

I already stated I'm not talking about your mathematical exercise, 
but about common programming patterns in REBOL, such as series/-1

Ladislav, thanks for bringing a tangible example that demonstrates 
our both points. I will try to be brief:


1) I will start by repeating again that nobody contests that having 
a continuous numbering is better than a discontinuous one (for pure 
arithmetic efficiency, as you've showed).


2) Brian showed that R2 is not "broken" as the head-index? function 
can be written. 


3) I have never needed to write such "workaround" in R2, nor did 
I remember seeing it in others code (if someone did use such workaround, 
please step in, we need real-world use-cases).


4) According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases. 


5) I often use series with an offset and I do index computation on 
them, but usually, in a single direction at a time (using only positive 
*or* negative indexes). In the very rare cases where I need an index 
computation "over 0", I switch to absolute (from head) indexing, 
but not relying only on index arithmetic, but also on series navigation 
using the INDEX? SKIP idiom. This short idiom gives exactly what 
your head-index? function gives to you, but using series navigation 
abilities rather than pure index arithmetic. Of course, it works 
because SKIP is an implicit 0-based system with no hole.


6) INDEX? SKIP in R2 solves the "hole issue", for the very rare cases 
where we need to solve it. So, allow me now to propose my own head-index? 
implementation:

    head-index?: func [s [series!] i [integer!]][index? skip s i]


It is not pure arithmetic for sure, but we are programmers, not mathematicians 
(except you who is both :-)), so this solution is IMHO as acceptable 
as pure arithmetic ones, from a programmer's point of view.


So, what I contest is the trade-off required for "fixing" index arithmetic 
in R3, resulting in IMHO "broken" PICK and path notation for 0 and 
negative indexes. Also, given that INDEX? SKIP is available in R2, 
the "fixing" seems even less necessary. Still, I am open to discussing 
options for improving index arithmetic but *without* having to break 
other features.


I think we will agree to disagree about the right trade-offs between 
R2 and R3.


So, can we now all focus on studying the different improvements proposed?

Doc, I can splint a broken leg but it doesn't make it less broken. 
Still, you're lucky thet you haven't been caught by this.


As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work. If PICKZ and POKEZ are available, those of us who need something 
that works will have something. I don't mind even making R3 work 
like this, but only with the error and the alternate working functions. 
Let the people who insist on using path notation bear the brunt of 
the problem, so be it.

For example, when traversing two series at the same time while using 
just one index variable (which is pretty common), you need to be 
able to use the variable to correctly point to the corresponding 
places in both series, which logically *needs* some version of "index 
arithmetic".

'So, what I contest is the trade-off required for "fixing" index 
arithmetic in R3, resulting in IMHO "broken" PICK' - this is the 
main point, as I see it. If I remember well, you consider PICK broken 
since "0 points (maybe unnaturally for you?) backwards for PICK"? 
If that is what you dislike, then I can sympathize, having similar 
feelings:


It is necessary to realize what PICK SERIES INDEX is supposed to 
do. In my opinion it is a "relative operation" (relative to the current 
series "index" - having two series with common head but different 
"indices" we expect the PICK function to yield different results). 
Us such, we need to realize that we already have a "relative operation" 
for series for quite some time, which nobody contests to be "relative" 
- it is the SKIP operation. So, we have SKIP SERIES I being relative 
and we should have a natural obtain-value-of SKIP SERIES I shortcut 
instead of the whole nonsense, which is what you instinctively do 
presenting your (in R2 wrong!) HEAD-INDEX?.

Excellent. With such a simple solution, even ordinal! seems excessive

 - OK, since Kaj named the solution "simple", I can agree that (and 
 never questioned) that SKIP SERIES I is a good operation to use and 
 that really produces the simplest possible:

(PICKZ SERIES I) ?= (PICKZ SKIP SERIES I 0)

As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work.

 - if PICK SERIES 0 yielding NONE is stupid, then triggering an error 
 is not less stupid

As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work


I agree that R2 not returning an error on 0 is a real issue that 
needs to be fixed. If someone thinks that disallowing 0 in a 1-based 
system makes me stupid, so be it.

I could use ordinals all the way to TENTH. It is a common practice 
in advanced REBOL code to assign these ordinals to other words that 
are used as local accessor functions for series-based data structures. 
Using those accessor functions makes the intent of the code written 
with them much easier to understand. This is a trick that Carl and 
I use pretty often, and the reason he defined ordinals that high 
ion the first place even if only the earlier ones tend to be used 
directly.

Binary! is a series datatype, integer! is a scalar datatype, they 
are fundamentally different.

Arghhh! My first time compiling something to Red:
-= Red Compiler =-
Compiling red/tests/sorting.red ...
*** Red Compiler Internal Error: Script Error : copy expected ran
ge argument of type: number series port pair
*** Where: process
*** Near:  [stack/push to type copy/part s]

Back to an older topic, hex syntax. If you had 16#abcdabcd translate 
to an integer!, it wouldn't have to be considered to be a conflict 
with #abcdabcd being an issue! value. It's just like {abcdabcd}, 
#{abcdabcd} and #abcdabcd are different now. There would be no reason 
to keep the hex syntax once the value is loaded, it could just be 
a regular integer. You could even keep the issue! type as a word 
type with some extra series-like operations supported, the way tuple! 
supports series-like operations without being a series.

SELECT full support implemented for all series datatypes (including 
path access syntactic sugar).

COPY on any-block! series implemented, /part and /deep supported 
(/types has not been implemented yet).

To avoid having to use to-logic when using refinements to pick a 
value in a series. For example:

In REBOL:
    foo: func [/only][pick [1 2] only]
    foo

    ** Script Error: pick expected index argument of type: number logic 
    pair
    ** Near: pick [1 2] ref

In Red: it should return 2.

Also, you won't find the source code of block literals in text format 
if you scan the binary, because they are stored as code and not data. 
That is the only way currently they can be stored in compiled binaries. 
Storing them as text would need a way to load them and then compile 
them at runtime (it will be possible in the future, but not right 
now).


Anyway, the probably best way to store all those series literals 
is to allow the use of a redbin format. We will have that too at 
some point.

I have added a new function type today: routine!. It allows to write 
a Red/System function in a Red program. The compiler will marshal 
(or type-cast) the arguments back and forth automatically.

Here is the Fibonacci example rewritten as a routine:

Red [ ]

fibonacci: routine [
    n          [integer!]
    return: [integer!]
][
    either n < 2 [
        n
    ][
        (fibonacci n - 1) + (fibonacci n - 2)
    ]
]


The function body is Red/System code, so it will run at full Red/System 
speed.


Integer! and logic! values are converted automatically, other Red 
datatypes are passed boxed but type-casted as Red/System counterparts 
(as defined in the Red runtime). Hint: floats will be converted automatically 
too.

So, passing and processing a block! series would look like this:

Red [ ]

add-one: routine [
    blk       [block!]
    return: [block!]
    /local value tail int
][
    value: HEAD(blk)
    tail: TAIL(blk)
	
    while [value < tail][
        if TYPE(value) = TYPE_INTEGER [
                int: as red-integer! value
                int/value: int/value + 1
        ]
        value: value + 1
    ]
    RETURN(blk)
]


I haven't yet released the code, it needs a bit more work, it should 
be ready by tomorrow.


The purpose of routine! datatype is to provide access to ultra-fast 
and low-level code for Red program in a simple way. The design is 
not yet fully set in stone, so suggestions and comments are welcome.

@Doc : Just to be useful with assymetry in series, do you remember 
this TAKE discussion ? http://www.rebol.net/r3blogs/0082.html

empty?: function [
	series			[string!]
	return:			[logic!]
][
	tail? series
]

What's not implemented here? The problem seems to be in the series 
string! argument

... and even when I change s to series

I'm feeling nostalgic.  I used to hand-craft machine code on the 
6502/6510 series of processors back in the 80's, so I have an idea 
of what you're talking about.  There are some pretty neat tricks 
you can do when you're dealing with memory addresses directly.  I 
crafted more than one self-modifying program to squeeze every bit 
of computing power out of a processor.  I know that a lot of that 
ability has been removed by protected memory and abstraction, though.

cycle: func ["Cycle a series through its index."
	'series [word!]
	/local s
][
	either tail? s: get series [
		set series  next head s
		first head s
	][
		set series  next s
		s/1
	]
]

I hope you guys are considering the longer (hopefully not so long) 
term series streaming (from ports?) wrt to what you consider worthwhile 
functions in parse. I would think that some the in-place changing 
functionality is desirable for that kind of situation. I guess, copying 
might not even be an option if there is not significant buffering 
available. Am I totally off with this kind of thinking?

Kaj, what matters in such benchmark is not the usefulness of the 
resulting data, it is how the test stresses the language implementation. 
From that perspective, Fibonacci just tests the efficiency of nested 
calls, nothing else, no series manipulation, no memory allocation, 
very limited math, very limited control flow, ... The demo code will 
stress more parts of the implementation, hence giving you a more 
accurate picture (closer to what user will experience with their 
own scripts).


If you take the language Shootout tests, each test is meant to stress 
a specific part of each language, giving a good (and quite fair) 
comparison for each category.


I think we should implement them in order to get a good picture of 
Red performances and how they evolve. Anyone interested in implementing 
them? http://dada.perl.it/shootout/

Please put in your agenda the weekend of saturday the 26th and sunday 
the 27th of january. Then we will have the DevCon 2013 in De War 
'Place for Pioneers' in Amersfoort, the Netherlands. This year we 
will combine the Syllable Winter Conference with the DevCon, Conference 
for the REBOL Programming Language Family, as they have much overlap. 
Presentations will be done by Nenad Rakocevic and Kaj de Vos. We 
are open to other guest speakers and presentations? Entrance is free, 
but donations are very much appreciated. Keep an eye on this website:
http://devcon.esperconsultancy.nl/(will be updated soon)
and this Twitter-account:
https://twitter.com/devc0n

It is easily reachable by airplane (Schiphol, Amsterdam Airport) 
and by international trains. 

It's an old matches factory marked 'Spullenmannen', which is now 
being used by artists.

DE WAR


DE WAR is a breeding ground for art, technology and sustainability 
in Amersfoort, and is host to  a wide range of activities. Since 
2002 the Spullenlab has been the headquarters of Spullenmannen, an 
artists\u2019 collective making theatre, installations, visual art, 
and purposeless contraptions. A  shared office space was set up in 
2006, with different working places, a meeting room, and other facilities 
shared by a number of cultural enterpreneurs. The OpenTOKO workshops 
started in 2008, as a series of \u2019open knowledge\u2019 workshops 
on the connection between art and technology. Since 2010, DE WAR 
has also been housing FabLab Amersfoort, TransitieLab, and Studium 
Generale Amersfoort.  Moreover, a performing space for small theatre 
productions has been set up in 2011.


DE WAR has been established in the old match factory on the river 
Eem.  The factory complex dating back in 1881 has, besides from other 
activities, operated as a production facility of the Dutch colour 
dye industry, and is also known by the name of its last owner, Warner 
Jenkinson. Nowadays owned by the municipality of Amersfoort,  the 
factory complex faces an uncertain future, either to be demolished 
or to be renovated. Besides DE WAR several other offices and ateliers 
are housed within the same factory complex.


DE WAR is initiative  of PLAN B, at the address KLEINE KOPPEL 40, 
3812 PH in Amersfoort,

At a request, I upgraded R3 on Try REBOL from 2.99.111, the last 
official RT version, to Andreas' current build, the ongoing 2.101 
series. Not many changes, but some bug fixes.

http://tryrebol.esperconsultancy.nl


Graham programmed a nice bot for Stack Overflow chat that is able 
to call the Try REBOL web service to execute code examples and post 
the result.

This work will be paid for by Respectech as part of an assignment 
I'm doing for them. As far as we know, this is the first commercial 
assignment done with Red.


I'm implementing a network server that needs to run for long periods 
and handle relatively large numbers of requests. This is tricky because 
Red has no garbage collector yet, and the memory allocator doesn't 
handle large series yet. We have been testing the memory system to 
scale it, and Doc has fixed an allocator bug so that series can now 
be twice as large. I've also found and reported seven other bugs 
so far.


The results are very encouraging. The memory system is reliable in 
my stress testing. It can use all the memory available in a machine 
for the contents of series. In the default configuration, one series 
can have a maximum content of 2 MB, or 131070 values for a block!. 
This can be enlarged, basically at will, by compiling your program 
with customised allocator settings.


To reduce the amount of memory that currently cannot be reclaimed 
by garbage collection, I am reducing the number of series generated 
during the handling of each server request. This can be done within 
the same Red program, because low level optimised Red/System code 
can be inserted anywhere. I am down to only a few hundred bytes per 
handled request, and the memory budget of the server is a GB, so 
the Red 0MQ server will be able to handle several million requests.

In addition to these added programs, the existing interpreters and 
other programs have been rebuilt with the latest Red enhancements, 
including the doubled maximum size for series.


These new Red interpreters are candidates to be used in filming and 
streaming the presentations on the DevCon in Montreal.

i'm trying to extract article text from an awfully written series 
of html pages - one sample:


http://www.business-standard.com/india/news/vadra-/a-little-helpmy-friends//489109/

They made some awkward changes in the 3 series that I haven't reviewed 
yet

(Pardon the level-up in the lesson.)

That's not necessarily the case for R3, it's just the case *now*. 
COPY and PICK are just actions, which could easily be defined for 
the issue! type. You could get most of the R2-like behavior for issues 
in R3 by emulating the way tuples pretend to be series when they're 
really not.


The type classes in Rebol aren't like base classes in OOP languages, 
they are more like behavioral conventions, and those conventions 
are more like Go interfaces than anything OOP. Something is series-like 
to the extent that it behaves like a series is supposed to behave. 
But the acrions that are defined for series types are in some cases 
also defined for other types as well, and the corresponding behavior 
for those types can be similar enough to that of series to allow 
both series and, say, tuples, to be operated on by the same code. 
All that matters is how it seems to act from the outside, not what 
it really is.

We've been making this even more the case in R3 and R2 lately, such 
as when we allowed SELECT to be used on objects (and maps in R3), 
since that is a function that is used to make series act like objects. 
Or when we allowed APPEND to work on objects and maps in R3, since 
there was a corresponding behavior that could be defined for those 
types, but didn't do the same for INSERT because its positional return 
value has no corresponding concept for object-like types.

I was wrong. Simple programs like (print "Hello World") compile and 
execute, but programs with a lot of code compile but produce a series 
of errors when executed. I noticed a pattern. Wherever a word is 
not followed by ':' causes errors, examples below. Perhaps it's just 
this linux version of enface?

    stylize [
        fld80: field 80x28 font-size 17 white ivory center
        .......
    ]

produces the error:

    ** Script Error: stylize has no value
    ** Near: new-styles: stylize [
        fld80: field 80x28 font-size 17 white ivory center 
        fld400: field 400x28 font-size 17 whit...

I'll try this on windows when I have the opportunity.

I think that it's quicker, since you don't mess with series altering, 
insted you just create mixed words enough to reach the maximum available 
permutations.

I found the 'Rebol for Dummies' book quite disappointing for my personal 
use, but it might be good as a course book though. It certainly covers 
a lot of ground quickly. I personally preferred Nick's video series 
http://re-bol.com/rebol.html.Somehow more interesting and easier 
to digest. Just my personal experience.

Certainly the series copy trap is the one beginners will fall into 
most. Higher order functions won't be in their code, probably until 
they are comfortable with 'closure.

The "series copy trap" is what makes me hesitate about making closures 
the default function constructor. I think it should not be a "trap" 
in the first place, it is just undocumented, while it should IMHO 
be very clearly explained in the series chapter. Understanding how 
literal series behave is an important step in understanding Rebol.

It works correctly under R3. R2 is obviously using the head of the 
series. You can work around it by using COPY before NEXT.

I don't like the BACK BACK ... etc, depening upon the length of IDX 
which is what I want to print out 

Can I do something like LENGTH? IDX and use that number to "back 
up the series"?

How can I use the LENGTH? of IDX as a way to CLEAR those last positions.


ie IDX is 110, length is 3 then clear the last 3 characters from 
the ruler1 series and replace with to-string idx

try ? 

clear skip tail series -3

Neither INSERT nor APPEND modify the index attribute of their argument 
(the index attribute of series is immutable, in fact)

Having a series with index 1 (the head has this index), neither INSERT 
nor APPEND can change the index of the series. What they do is something 
else - they return a series with a different index.

To illustrate this further, let's consider a trivial example:

    a: 1
    b: 2

    add a b ; == 2


You can examine A and B now and see that the ADD function did not 
change A or B, but it returned 2 (another value). Similarly, INSERT 
does modify the argument series, but not its index, however it returns 
a series with a different index.

In Rebol, there is no "pointer" (C like).

string!, binary! are series. Series are groups of elements (character, 
octet) so a word! (like str or end) associated to a serie hold also 
a position on it.

end: find str "d"

==> search for "d" in the "abcdef" series in memory, then create 
a word! 'end that hold the position of "d" in this same serie.

Kees - beware - rebol series concept needs really carefull aproach 
- it caused me a headache when working with series, till I became 
accustomed to it. And still, sometimes, I use trial and error aproach 
in console ...

Kees - better start with a fresh session, fresh series ....

You may read the series page http://www.rebol.com/docs/core23/rebolcore-6.html

The key with series programming in Rebol is always "Is this the same 
serie or a new one ?"
Sometimes you want to act on the same.
sometimes you want to act on another.
FUNDAMENTAL

I fear that with the pull request as-is, even basic script execution 
is broken:
$ cat foo.r 
REBOL [] print 42
$ ./r3 foo.r 

** Script error: select does not allow integer! for its series argument
** Where: make either either -apply-
** Near: make system/standard/script [
    title: select first code '...

>>

Adrian, the actors are used to provide a series abstraction on ports. 
 But as developers I think it might be clearer to have specific methods. 
 Otherwise you're reading the options block to see exactly what is 
being done.

RANDOM help: "Pick a random value from a series" . The text looks 
a bit inaccurate to me. Wouldn't one of:

Randomly pick a value from a series

or

Pick a value from a series at random


For me, these reflect more accurately what is random. Any opinions?

I understand what Ladislav is saying.  The current text implies that 
there is a series of random values, and one will be picked.

Or it could mean that there is a series, and one of the values will 
be picked randomly.

What was wrong with the R2 text?

  "Return single value from series."


But the doc string for 'value isn't helpful with regard to series 
values either.

I would make it a bit more readable though.

  Return a single value from the series.

value -- Maximum value of result or series (modified when series)

Should have a comma:


value -- Maximum value of result, or series (modified when series)

Other than that, the two series are identical.

I like "Pick a value from a series at random" because the potential 
ambiguity would be whether any value is picked at all, which you 
could say always happens in some other docs if you feel it to be 
necessary to resolve the ambiguity.

Yeah, sorry, the fake typesets in R2 are actually blocks. The real 
typesets in R3 aren't series at all.

They are specialized bitsets, so specialized that they fit within 
a value slot rather than being an external structure. But JOIN forms 
non-series, so they are consistent with bitsets in that JOIN does 
the same thing with them.

well, I can imagine more scenarios, and it needs some thought to 
stay consistent between the cases. So my first thoughts, starting 
with the latest example:

for i 2 1 1 [prin "x"]


If above scenario means returning #none (and I agree with that), 
then I think that the for i 1 2 0 [print "x"] could be just the same. 
But - it might be related to the thoughts of the indexing. In REBOL 
series (if I am right), the position is in between the elements (not 
on the first element). So in that regards, skip 0 moves nowhere. 
But - it might also mean (as "first series" returns first element), 
that it should perform the loop just once. 


The last option for me is to cause an infinite loop, although from 
some point of view, it might make some sense too - you simply want 
to traverse the range, from 1 to 2, but you skip 0. If you would 
use just 'skip, you would cause an infinite loop. So - I really don't 
know ....

This is an excellent question Ladislav. What if we start with the 
doc string:

  R2: Repeats a block over a range of values.
  R3: Evaluate a block over a range of values.


That makes me think 'bump has to be non-zero, and it should throw 
an error. It should also throw an error (under R2) if 'start and 
'end are series values and won't terminate (e.g. empty series). R3 
does this now. That is, FOR should always terminate.


R2 allows char! values, R3 does not. Under R2 specifying an 'end 
of #"ÿ" (char 255) also results in an endless loop. My RANGE func 
tests for that, because it caused me a problem at one point.

I think that we have two conflicting values here:

* Do what I *say*, since you can't read my mind to know what I mean

* Trigger errors when you run into something almost definitely wrong 
as a favor to the developer


In the case of FOREACH, it triggers an error for an empty words block 
and doesn't allow none because that block is part of the control 
structure, not the data (which we do allow empty or none for). In 
the case of a block of only set-words, that also doesn't really advance, 
but at least you get a reference to the series so you could in theory 
be doing something (that you should probably use WHILE to do instead), 
so not triggering an error in that case is iffy, you could make an 
argument either way.


For FOR, the main factor for whether the loop would normally end 
(without BREAK or changing the index manually somehow) is whether 
the step > 0 if start < end, or step < 0 if start > end. So it's 
not whether it = 0.

On range!, my thinking is that the default would be a 'bump of 1 
(next value in a series), because that's how I think of iterating 
over a range of values.

Let's say that I have two series that are the same length, and the 
values at each position of each series are related to each other. 
 What if I want to use a 'for loop to increment through the first 
series, but in some cases, depending on the value of the first series, 
I want to skip x values ahead, and on other values, I want to access 
that same position in the second series and perform an action on 
it.  Why couldn't I use a 'for loop to do this if I wanted?

Bo: you could rely on FORALL and series positions instead of carrying 
numerical indexes around:

forall b [
    offset: either b/1 = pick s1 index? b [
        do something
        1
    ][
        do something2
        5
    ]
    b: skip b offset
]