AltME groups: search

I don't think there will be better. And it was used in rebcode.

as far as I am concerned I would not need ELECT3 and above, but up 
to ELECT2 they look nice to have.

Counter part DOWNPOKE and you only need to steggle (twist) idf it 
should be downpick 1 or downpick -1 ;)

the problem with DOWNPICK, REPICK, and some others is that they aren't 
related to the purpose of the function in any explainable way

Ladislav: are you advocating for having two conventions, both 1-based 
and 0-based?

Make sure that the names of PICKZ and POKEZ are immediately relatable 
to PICK and POKE, the way that FUNCTION, FUNC and FUNCT are related.

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.

You wouldn't need to implement PICKZ and POKEZ as actions. Just implement 
them as regular functions that call PICK and POKE, like the ordinal 
functions are in R3.

In Red, there isn't that much difference. But in R3, natives are 
more like regular functions than they are like actions or ops. The 
implementation language is different, but the dispatch model is very 
similar. On the other hand, the dispatch models for actions and ops 
are very different from regular natives.

Ladislav, what about ADDRESS in place of ELECT?  Fan of DEPOSIT. 
 Umm, adding I actually prefer one based indexing and lean toward 
it.

It's been too long for me to remember the discuission for R3, but 
I think I ended up liking the *Z convention, because it's easy to 
understand. ELECT and BASIS? don't make immediate sense to me.

IMHO adding both zero and one-based selection will only confuse.

right - POKEZ and PICKZ are for nerds anyway, so - who cares about 
the names? :-)

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.

And a PICK/BACK refinement is also not an option?

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  ;-)

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 think that what we are seeing here is the frontier between academic 
and practical design choices. I am all for following academic principles 
as long as they are not "too" detrimental to practical usage. I would 
draw the line at the point where most users would get lost. I believe 
that this is a dangerous pitfall in language design if you aim at 
a widespread use.

I'm pretty sure I prefere R2's behaviour. Also "pick 0" I could translate 
like "pick nothing" so returning none is fine in my mind. And I mostly 
use just R2 and I don't remember I had ever any problems with this.

Path notation is somewhat rarely used with negative indices (and 
probably even rarer with computed components, which I think were 
only added as late as R2.6).

I did some investigation over the rebol.org library and a few other 
available R2 apps a while back, I think it's basically always /-1 
and /-2 for negative path indices.

0th is not that unnatural. I looked into an English dictionary yesterday, 
and actually found it defined as "the item before the first".

Yes, as I said: almost always /-1 and /-2.

