AltME groups: search

Those were just tries. Any of the above logo is imo better than what 
Graham originally posted. But I am not satisified either. Here's 
my take, what needs to be considered for the logo to actually "work":


- you should define a brief - namely a description of qualities/characteristics 
of Red. What is Red, what sets it apart, what does it mean to you, 
what should it mean to ppl, what differentiates it from others, etc.


- type of logo - only letters? Letters plus pictogram? Shoul pictogram 
only decorate logo, or is part of the name? Pictograms are often 
related to the business, but I am not sure, if you are easily able 
to relate pictogram to "red", as it is a name of the color. Nor am 
I sure, if pictogram would express a programming language. What I 
would suggest, would be either - pictogram contains "R", which also 
works as a filetype icon. Or pictogram expresses some quality - e.g. 
>> (REBOL/Red prompt), [R] block as one of the main concepts (series)


- color scheme - not much options with something named Red, right? 
:-)


- usability - you should think about the color scheme, and logo in 
various forms - normal, inverse, black&white, icon, letterhead, business 
card, ppt presentation, etc. You can look for inspiration to how 
I aproached 2zone media logo with the agency - http://www.xidys.com/pekr/2zone_media_logotypes/

Pekr: I am finishing the generation of the intermediary representation 
for the output of Red compiler. I had to change it several times 
as it is uneasy to design properly without all the other pieces ready 
(another chicken and egg problem).


For example, to properly store literals (especially series literals), 
I need some kind of Redbin format, but designing it and implementing 
it now seems like a bit premature (as most types are not defined 
yet). So, I went for a dynamic construction model at run-time for 
now. I'll move literals to Redbin when it will be available.


For Redbin, I want it to be powerful enough to be able to serialize 
the whole state of a running Red program, but I don't know yet to 
what extent it is doable when running native code directly (needs 
some significant research work).


Also, I need to make a few changes to Red/System compiler to better 
integrate witht Red's one, I should finish those changes and release 
them this weekend.

Can you call all the series navigation actions on R3 ports?

You can make a port work a lot like a series, and you mostly did 
with the virtual block scheme. FOREACH and PARSE not working on ports 
can be a bit annoying, but they would only work on a subset of the 
port types that either work like series or (theoretically) like files 
(like open/direct file ports in R2).

Doc, no series in RED ?

If Red wouldn't have series and blocks, it wouldn't have much in 
common with REBOL. ;-)

Sorry Doc, I have made the wrong question: I don't see in the documentation 
block and series manipulation functions. Maybe I am looking at the 
wrong place ?

What I would welcome though is some series capabilities, even blocks, 
traversal, etc. Doc says, it will come via Red. The question is, 
for low level wrappers, if such concept would be usefull or not?

I believe that it will be possible to access all Red datatypes from 
Red/System via the Red Memory Manager (which is being built in Red/System). 
I doubt that Red/System will have any built-in functions to traverse 
and manipulate series though.

I don't think it is useful for Red/System, look at Kaj's bindings, 
its all system structures, API calls, enumerations and a few functions.

When we have Red we (or someone) can write wrappers in Red, so "normal" 
users will not need to use Red/System.

And there is no use series etc. kind of high level features in bindings/API/kernel 
calls.

No object! nor series! support planned for Red/System, remember that's 
supposed to be just a low-level dialect callable from Red meant for 
system programming. However, as Peter mentioned, it will be possible 
to access Red values and actions (mainly series and I/O actions) 
from Red/System when deeper interfacing with Red is needed.


OOP is just not necessary to Red/System, only code and data encapsulation 
is IMO worth adding in the form of a module system. I'm not a big 
fan of intensive use of OOP, as done in C++ or Java (or I'm probably 
just repelled by class-based OOP). I find prototype-based OOP (REBOL, 
Javascript,...) much more appealing and will support it in Red.

I thought about implementing some basic series functions in Red/System, 
but they would be primitive and hardly used once the Red memory manager 
is available. There could still be a place for them in low level 
coding, but right now it doesn't justify the effort for me

With the latest series of fixes, I've finally been able to move the 
SQLite binding into a CONTEXT

There are still a lot of details to work on, but the core part is 
there. The bootstrapping does had several complications (like literal 
series handling) that will vanish once we get Red compiler rewritten 
in Red.

There is a bit that is worth learning from R3's Unicode transition 
that would help Red.


