The code doesn't have to be completely syntactically correct, only tokenization-wise correct. It's perfectly fine to have syntactic errors like unbalanced parens and missing semicolons in there.

Anyway, I don't want the preprocessor to be language independent because I don't want to watch out for cpp-directive-like things in comments and string literals.

I've also run into the situation you describe a couple of times in all my years with Pike, but for me it's not nearly often enough to warrant some kind of language support.

well, if we introduce counting from the end, why not allow a range that starts relative to the end too?

a[x..<y] == a[x..sizeof(a)-y] a[<x..y] == a[sizeof(a)-x..y] a[<x..<y] == a[sizeof(a)-x..sizeof(a)-y]

may be off by one, but you get the idea.

The remaining problem when it comes to implementing this is how to call lfuns in a good way, whether it's some extension to `[] or perhaps one or more completely new lfuns.

Yes, I'm thinking along the same lines. Right now this is my best shot:

A new lfun `[..] to handle all range operations. In the long run `[] no longer will be used for that, so that it can concentrate on single element indexing (which really is a fairly different operation).

`[..] would get this type:

mixed `[..] (int lower_bound_type, int lower_bound, int upper_bound_type, int upper_bound);

The bound type arguments say what type of bound was given, either a normal from-the-start bound, a from-the-end bound, or unspecified (i.e. as the first bound in a[..x]). This gives complete control to the object so that it's possible to implement data types with indeterminate lengths and/or with "real" indexing below zero.

lower_bound_type and upper_bound_type could be combined to a single bit field, but it's probably overall more expensive to do the necessary bit operations on that instead of passing them separately.

For compatibility, there'll be a fallback to `[] which then is called like this for all types of range operations:

o[a..b] => o->`[] (a, b) o[a..<b] => o->`[] (a, o->_sizeof()-1-b) o[a..] => o->`[] (a, Pike.NATIVE_MAX) o[<a..b] => o->`[] (o->_sizeof()-1-a, b) o[<a..<b] => o->`[] (o->_sizeof()-1-a, o->_sizeof()-1-b) o[<a..] => o->`[] (o->_sizeof()-1-a, Pike.NATIVE_MAX) o[..b] => o->`[] (0, b) o[..<b] => o->`[] (0, o->_sizeof()-1-b) o[..] => o->`[] (0, Pike.NATIVE_MAX)

The unfortunate thing with this fallback is that one can't define a class with element indexing but without range indexing, which is a very common case. Maybe there could be a runtime type check that `[] takes more than one argument before trying this fallback.