(And could keep R3's behaviour for computed indices.)

I bet most readers here and R3 users will find it confusing. See 
my above `pick at values 2 0` example.

You can basically do:
- no 0 or negative indices at all

- disallow 0, have 1 return the next element forward, -1 the next 
element backward (R2)

- disallow 0, have 1 return the current element forward, -1 the current 
element backward

- allow 0, have 1 return the next element forward, 0 return the element 
before that


All have their advantages and disadvantages. All require explaining 
and may not be obvious depending on what you expect.

Yes, but that's not how my brain see it by default, I need to make 
a conscious effort for that. Also, I might be tempted to then use 
0 to access the first item instead of 1...This is a pitfall where 
almost every new (and maybe some older too) will fall in.

If we do R2's behavior, make sure that PICKZ and POKEZ exist so I 
have something to use. They can call PICK and POKE internally. I 
need something that does computed indexes/offsets, and I can't afford 
to have a hole in the list (0 for R2), and I can't count on the port 
scheme supporting SKIP.

Just erroring out on index 0 is ann improvement.

Making "pick 1" and "pick -1" return the same element is an improvement.
R3's behaviour is an improvement.

R2's messy behaviour with a clean set of SKIP, PICKZ, POKEZ is an 
improvement.

and I can't afford to have a hole in the list

 Brian, could you give us some short code cases where this was a problem 
 for you? This would really help.

Error out and add PICKZ, POKEZ while at it. That would at least give 
us a base to work with.

I wouldn't even mind if PICKZ/POKEZ were the actions and PICK/POKE 
were the native wrapper functions. Not as pretty for port scheme 
implementors though.

Brian: in `pick ser idx + off`, how often do you need `idx + off` 
to give you both positive and negative results from the same expression?

We should write a short-list of possible options that would solve 
the whole issue and see if we can get a large consensus on one of 
them. Anyone kind enough to extract the different options we've discussed 
and put them somewhere online with the main pros/cons?

Of course port schemes and datatypes actually need to implement PICK/POKE, 
but at least for datatypes the implementation is usually native so 
the hole is less expensive to implement.

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

I think it's more common to rewrite the code to something different, 
where possible, than to try and workaround the 0 gap.

Anyone who does computed indices from offset base positions would 
run into that issue. However, given that this only tends to happen 
in heavy-math code, I wouldn't be surprised if Ladislav and I would 
be caught by it more often than anyone else in the REBOL community, 
even Carl.

I'm pretty sure I ran across this problem when trying to implement 
a triple store ages ago (and ended up switching to a different implementation 
approach).

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.

In that case, it would help if PICKZ/POKEZ were the actions because 
they don't have the 0 hole, and we can add PICK/POKE optimizations 
that apply an algebraic transformation to change the call to PICKZ/POKEZ. 
Implementing the hole in the action has overhead that the optimizer 
wouldn't be able to undo. It would be able to undo the hole implementation 
in a wrapper function though by inlining the code then optimizing 
it away. That would make up for the problems caused by putting the 
0 hole in there in the first place.

Most computed index situations use modulus, which generates 0-based 
numbers. If there's no 0 hole in PICK/POKE then you can do PICK/POKE 
NEXT, as long as this doesn't have side effects the way it does for 
port schemes or weird copy-on-write stuff; in that case PICKZ/POKEZ 
would be more of a convenience. If there's a 0 hole in PICK/POKE, 
you absolutely need a version of the functions without that hole, 
and having the extra advantage of being 0-based would be even better, 
an extra justification for their existence.

(sorry, there's two standard ways to pluralize index and I don't 
use either consistently)

- "the most sane way to make a decision here is to come up with use 
cases": +1
- We are unlikely reach consensus: +1
- Have I ever been bitten by R2's behavior? No.


Great discussion on this. I greatly appreciate Andreas's points about 
common (-1, -2) cases, and his gist example. I'm good with throwing 
an error where silent incorrect processing would be worse. The concrete 
examples will be the best way to drive this, IMO. By concrete, I 
mean real-world, "this is code I actually wrote to solve a problem" 
stuff. If you can't post code for legal reasons, a generalized adaptation 
is almost as good. Make the most common uses behave correctly, even 
if there are cases they don't handle, and show how the other cases 
*can* be handled, even if it means slower mezz code. Then see if 
there's a better way to support them.

Why not have a special function to handle the 0 gap problem? The 
rest of the world can use the normal 'pick and 'poke and if you need 
the special ones they are available and behave as expected in those 
cases.

I thought they only did the negative and zero index.

Jerry: I don't have enough time for that, I am counting on the doc-strings 
and extraction tool to generate such documentation automatically. 
Peter is working on such tool.

I think that what we are seeing here is the frontier between academic 
and practical design choices. I am all for following academic principles 
as long as they are not 

too" detrimental to practical usage. I would draw the line at the 
point where most users would get lost. I believe that this is a dangerous 
pitfall in language design if you aim at a widespread use."

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.

And if you implement an index! type, you can make 1 be preceded by 
-1

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.

We can do Roman indexes if need be. It's really bad for math, so 
we would need PICKZ and POKEZ if we want to do computed offsets (SKIP 
can have side effects with ports in cases where PICK/POKE don't necessarily 
have, but regardless it has overhead). Maybe Roman PICK/POKE will 
be easier for newbies to learn, though they may curse it later once 
they have to do anything hard. (Note: Roman in mathematical difficulty, 
not notation.)

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.

why 1 would be a better starting index than zero? Why not 2, or 10? 
The answer itself is interesting because it shows a lot about the 
though process of the people defending the idea.

 - what an flawed argument - the guy completly missess language as 
 REBOL imo, where we have first, second, etc. And first simply returns 
 first real thing. What is zeroth thing?

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 ...

I am not sure REBOL introduced the easy model - it is mixture of 
those real existing values, and virtual elements:

blk: [a b c]
index? head blk == 1
index? tail blk == 4


I can imagine tail simply pointing to the last element, as well as 
head pointng to the "zeroth" element. But then, if we would not think 
about "in-between" positions, how would insert behave? If I would 
once agin think about the real example with e.g. 3 ppl standing in 
the line, and I say - go, and insert yourself to the last position 
- does it mean new person is going to be third, and shifts the last 
one to the fourth position, or does it mean the person just adds 
himself/herself to the fourth position?

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

Completely agreed 0 does not exist, even not for computers. A computer 
with 0 memory does not have memory at address 0 either :)

