What if selected functions in phobos were modified to take an optional parameter that specified COW or in-place? The default for each would be whatever they do now.

For example, toupper and tolower?

How many times have we seen something like this:

str = toupper(str); // or equivalent in another language.

Thanks,

- Dave

Dave wrote:

> 
> What if selected functions in phobos were modified to take an optional parameter that specified COW or in-place? The default for each would be whatever they do now.
> 
> For example, toupper and tolower?
> 
> How many times have we seen something like this:
> 
> str = toupper(str); // or equivalent in another language.
> 
> Thanks,
> 
> - Dave

I don't get it (the example).

str = toupper(str);

does not mean that str can be modified in place

-- BEGIN --
void bla(char[] str) {
  str = toupper(str);
  /* something else */
}

bla("this string is readonly");
--- END ---
If you mean something else - sorry, still I don't get it.

I'd rather wait till const/immutability in D problem will be resolved. Don't forget that additional "option" is runtime cost. There are some propositions of const/immutability that could help providing compile time information to deal with your proposition.

Dawid Ciezarkiewicz wrote:
> Dave wrote:
> 
> 
>>What if selected functions in phobos were modified to take an optional
>>parameter that specified COW or in-place? The default for each would be
>>whatever they do now.
>>
>>For example, toupper and tolower?
>>
>>How many times have we seen something like this:
>>
>>str = toupper(str); // or equivalent in another language.
>>
>>Thanks,
>>
>>- Dave
> 
> 
> I don't get it (the example).
> 
> str = toupper(str);
> 
> does not mean that str can be modified in place
> 

how about:

str[] = toupper(str)[];

Dawid Ciężarkiewicz wrote:
> Dave wrote:
> 
>> What if selected functions in phobos were modified to take an optional
>> parameter that specified COW or in-place? The default for each would be
>> whatever they do now.
>>
>> For example, toupper and tolower?
>>
>> How many times have we seen something like this:
>>
>> str = toupper(str); // or equivalent in another language.
>>
>> Thanks,
>>
>> - Dave
> 
> I don't get it (the example).
> 
> str = toupper(str);
> 
> does not mean that str can be modified in place
> 
> -- BEGIN --
> void bla(char[] str) {
>   str = toupper(str);
>   /* something else */
> }
> 
> bla("this string is readonly");
> --- END ---
> If you mean something else - sorry, still I don't get it.
> 

Right now, if you call toupper with a string with any lower-case chars. in it, it will .dup the string passed into it, then modify the dup'd string instead of the original and then return the dup. If it doesn't need to modify the string then it returns a reference to the original string. Often though, people just want to modify the original string anyway, so they do this:

str = toupper(str);

A new version could be declared as:

char[] toupper(char[] s, CIP cip = CIP.COW);

and changed to not modify the original instead of dup'ing it if COW isn't specified (which it is by default).

Then instead of str = toupper(str) you could do:

toupper(str,CIP.InPlace);

and avoid the duplication (a ref. to the modified string is still returned).

> I'd rather wait till const/immutability in D problem will be resolved. Don't
> forget that additional "option" is runtime cost. There are some
> propositions of const/immutability that could help providing compile time
> information to deal with your proposition.

Dawid Ciężarkiewicz wrote:
> I'd rather wait till const/immutability in D problem will be resolved. Don't
> forget that additional "option" is runtime cost. There are some
> propositions of const/immutability that could help providing compile time
> information to deal with your proposition.

It would take many calls to the modified toupper to cost as much as needlessly duplicating one large text file, and now you have to either live with the dups or write your own in-place toupper <g>

None of the const/immutability ideas will take care of having to "copy on write"; they were all more-or-less just ways of enforcing COW so there wouldn't be mistakes.

"Dave" <Dave_member@pathlink.com> wrote in message news:ealack$bjg$1@digitaldaemon.com...
>
> What if selected functions in phobos were modified to take an optional parameter that specified COW or in-place? The default for each would be whatever they do now.
>
> For example, toupper and tolower?
>
> How many times have we seen something like this:
>
> str = toupper(str); // or equivalent in another language.

I've had the same idea; would be great for those trying to write libraries that make as few allocations as possible.  Not to mention just plain more efficient if you don't need a copy.

Jarrett Billingsley wrote:
> "Dave" <Dave_member@pathlink.com> wrote in message news:ealack$bjg$1@digitaldaemon.com...
>> What if selected functions in phobos were modified to take an optional parameter that specified COW or in-place? The default for each would be whatever they do now.
>>
>> For example, toupper and tolower?
>>
>> How many times have we seen something like this:
>>
>> str = toupper(str); // or equivalent in another language.
> 
> I've had the same idea; would be great for those trying to write libraries that make as few allocations as possible.  Not to mention just plain more efficient if you don't need a copy. 
> 

Too much water under the bridge now anyway (or is there?), but I've often thought that it would've been better to do the same and make in-place the default and COW the exception anyhow. This wouldn't have been a hurdle for people coming from the C lib. to Phobos anyway -- they're used to it (e.g.: strcat, et al). As to users of other languages, all the docs. would have to do is make sure to point out what in-place means, with maybe an example of how to .dup your string before you pass it in if needed.

Dave wrote:

> Dawid Ciężarkiewicz wrote:
>> I'd rather wait till const/immutability in D problem will be resolved. Don't forget that additional "option" is runtime cost. There are some propositions of const/immutability that could help providing compile time information to deal with your proposition.
> 
> It would take many calls to the modified toupper to cost as much as needlessly duplicating one large text file, and now you have to either live with the dups or write your own in-place toupper <g>

Yes. Still - I'd rather see duplicated functions for that or something like
it (just to have it in compile time).

> None of the const/immutability ideas will take care of having to "copy on write"; they were all more-or-less just ways of enforcing COW so there wouldn't be mistakes.

Well, right.

Maybe just writting new module (std.strinplace) that do what you want and then sending it to Walter/D discussion group is good . I guess with newday import improvements names could stay like they were and people interested in this speedup would statically import this module and use FQN where they want such behavior.

Dawid Ciężarkiewicz wrote:
> Dave wrote:
> 
>> Dawid Ciężarkiewicz wrote:
>>> I'd rather wait till const/immutability in D problem will be resolved.
>>> Don't forget that additional "option" is runtime cost. There are some
>>> propositions of const/immutability that could help providing compile time
>>> information to deal with your proposition.
>> It would take many calls to the modified toupper to cost as much as
>> needlessly duplicating one large text file, and now you have to either
>> live with the dups or write your own in-place toupper <g>
> 
> Yes. Still - I'd rather see duplicated functions for that or something like
> it (just to have it in compile time).
>  
>> None of the const/immutability ideas will take care of having to "copy
>> on write"; they were all more-or-less just ways of enforcing COW so
>> there wouldn't be mistakes.
> 
> Well, right.
> 
> Maybe just writting new module (std.strinplace) that do what you want and
> then sending it to Walter/D discussion group is good . I guess with newday
> import improvements names could stay like they were and people interested
> in this speedup would statically import this module and use FQN where they
> want such behavior.

Not a bad idea... The main prob. would be that there would be a lot of duplication of code.

On Mon, 31 Jul 2006 16:40:54 -0500, Dave wrote:

>Not a bad idea... The main prob. would be that there would be a lot of duplication of code.

void toUpper_inplace(char[] x)
{
 . . .
}

char[] toUpper(char[] x)
{
   char[] y = x.dup;
   toUpper_inplace(y);
   return y;
}

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"