Yes, it would make the from-the-end functionality not work for old data types (assuming they implement array-like behavior, but with the current `[] calling convention they more or less have to do that).

As for Pike.NATIVE_MAX, it's how it already behaves. It'd of course be better to use an infinity symbol if there were one.

Is Int.inf added as a constant for that value too? Otherwise we should do that.. ;)

I wanted somewhere to begin. Ideally I would like to have integer inf support as low as in GMP itself.

Sweet dude.

It refers to the whole thing. Read the CVS. http://pike.ida.liu.se/development/cvs/combined.xml

wow, you guys never cease to amaze me!

greetings, martin.

What, we don't get to have the index-from-the-end-discussion every year any more? Excellent! Well done!

Sure we get to have them again.

So far, I don't think anyone has opposed the concept as such. The big problem has always been syntax and obscure semantics. And those can resurface at any time... ;)

I'm not quite sure if it's right to use sizeof(a)-1 as the end bias anymore. It's consistent in one way since 0 is the first element from the start and <0 the first from the end.

On the other hand, it's off-by-one wrt single indexing (not considering the sign). I.e. the last element through indexing is -1 (a[-1]), while it's <0 through subranging (a[<0..]). Seen that way it appears to be more appropriate to let <1 refer to the last element.

Which way is better? How is it in lpc? Should it perhaps even be that < only selects the negative range so that the index still have to be negative, i.e. to select the last index one would have to write <-1?

I think we should leave this open for now. Please play around with it, but be advised that it might very well change.

If you can index from the end with both positive and negative numbers then you'll get the difficult special cases near the bounds. It's the same reason why we don't use negative indices in ranging in the first place.

What I meant was that arr[-17..42] == arr[0..42], which is a good thing. The same should apply to the from-the-end variant too, of course.

Sorry, I didn't read carefully; ignore the previous answer.

Yes, it wouldn't be bad to extend the indexing operator with < too, regardless of off-by-one issues. For consistency, if nothing else. The problem with that is that one then would expect an index_type argument to `[] too, i.e. the reasonable prototype would then be

mixed `[] (int index, int index_type)

where index_type is a flag that says whether the < variant is used or not. That clashes a bit with the current `[] operator since the second argument means a range operation.

You mean like a `[<] or something? Perhaps, but then there would by extension be `[..<], `[<..] and `[<..<] too, and I think that would be unwieldy. I think it'd be unwieldy to have to write `[] and `[<] as two separate functions too, for that matter.

In that case I think it's better to simply change the `[] calling convention incompatibly. It's afterall something that #pike can cope quite well with.

The lfun name doesn't make sense in that case. It's tough when the only natural name already is taken. In this case I'm more inclined to introduce an incompatibly to stay with the natural name, since it's cleaner in the long run.

Either that, or `[,] :)

Changing APIs is *bad*, and #pike isn't an excuse.

Besides, it's *very* convenient to have `[] if you are too lazy to implement the '<'-operator parts yourself.

In this case I actually think #pike is a reasonable excuse. It's not _that_ big a deal to put a couple into your old code:

To me, #pike is for emergency use only. If possible, I write programs that are compatible with any pike (at least upwards). "You can solve that with grepping and inserting #pike" is never ever a good argument, in my opinion.

I think conveniency argument is a more compelling one: If you got a _sizeof in your class you don't have to deal with pesky from-the-end flags at all.

Yes.

Another thing is that `[] wouldn't really be the convenience alternative in the future either: One would expect sizeof magic in the single argument case too, and that isn't compatible. Consider old style code calling a new style conveniency `[] that tries to operate on that principle.

*thinks* Explain.

Don't meddle with it then; assume that `[] is capable of handling negative indices as usual and transform

a[<x] -> a[-1-x]

and skip making another lfun.

I'm not sure if I'm commenting the correct part of the thread. Anyway, this is a comment regarding negative indices to `[], with one index given.

I see many uses of objects where negative indices are fully apropiate. Thus, if the standard `[] lfun is changed to take an index type argument, it must must not clamp the range to 0<=x<sizeof(Object), as it can be fully valid with an object having sizeof(Object)==10, while the indices ranges -5..4.

Yes, and so it can hardly be considered 100% compatible; it's afaics only in the cases where the arguments are passed straightly on to some internal `[] that it works without any change.

The main benefit of your alternative is afaics that the ugly separate flag arguments are avoided; the flags are there nevertheless and needs to be handled. The price is more object cloning. I'm not so sure that won't have a noticeable impact.

First of all, thanks Martin(s), for supporting our efforts to port psycMUVE to Pike.

Our testcase (as mentioned by Martin and running under LDMud):

http://psyc.rebelsex.com/syntaxtest (source at http://psyc.rebelsex.com/syntaxtest?source - quick&dirty)

a[..*] is of course equal to a[0..*].

LPC does a[x..<y] == a[x..sizeof(a) - y] so a[0..<1] is the whole string/array.

fippo looked through the psycMUVE and found us using cases 1, 2, 4, 6 and 13 more or less frequently. The others... well... arcane :)

Case 2 (a[<1]) is already achieved using a[-1] in Pike and as we use it approximately 15 times we can handle it using a macro ... but if someone should think that a[<positive_integer] is nice to have... we'd make use of it :).

Cheers

a[x..<y] means a[x..sizeof(a) - y] and as "sizeof(str) - 1" is the last element of str, <1 is the last element.

One such use case: Consider that you have a string x and another string y that is a suffix to x. You want to get the substring of x that ends where the suffix starts.

o If from-the-end indexing starts at -1 going downwards, you have to write like this:

x[..< -sizeof (y) - 1]

I.e. both a negation and an off-by-one adjustment are necessary.

o If from-the-end indexing starts at 1 going upwards:

x[..< sizeof (y) + 1]

o If from-the-end indexing starts at 0 going upwards:

x[..< sizeof (y)]

So in this specific case, the last alternative leads to the simplest code. There must be more such common use cases.