Counting starting at 0 is nonsense. No matter who and how many times 
it is explained. In human/fysic world we only put letter 1 in envelope 
1, letter 2 in envelope 2 etcetera, there is no letter 0 to put into 
envelope 0. It is only a confusing trick to start at 0. (I know you 
can look at memory like a binary tree) In these days of plenty of 
memory, I say let location 0 unused. Besides for who was REBOL meant 
initially? People. Scientists not computerscientists. Let those struggle 
with C and the likes. 1-base is one of the big plusses REBOL has 
over the majority of other languages. (enough bikeshedding from me 
today)

Yet those ppl use arguments, like even in Bibble, there was zeroth 
day (well, in physics, that might mean the singularity point, where 
our physic laws don't apply), or, that without 0 you are not able 
to count BC to nowadays difference properly. Whoever came with that 
BC AD distinction, was not sane at the first place, and I really 
doubt, that back at those times, they agreed that their age is some 
-2300 years, knowing the point 0 (Christ) ahead :-)

Please move the discussion whether "0 exists" elsewhere. REBOL's 
integer! corresponds to integers and includes 0. Unless you want 
to change that as well, that's a fact we have to live with.

One very important point is, I think, that this discussion is not 
necessarily about 0-based vs 1-based.


It is more about if and how to map the concept of ordinals to the 
concept of integers. If you choose to use indices-as-ordinals ("1-based 
indices"), those two questions collapse to one. If you choose to 
use indices-as-offsets ("0-based indices"), the question of how to 
handle ordinals _still remains_.

One reason I posted the Pascal example was due to the earlier discussion 
about  ordinals not including zero. In Pascal, integer are considered 
an ordinal type and include zero. Now the Pascal definition of ordinal 
may not be absolutely correct in mathematical terms but I would suggest 
it is pragmatic to support reasonable behaviour for indexing.

I don't see quite the same distinction as you between indices-as-ordinals 
and indices-as-offsets except in terms of implementation where the 
former requires additional steps in the calculation compared with 
the latterr. (Though as you say this is not the issue).

So would two sets of functions, one providing absolute addressing 
and the other providing relative addressing solve the issue?

And `pick ser 0`, yes.

Ada and VHDL/Verilog are two other languages that spring to mind, 
which allow choosing the index range, like Pascal.

Is it true to say that whilst there is no effective difference (in 
logical terms) between 0-based and 1-based absolute indexing, there 
is a difference when it comes to relative indexing,

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?

Part of the reason why I keep highlighting the ordinals aspect is 
that I think this is part of what many people really like about current 
R2 behaviour, and many fear to lose.


FIRST is convenient and nice, and having path notation for "first-to-right", 
"first-to-left" is nice as well.

With that background, I still think adding an ordinal! type is a 
nice solution. Here's the basic proposition:


1. introduce an ordinal! type, with literals: -3rd, -2nd, -1st, 1st, 
2nd, 3rd


2. extend PICK and POKE (and paths) to accept integer! and ordinal!

3. have SKIP only accept integer!, AT only accept ordinal!

4. define FIRST, SECOND, THIRD, etc as PICK 1st, etc

4a. maybe add dual FIRST-BACK (or use a /BACK refinement)


That in place, you keep all the nice "human-friendly" features of 
current R2, at the only expense of sometimes having to type 2 extra 
characters.

I still fail to see a real-world use-case where you need both negative 
and positive indexes at the same time (in other words, compute indexes 
*over* current position). Even in such rare case, you can still do 
the computation using INDEX? SKIP values (so switching to absolute 
indexes instead of relative ones).

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.

And basically, adding /< syntax would most likely add just another 
datatype :)

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.