First, make sure that strings are logically series of codepoints. 
Don't expose the internal structure of strings to code that uses 
them. Different underlying platforms do their Unicode APIs using 
different formats, so on different platforms you might need to implement 
strings differently. You don't want these differences affecting the 
Red code that uses these strings.


Don't have direct equivalence between binary! and string! - require 
conversion between them. No AS-STRING and AS-BINARY functions. Don't 
export the underlying binary data. If you do, the code that uses 
strings would come to depend on a particular underlying format, and 
would then break on platforms where the underlying format is different. 
Also, if you provide access to the underlying binary data to Red 
code, you have to assume that the format of that data can be corrupted 
at any moment, so you'll have to add a lot of verification code, 
and your compiler won't be able to get rid of it.


Work in codepoints, not characters. Unicode characters are complicated 
and can involve multiple codepoints, or not, but until you display 
it none of that matters.


R3 uses fixed-length encodings of strings internally in order to 
speed things up, but that can cause problems when running on underlying 
platforms that use variable-length encodings in their APIs, like 
Linux (UTF-8) and Windows/Java/.NET/OSX? (UTF-16). This makes sense 
for R3 because the underlying code is compiled, but the outer code 
is not, and there's no way to break that barrier. With Red the string 
API could be logical, with the optimizer making the distinction go 
away, so you might be able to get away with using variable-length 
encodings internally if that makes sense to you. Length and index 
would be slower, but there'd be less overhead when calling external 
API functions, so make the tradeoff that works best for you.

Red user code would only need to support the codepoint-series model; 
Red would translate that into the system's preferred underlying model. 
More encodings would need to be supported for conversion during I/O, 
of course, but not for API or internal use.

Be sure to not forget the difference between UTF-16 (variable-length 
encoding of all of Unicode) and UCS2 (fixed-length encoding of a 
subset of Unicode). Windows, Java and .NET support UTF-16 (barring 
the occasional buggy code that assumes fixed-length encoding). R3's 
current underlying implementation is UCS2, with its character set 
limitations, but its logical model is codepoint-series.

Nice features of the new macro support: 


- the replacement in the argument block operates for any block series 
(includes paths types)

- nested macros in macros are resolved


- you can define the argument as paren! instead of block!, and paren! 
will then stay once macro resolved.

Next: char! and all series actions already present in block! implemented 
for string!

So, if all goes well, you'll have the full REBOL model + optimizations. 
There are many ways to optimize and on many different abstraction 
levels. Yet, some atomic operations will remain "unoptimized", like 
series atomic manipulations (maybe we'll figure out a way to optimize 
them too in the future).

Also, the literals series construction is taking much more space 
than it should. The boot.red script is precompiled and stored as 
code in all binaries, we should rather keep it in compressed source 
form or, even better, in redbin format. But currently, precompilation 
is the only option we have.

If you have support for unboxed intermediate values or unboxed series 
types (like vector) then you can make sure you can do IPv6 types 
that way too.

The issue! type was changed from a string-like type in R2 to a word-like 
type in R3, but the R3 behavior isn't completely final. It will continue 
to be a word-like type, but the syntax might get some tweaking and 
some string-like operations might be added back where possible, perhaps 
in a similar way to how tuples are series/like at times but actually 
immutable.

In such case, you should not use FOREACH, but an alternative. FOREACH 
doesn't handle a series offset, so you can't test for a position 
in the series.

Jerry: here is a quick overview:


Red values are stored contiguously in series slots (128-bit cells). 
Series buffers are allocated from large chunks of memory of type 
series-frame!. Series value in slots store just a head offset and 
a pointer to a node!. The node! is another pointer to the series 
buffer. So series buffer are indirectly accessed, allowing them to 
be moved in memory (for reallocating with bigger/smaller size or 
moved by GC).

A series buffer has header, with OFFSET and TAIL pointers that define 
respectively the begin and end of series slots. The OFFSET pointer 
allow to reserve space at head of the series for optimizing insertions 
at head. Series slots size can be 1 (binary/UTF-8/Latin-1), 2 (UCS-2), 
4 (UCS-4) or 16 (value!) bytes wide.

From ~Links group: "Could Red eventually become a contender for #6? 
 How strong will support for parallel processing be, eventually, 
in Red?"


