Loosing my time on skittles...

input "abcd"
desired output "arcd"
i want to use stride

snippet, where x and y are integer in real code:

    string s1 = "abcd";
    s1 = s1[stride(s1,x)..y] ~ 'r' ~ s1[2..$];

if x = 0 and y = 0 -> run time error. ok
if x = 0 and y = 1 -> "rcd" (??)
if x = 1 and y = 0 -> run time error. ok
if x = 1 and y = 1 -> "rcd"
if x = 0 and y = 2 -> "brcd" (WTF?)
if x = 1 and y = 2 -> "brcd" (...)

what the hell of parameters have i to put to achieve "arcd"?

On 02/12/2012 09:37 AM, RenatoL wrote:
> Loosing my time on skittles...
>
> input "abcd"
> desired output "arcd"
> i want to use stride
>
> snippet, where x and y are integer in real code:
>
>      string s1 = "abcd";
>      s1 = s1[stride(s1,x)..y] ~ 'r' ~ s1[2..$];
>
> if x = 0 and y = 0 ->  run time error. ok
> if x = 0 and y = 1 ->  "rcd" (??)
> if x = 1 and y = 0 ->  run time error. ok
> if x = 1 and y = 1 ->  "rcd"
> if x = 0 and y = 2 ->  "brcd" (WTF?)
> if x = 1 and y = 2 ->  "brcd" (...)
>
> what the hell of parameters have i to put to achieve "arcd"?

This is yet another problem caused by the dual nature of narrow strings. When used with algorithms like stride(), a char[] is *not* a RandomAccessRange but when used with the [] operator it is.

According the stride()'s documentation, s1 will lose elements through popFront() because of not being a RandomAccessRange.

Related question: Does D define the order of evaluation in an expression like

  foo() ~ bar()

Or is it unspecified as in C and C++?

Ali

On 02/12/2012 10:07 AM, Ali Çehreli wrote:
> On 02/12/2012 09:37 AM, RenatoL wrote:
>  > Loosing my time on skittles...
>  >
>  > input "abcd"
>  > desired output "arcd"
>  > i want to use stride
>  >
>  > snippet, where x and y are integer in real code:
>  >
>  > string s1 = "abcd";
>  > s1 = s1[stride(s1,x)..y] ~ 'r' ~ s1[2..$];

No matter how much *my* explanation below still makes sense to *me*, :p I can't compile that code with dmd 2.057. (?)

>  >
>  > if x = 0 and y = 0 -> run time error. ok
>  > if x = 0 and y = 1 -> "rcd" (??)
>  > if x = 1 and y = 0 -> run time error. ok
>  > if x = 1 and y = 1 -> "rcd"
>  > if x = 0 and y = 2 -> "brcd" (WTF?)
>  > if x = 1 and y = 2 -> "brcd" (...)
>  >
>  > what the hell of parameters have i to put to achieve "arcd"?
>
> This is yet another problem caused by the dual nature of narrow strings.
> When used with algorithms like stride(), a char[] is *not* a
> RandomAccessRange but when used with the [] operator it is.
>
> According the stride()'s documentation, s1 will lose elements through
> popFront() because of not being a RandomAccessRange.
>
> Related question: Does D define the order of evaluation in an expression
> like
>
> foo() ~ bar()
>
> Or is it unspecified as in C and C++?
>
> Ali
>

Ali

This is the code i compiled v. 2057 and parameters 0 1
import std.stdio;
import std.utf;
void main()
{
    string s1 = "abcd";
    s1 = s1[stride(s1,0)..1] ~ 'r' ~ s1[2..$];
    writeln(s1);
}

On 02/12/2012 10:25 AM, RenatoL wrote:
> This is the code i compiled v. 2057 and parameters 0 1
> import std.stdio;
> import std.utf;
> void main()
> {
>      string s1 = "abcd";
>      s1 = s1[stride(s1,0)..1] ~ 'r' ~ s1[2..$];
>      writeln(s1);
> }

Argh! std.algorithm.stride() and std.utf.stride() are different. :) What a confusion! :(

I think the following is correct for the first part, but the 2 in the last part will also be wrong unless it is also calculated:

    s1 = s1[0..stride(s1,0)] ~ 'r' ~ s1[2..$];

Ali

Mmmm.... this doesn't compile....

import std.stdio;
import std.algorithm;
void main()
{
    string s1 = "abcd";
    s1 = s1[stride(s1,0)..1] ~ 'r' ~ s1[2..$];
    writeln(s1);
}

Error: undefined identifier stride, did you mean alias string?

On 02/12/2012 11:05 AM, RenatoL wrote:
> Mmmm.... this doesn't compile....
>
> import std.stdio;
> import std.algorithm;
> void main()
> {
>      string s1 = "abcd";
>      s1 = s1[stride(s1,0)..1] ~ 'r' ~ s1[2..$];
>      writeln(s1);
> }
>
> Error: undefined identifier stride, did you mean alias string?

Because I am not operating correctly lately. :(

I meant std.range, not std.algorithm. But std.range.stride will cause a different compilation error because it returns a range object, not an index.

Ali

On Sunday, February 12, 2012 10:07:52 Ali Çehreli wrote:
> Related question: Does D define the order of evaluation in an expression like
> 
> foo() ~ bar()
> 
> Or is it unspecified as in C and C++?

It's currently unspecified. Walter has stated that he wants to make it so that it's always left to right, but I don't believe that he's done it yet, and it may or may not ever happen.

- Jonathan m Davis

On 02/13/12 18:57, Jonathan M Davis wrote:
> On Sunday, February 12, 2012 10:07:52 Ali Çehreli wrote:
>> Related question: Does D define the order of evaluation in an expression like
>>
>> foo() ~ bar()
>>
>> Or is it unspecified as in C and C++?
> 
> It's currently unspecified. Walter has stated that he wants to make it so that it's always left to right, but I don't believe that he's done it yet, and it may or may not ever happen.

Actually, it *is* specified as left-to-right, except for assignments and argument
evaluation. http://dlang.org/expression.html
No idea if the compiler fully implements that part of the spec.

artur

On Monday, February 13, 2012 19:47:03 Artur Skawina wrote:
> On 02/13/12 18:57, Jonathan M Davis wrote:
> > On Sunday, February 12, 2012 10:07:52 Ali Çehreli wrote:
> >> Related question: Does D define the order of evaluation in an
> >> expression
> >> like
> >> 
> >> foo() ~ bar()
> >> 
> >> Or is it unspecified as in C and C++?
> > 
> > It's currently unspecified. Walter has stated that he wants to make it so that it's always left to right, but I don't believe that he's done it yet, and it may or may not ever happen.
> 
> Actually, it *is* specified as left-to-right, except for assignments and
> argument evaluation. http://dlang.org/expression.html
> No idea if the compiler fully implements that part of the spec.

Well, foo() ~ bar() _is_ argument evaluation if you're dealing with an overloaded operator. And unfortunately, whether the spec is what the compiler does is frequently suspect anyway. So, who knows.

- Jonathan M Davis