Whereas s/2 could be conceived as shorthand for `first next s`. And 
there you already get a glimpse at the problem:

- s/2 is first next s, s/-2 is first back back -- why is there 1 
next but 2 backs?
- what is s/0?

Concept 2 is a 0 based sequence which is traversed via index manipulation.

That interpretation doesn't match `FIRST s` and `PICK s 1`...

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]

In an index system if you want box 4 you say s[4] - or if your current 
index is at 1 and you want box 4 you say s[i + 3]

Andreas - the problem I have with ordinals is how do you do mathematics 
on them eg. 3 + -3rd ? Index manipulation uses ingteger! and so is 
mathematically modifiable

Anyway - good luck Doc on sorting this one out - and thanks again 
for doing Red it is very exciting

One possibility. Another would be to have ordinals purely as syntactic 
convenience, and not allow arithmetics with them.

Ok - thanks for the clarification Andreas - that makes sense now. 
I think maths usage would be essential for use cases such as the 
one Brian put forward - he mentioned at least addition and modulo.

Agreed, "not usable" is a little harse. Bad and awkward, but once 
you work around that it is usable.

You actually have that you have to work around it, otherwise R2 will 
bite you hard (and silently).

You actually have that you have to work around it, otherwise R2 will 
bite you hard (and silently).

 - yes, "you have to work around it" is (for me) a different formulation 
 equivalent to "not working"

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

...and also for people stating that "index arithmetic *is* working 
in R2"

Note that the difference between 1c) and 1b) seems to demonstrate 
why 0-based indexing may be found more convenient than 1-based indexing

Yes, and that's what Andreas' formulation of the ordinal! proposal 
does

Well, I would state that my task looks like a "simple enough task 
to tackle", and the one even inexperienced users (surely not only 
mathematicians) should be able to tackle, and they would, as Peter 
demonstrated, if the index arithmetic weren't broken.

One note: as far as I can tell, s/-1 is not a common pattern at all, 
but rather a quite "uncommon" one in as far as it is rarely encountered 
in real REBOL code. FIRST and /1 are the common patterns, which are 
not touched by R3.


Actually, the only thing different in R3 that arguably "works for 
common people" in R2 is this uncommon pattern of s/-1 and s/-2. Every 
other use of negative indices is broken in R2 (and as such, works 
for neither mathematicians nor common people) but works in R3.

I really don't care about path syntax with computed indexes, it's 
ugly and awkward, and broken because of the 0 hole. I'd really rather 
use a function. As long as we get PICKZ/POKEZ, I'll be good. We already 
have SKIP to act as a non-broken AT. But at least plug the hole with 
a triggered error, so it won't mess people up silently. It's a huge 
failure, at least make not fail silently.

As Ladislav demonstrated, 0-based is better anyway for computed indexes, 
so PICKZ and POKEZ would be better to use even if PICK and POKE didn't 
have the hole

I just counted three occurrences in PowerMezz, and two occurrences 
of /-2

Just for comparison: Red's sources are 13k lines (including whitespace 
and comments) of code.

In the ancient (!!) rebol.org snapshot I have locally, I counted 
11 occurrences in 8 files (blog, new-blog, make-doc, make-doc-pro, 
makedoc2, json, translate, xml-dom) in a total of ~1000 files and 
255k lines of code.

People have been discouraged to use fixed path indexes because they 
are supposedly slower in R2 than FIRST and such, but I like path 
syntax because it is shorter and unambiguous

Brian, just for the record, I find your proposal reasonable and pragmatic.


If I'm given PICKZ and POKEZ, I couldn't care less about the poor 
souls suffering from trying to use path syntax with negative indices 
and falling into the 0 hole. Maybe a bit egoistic, but well.

The reason I'm not finding negative indexes in paths in my own CMS 
code is that I had to replace them because they're not compatible 
between R2 and R3