#6: yes, that is one of the goals I want to achieve with Red. For 
parallel processing, the model I have in mind is the "parallel collections" 
from Scala. This means that when you are looping over a series, Red 
should be able to parallelize the loop code over n (CPU and/or GPGPU) 
cores at the cost for the user of only a change of the loop function 
name (in Scala, they use a "par." prefix for such functions). This 
requires that the compiler do a deep static analysis of the loop 
body to determine if it can be parallelized (e.g. iterations not 
dependent on results from previous ones). Now, if you also add SIMD 
support in the equation to leverage intra-core parallelism, you get 
a good picture of what I want to achieve. ;-)


So, I think a semi-assisted parallelization/vectorization of loops 
in Red is doable. To what extent and which final efficiency, I'm 
not sure before we build some prototypes.

Path notation preliminary support added: you can use it on any series 
with integer! or get-word! values as accessors (nested word! values 
need SELECT action to be implemented first).


See changes in demo script: https://github.com/dockimbel/Red/commit/88fd1ff1da855a383e91566903fe373ea4d41eca

Set-path notation support for modifying series added.

Should Red/System series be one-based? There are some discussion 
on it. Why not set a #pragma for it, so programmers can set it themselves?

As for R3, it did not really introduce "0-based convention implicitly", 
it still is firmly "1-based" in as far as the first element in a 
series can be accessed using index 1.


When you want indices-as-ordinals, you really need to decide: (a) 
is the ordinal "zeroth" meaningful, and if so, what it means; (b) 
are negative indices meaningful, and if so, what they mean.


R3 went with the choices of (a) having meaningful zeroth, defined 
as "the item in a series before the first item", and (b) allowing 
negative indices, having index -1 as the immediate predecessor of 
index 0.


R2 went with the choice of (a) not having a meaningful zeroth, but 
instead of erroring out, functions (pick) & syntax (paths) accepting 
indices are lenient: passing an index of 0 always returns NONE. For 
(b), R2 allows negative indices and defines -1 as the immediate predecessor 
of 1.

Andreas: thanks for the good sum up.


R3: agreed that index 1 is still the first element in a series, but 
index 0 is allowed and there is this ticket #613 that clearly aims 
at introducing 0-based indexing in R3...so my guessing was these 
different changes or wishes were inter-related. http://curecode.org/rebol3/ticket.rsp?id=613


R2: I would have really prefered that index 0 raises an error than 
returning none.

If you wish to allow index computation for series not positioned 
at the head, allowing index 0 is actually quite sensible, unless 
you want to make index computation particularly error prone.

The problem with no meaningful index 0 is that potentially meaningful 
index values are no longer isomorphic to integers. And as REBOL has 
no actual datatype for indices, all we can compute with are integers 
while relying on a correspondence of those integers to indices.


If you only ever compute indices for series positioned at the head, 
you get a nice correspondence of integers to indices, because meaningful 
indices for this series correspond to the positive integers.


But if you also want to compute indices for series positioned elsewhere, 
this nice integer-to-index correspondence breaks down as you suddenly 
have an undefined "gap" for the integer 0, whereas negative integers 
and positive integers are fine.

Andreas: do you have a short code example involving index 0 in computation? 
I don't remember ever having issues with index 0 and I use series 
with offsets a lot! Though, Ladislav claims he and Carl did encounter 
such issue at least once...the use cases for this issues remain a 
mystery well kept by Ladislav. ;-)

I personally avoid computing with non-head positioned series wherever 
possible.

That is caused by the fact that there is no gap in the series, the 
gap is only caused by "unreasonable thinking".

Yes, I can in this case: "unreasonable thinking" here is the fact 
that the "mathematical model" - in this case the numbering of positions 
in series differs substantially from the properties of the object 
it is modelling - in this case there is a difference between the 
"no-gap in the series" versus "gap in the mathematical model".

SKIP works with offsets only, it's not related to indexing.

 - that is not true, in fact. It *is* related to indexing, since we 
 may always use PICK SKIP SERIES N M versus PICK SERIES K and these 
 things are realted, like ir or not.

 in this case the numbering of positions in series differs substantially 
 from the properties of the object it is modelling


Is this again the "inbetween position" vs values counting intepretation 
difference?

It is because the series values actually are a contiguous concept, 
but their respective indices are not a contiguous space of integers.

Numbering positions in a series is, in other words, characterized 
as "mathematically modelling 'positions' in a series". Your "inbetween 
positions" are something that does not exist in the series in fact.

Tail position is inbetween - actually not. You can write: INSERT 
TAIL SERIES #"a". You do not insert the character "inbetween", in 
fact.

tail position

 is actually a misnomer, in as far as it corresponds to no proper 
 index of a series. The special behaviour series seen in some functions 
 when operating on series in "tail position" would warrant "tail mode" 
 as a more sensible description of the state the series is in.

as it corresponds to no proper index of a series

 - I reserve the right to disagree. INDEX? TAIL gives some correspondence

Yes, it gives an index that can I'd consider "improper" for the series, 
in as far as the series does not contain a value at that position.

Subjective interpretations of series tail position are possible, 
as TAIL position exists without pointing to any value.

(And an index that does not correspond to a value in the series, 
at this point in time.)

http://www.rebol.com/r3/docs/concepts/series-traversing.html


The first position of the block is called its head. This is the position 
occupied by the word red. The last position of the block is called 
its tail. This is the position immediately after the last word in 
the block. If you were to draw a diagram of the block, it would look 
like this: [...] Notice that the tail is just past the end of the 
block.

Too bad the images are missing...

also, yet another inconsistency (PICK help string):

Returns the value at the specified position in a series.

In the light of these, taking the INDEX? help string we may actually 
say that the formulation:

Returns the index number of the current position in the series.

is actually indefinite, not determining anything at all

My thought behind the "tail position" complaint above was, that series, 
position, and index are already used rather exchangably, and lax 
in a few parts of REBOL's documentation. Adding "tail position" to 
the mix, only further contributes to that confusion.

If you realize that indices are one degree vectors.   A lot of this 
discussion becomes moot.   vectors of length 0 are considered impossible 
when considering only natural numbers (due to 0 divide).  This is 
why I consider R2's handling of indices proper.   


As such, any series "position" is not AT a value it is LOOKING AT 
a value (oriented in positive direction, starting at a point in space 
which is "0").   like extending your arm to grasp the nth thing in 
front of you.  


Tail are 0 length vectors (thus mathematically imposible), when we 
are beyond  the last item edge we are at the edge of space.   you 
cannot "take" the tail item, there is nothin in front of you, just 
as you cannot "take" the 0th item, there is no such thing, 0 is the 
origin of the vector).


when we consider series indices to be vectors, we see the natural 
relationship which Ladislav pointed with SKIP and other methods.


with vectors, things like COPY/PART make sense in the negative direction, 
just as well as in the positive direction.



In R3, this was changed to indices being OVER a value , with the 
first item requiring you to look down and then away for other values. 
 The issue is that index 0 is looking backwards... that doesn' map 
to any good reasoning.  In fact it creates many weird inconsitencies 
in the model, when you try to describe it.


R3's series changes seem like a kludge work-around to map non-vectorial 
infinite integer space to a bounded vectorial space. sacrificing 
model integrity in the process (while trying to ease its mathematical 
properties).  R3's series *may* be "easier to count in a loop"  but 
the values being used make no sense.   counting backwards requires 
us to manipulate the indice for it to "make sense", whereas before, 
counting backwards was the same as counting forward.  we where just 
LOOKING in the opposite direction (the vector's orientation is inversed).

I am still sure that once we have negative numbers, we cannot do 
without zero (to maintain compatibility with the continuity of the 
underlying series). Then, actually, the SKIP behaviour is the only 
one easy to describe and use as the base of the "nomenclature".

Anyway.. reading this discussion, I'm feeling like deja vu... I would 
stay with REBOL way of indexing. Although I don't have any problem 
to switch into 0-based indexing in other languages. The problem is, 
that the other languages don't have functions like next, back, tail.. 
which enable series traversing, do they?

From R3-alpha world:

Carl:	It is zero based for math computation reasons. If you think 
that is wrong, we should discuss it and correct it soon.	11-Oct-2007 
6:03:15 PM

Carl:	Rest of REBOL is one based for this reason: first = pick series 
1	11-Oct-2007 6:03:33 PM

Carl:	The solution we discussed, but have not yet implemented (but 
it is easy to do) is to add a PICKZ (or PICK0) function.	11-Oct-2007 
6:05:41 PM

BrianH	: Those math computation reasons are why I prefer zero based. 
I tend to use SKIP instead of AT for the same reason.	11-Oct-2007 
6:06:09 PM

BrianH	: Please add PICKZ and POKEZ - I liked them in rebcode.	11-Oct-2007 
6:06:46 PM

Negative indexes applied from tail of series could be a good option, 
that would help replace the `back tail series` idiom.

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

PICK0 or PICK-0 might do. Definitely not ELECT, since the kind of 
selection that is done in elections is not related to the type done 
when you "pick" something. In US English there is a colloquial term 
"pick out of a lineup", which relates to series in a way that noone 
would think of the term "elect" (unless they are convinced that all 
politicians are crooks). PICK and POKE are from Basic, old-school 
tech terms that are more closely related to assembly instructions 
than they are to any high-level operation.

Re: python and negative indices... python does not have series positions, 
so they can afford doing that. a REBOL-like language simply can't. 
it's much simpler to just write "pick tail series -2" for eg.


perhaps one other way to look at this problem is to only have positive 
indices, and have REVERSE (or similar) return a value that is not 
a copy or modification of the series, but simply lets you look backwards.

the most sane way to make a decision here is to come up with use 
cases, probably. then we can intuitively see what is wrong.

The problem with R2 can be easily seen with:

>> b: skip [1 2 3 4 5 6 7 8 9] 4
== [5 6 7 8 9]
>> for i -4 5 1 [print [i pick b i]]
-4 1
-3 2
-2 3
-1 4
0 none
1 5
2 6
3 7
4 8
5 9


Now, you could also say that you should never iterate over a series 
using indices. But, then why have PICK at all?

I can tell you why I don't like the idea of continuing from the back 
of the series.

Most data is not in a cyclic group, it is finite so definitely at 
the beginning you do not expect it to continue from the tail.

You do not necessarily have to iterate over the series. I look up 
some values in a table and retrieve or store data at that index of 
a series.

But than again I use subscripting b/(i) over 'pick, maybe I must 
go back to REBOL School  ;-)

the most sane way to make a decision here is to come up with use 
cases,


I can't agree more. What I am wondering is: have rebolers ever hit 
that specific issue (0 gap producing a calculation error) at least 
once? My feeling is that it is an extremely rare error case (but 
a nasty one) that could have been mitigated by just making PICK raise 
an error on 0.


Now, you could also say that you should never iterate over a series 
using indices. But, then why have PICK at all?


Right, IMHO, you shouldn't iterate over a series using indices, unless 
you have a good reason for it. In the general case, people should 
use "navigational" functions to walk through a series. PICK is ok 
as long as you don't PICK on 0.

perhaps one other way to look at this problem is to only have positive 
indices, and have REVERSE (or similar) return a value that is not 
a copy or modification of the series, but simply lets you look backwards.


At first look, the implementation overhead wouldn't be high for supporting 
such feature and that could solve our PICK issue, elegantly I think. 
My only interrogation about it would be: will we be able to easily 
reason about such "reversed" view of series once mixed with "normal" 
series in the middle of our code or would it confuse many people?


Anyway, I think this one should be in the short-list of the possible 
solutions.

I.e., you'd hardly ever actually write PICK series 1, you'd use FIRST 
instead.

We have FIRST, SECOND, THIRD to pick forward; but we have no dual 
set of functions to pick backwards. Therefore we fall back to crutches 
such as "PICK series -1".

Don't forget also path notation: `series/-1`.

Maybe, but we still have the 0 index issue, `series/0`giving you 
access to item before current series position is IMO highly confusing.

Pekr, the reason it works for Python is because their series are 
always referenced from the start, so negative indices/offsets would 
otherwise have no meaning. REBOL has offset references to series, 
so negative indices/offsets already have a meaning for us.

Still the fact that `pick series 1` gives you the first item from 
current series position, makes the 0 position awkward.

I use computed indexes for computed lookup lists, such as for precomputed 
intermediate results of computations, translation tables, etc. If 
the computation uses signed numbers, you have to do an offset base 
position to get the results from the positions less than 1. Having 
a hole slows down the computation because it has to be handled in 
mezzanine code. PICKZ/POKEZ would actually be better for most of 
these situations because the computations work better with 0-based 
numbers (modulus, for instance). It's pretty common in code that 
actually *needs* to use PICK/POKE on series.

I've found that aside from computed indexes, the only times I use 
PICK/POKE on series are for negative/0 indexes, or indexes greater 
than 10. For the rest the ordinal functions are faster.

It's pretty common in code that actually *needs* to use PICK/POKE 
on series.


That's the sticking point. We can categorise the uses for PICK/POKE:

(a) with large positive literals
(b) with literals -1, -2
(c) with computed indices and series in "head position"
(d) with computed indices and an offset series

Yup. But that doesn't mean that I can switch to unsigned arithmetic. 
For that matter, sometimes switching to unsigned arithmetic means 
mostly indices at the top and bottom of a large range, skipping the 
middle (basically what you'd have to do with the Python model). By 
"large" I mean allocating a 2GB series or more and only using the 
100MB or so at both ends. Not always a good idea.

Series and structs aren't marshaled yet; they're just passed as address 
integers

Thanks, when I did the trick in my Java applet I had never expected 
to use XOR at all ever. In Java I had an field of 10by10. I'll explain 
a little. Starting top left having an initial direction south start 
on the first field of the grid. determine the next direction to go 
then step and repeat until you step of the board stap=step r row, 
k for column (kolom) so stapr or stapk will be 0 or 9. then you are 
on the other end of the board. the values along the board is a series 
of 32 elements going clockwise around the board. Go to the next field 
clockwise when right your init direction is west etc.

Looks like the Head First series: http://www.headfirstlabs.com/books/hfprog/

(Replying to AdrianS in Announce) R3's extension mechanism is designed 
to make it more possible to make and compile extensions that will 
continue to work even when R3 is updated. Even with the source open, 
that is still a value. The command dispatch model is also really 
useful for implementing native dialects and JIT compilers. The marshalling 
mechanism is also reasonably fast by FFI standards. It could, however, 
use better marshallers for series, and more datatype coverage.

Yet another task I think REBOL could help me with. Say I could not 
find the subtitles for an ancient tv-series i stumbled upon on the 
net. But I found subtitles in English. I can translate but some words 
will reoccur often, so I imagine a rebol script showing an original 
line or words to be translated. I type some translations and when 
I translate a word, all equal words in the rest of the document will 
change, saving me quite some time.

Guiseppe: "Could it be written as: ..."
TO ANY doesn't work.
but ANY [TO "..." BREAK | TO "..." BREAK] works.

just be careful using ANY and TO together, because they both don't 
advance the series pointer. So you can easily put the console in 
an infinit loop (escape key also doesn't work)

i have a block of objects:
each object is constructed like...
  c: #object! [
    name: "wonderwoman"
    attribs: [
      Y1991: #object! [ a: 1 n: 2]
      Y1992: #object! [ a: 1 n: 2]
    ]
  ]

i need to sort the series based on fields of the attribs inner object
i dont want to create a new series...any ideas?

>> help sort
USAGE:

    SORT series /case /skip size /compare comparator /part length /all 
    /reverse


DESCRIPTION:
     Sorts a series.
     SORT is an action value.

ARGUMENTS:
     series -- (Type: series port)

REFINEMENTS:
     /case -- Case sensitive sort.
     /skip -- Treat the series as records of fixed size.
         size -- Size of each record. (Type: integer)
     /compare -- Comparator offset, block or function.
         comparator -- (Type: integer block function)
     /part -- Sort only part of a series.
         length -- Length of series to sort. (Type: integer)
     /all -- Compare all fields
     /reverse -- Reverse sort order

hi maxim!

thanks - saw that in the docs, and also saw brett;s sort-object-series 
function on the mailing list
not quite sure how it works with an inner object though

this works great for fields in a simple object series:
sort-object-series: func [
  series
  field
] [

  sort/compare series func[a b][lesser? get in a field get in b field]
]

sort/compare series :sf

sort/compare/skip series :sf 2
??

so it would be:
sort/compare/skip/index series :sf 2 2

s is a sorted series, p is a decimal from 0.0 to 1.0

Depends on how you intend to use it. If you declare a series without 
COPY or MAKE, it references the data in what you usually think of 
as your source code

Hi looking for a better REBOL way to do the next thing: a: [ 1 2 
3 4 5 6 ] I have 1 of the values in this series and  want to do a 
foreach/forall on the series left of this value from right to left 
and also a foreach on the series on the right of this value but now 
from left to right. So say I chose 3 for the value then I need [ 
2 1 ] and [ 4 5 6 7 ]. This is my solution b: reverse copy/part a 
find a 3 and c: reverse copy/part a find reverse a 3 but now >> a
== [6 5 4 3 2 1]

And I don't want that and I don't like undoing the reverse each time. 
Do I need a temp for reverse a because c: reverse copy/part a find/last 
reverse copy a 3
** Script Error: Invalid /part count: 3 2 1
?

Thanks Sunanda for this option. One extra tricky thing is the length 
of the series varies and I feel I am doing to much bookkeeping myself 
already.

yes, Arnold, be very careful with reverse... if you are part/way 
it will only reverse part of the series.

Arnold, what you want to use is FORSKIP. It's like FOR, but with 
series references instead of numbers. No modifying REVERSE required.

Here's a R2 solution with same rules for string! and block! series:

rle: func [s [series!] /local out c i][
    out: make block! 1

    parse/case/all s [
        any [
            [end | c: (
                c: either word? c/1 [to-lit-word c/1][c/1]
                i: 1
            )]
           skip
           some [
               c (i: i + 1)
               | (repend out [i c]) break
           ]
       ]
    ]
    out
]

>> rle "aaabbcx"
== [3 #"a" 2 #"b" 1 #"c" 1 #"x"]

>> rle [a a a a a]
== [5 a]

>> rle [a a a a a b b]
== [5 a 2 b]

>> rle [a a A b b c d D d d d]
== [3 a 2 b 1 c 5 d]

Endo: you should rather bench on one long series rather than 1M times 
on a small one in order to avoid function calls overhead and get 
a more fair comparison. When I try with a 1M size string with random 
a,b,c chars, my parse solution is twice faster than the mezz one 
(Brian's one is crashing so can't test it). I was expecting a greater 
difference though.

providing an optional output buffer  (which the user can pre-allocate 
to some ideal size)  would make a VERY big difference on large inputs.


usually, when it goes into the hundreds of thousands, repetitive 
series re-allocation on growing mutable series,  will kill any kind 
of optimisation you can dream of. 


rle: func [s [series!]   /into out  [block!]  /local out emit pos1 
pos2 cont][
	out: any [ out     make block! 2 ]
 ...
]


this is especially effective on repetitive calls to the above function 
and using clear on the given buffer so that it auto-grows to an optimal 
size and is fast on later calls.


just today, I was doing some encryption benchmarking and when I hit 
strings larger than 1MB it was taking several minutes... thats until 
I realized that it was my dataset generator (a looped string insert) 
which was taking 98% of the cpu time.  !

Here's a version of my last one above, but with Steeve's trick adapted 
to make a /compare option. It defaults to its old case-sensitive 
behavior.

rle: func [
	"Run length encode to series of [length value]"
	s [series!] "The series to encode"

 /into {Insert into a buffer instead (returns position after insert)}
	output [any-block!] "The output buffer (modified)"
	/compare "Comparator function for equvilance"
	comparator [any-function!]
	/local x r qr b e
] [
	unless into [output: make block! 2] x: none
	r: case [
		compare [[any [e: if (apply :comparator [:x :e/1]) skip]]]
		any-string? :s [[any x]]
		'else [qr: copy [quote 1] [(poke qr 2 :x) any qr]
	]
	parse/case :s [any [b: set x skip r e: (
		output: reduce/into [offset? :b :e :x] :output
	)]]
	either into [:output] [head :output]
]

Whoops, forgot a bracket:

rle: func [
	"Run length encode to series of [length value]"
	s [series!] "The series to encode"

 /into {Insert into a buffer instead (returns position after insert)}
	output [any-block!] "The output buffer (modified)"
	/compare "Comparator function for equvilance"
	comparator [any-function!]
	/local x r qr b e
] [
	unless into [output: make block! 2] x: none
	r: case [
		compare [[any [e: if (apply :comparator [:x :e/1]) skip]]]
		any-string? :s [[any x]]
		'else [qr: copy [quote 1] [(poke qr 2 :x) any qr]]
	]
	parse/case :s [any [b: set x skip r e: (
		output: reduce/into [offset? :b :e :x] :output
	)]]
	either into [:output] [head :output]
]

(which is why they look like static variables in terms of series 
which are references)