Dave wrote:
> Oskar Linde wrote:
>>
>> 1. in-place default, copying algorithms specially named
>> -------------------------------------------------------
>>
>> Design:
>> void toUpper(char[] str); // in-place
>> char[] toUpperCopy(char[] str); // copy
>>
>> Pros:
>> * in-place is often more efficient and therefore default.
>> * many functions are imperative verbs, and as such one expects them to be modifying
>> * Similar to how the C++ STL is designed
>> Cons:
>> * many functions can not be expressed in-place (example: UTF-8 toUpper)
>>
> 
> Hmmm - Is the current implementation of std.string.toupper wrong then?

Not really. Some of the newer case folding mappings from Unicode are missing from std.uni, so it could be better though.

> (If you removed the if(!changed) {...} blocks [where the CoW is milked] you would effectively have an in-place implementation).

Again, not really. :) See Thomas Kuehne's post further up the thread. There are certain unicode case foldings where the number of UTF-8 element changes. This will be handled correctly by std.string.toupper/tolower, but the result can not be in-place.

>>
>> 2. copying default, in-place versions specially named
>> -----------------------------------------------------
>>
>> Design:
>> void toUpperInPlace(char[] str); // in-place
>> char[] toUpper(char[] str); // copy
>>
>> Pros:
>> * copying is safer, and is therefore a better default
> 
> Only if the coder expects that is the default, *and* they most often need the original data intact later in the program.
> 
> And that safety is not much of an advantage when your code is three-legged dog slow and eats up resources that could be used by other processes :) Walking to work may be safer than going 70 MPH on the freeway, but it would take me a week and I'd starve.

Is someone prejudiced here? :) I could counter that with how functional style programming is superior in all other ways, but I won't. ;)

>> * in-place is an optimization and would stand out as such
> 
> It's only considered an 'optimization' right now because it's different from the default (CoW).
> 
>> * default is functional (no-side effects), side effects stand out
>> * people used to functional style programming would not find any
>> surprises
>> * all functions can be defined as copying functions
>> * how many popular languages are designed (Ruby, Python, php, all "functional" languages, etc...)
> 
> Yes, but all of these are languages where performance is not an imperative (excepting some of the functional languages perhaps). Plus think of all the time and effort that have been spent on GC's because of this design choice :)
> 
>> Cons:
>> * could confuse people, lead to silent errors:
>> toupper(str); // doesn't change str
>> cos(x); // doesn't change x ;)
>>
>> For the record, I am in favor of number 2 and that would have biased the arguments above.
> 
> Likewise I'm in favor of #1 ;)

I could live with either one. It is after all only a matter of naming. Consistency is the most important thing. The argument that there are only a small subset of all functions for which in-place as a concept is applicable is IMHO quite strong.

/Oskar

Oskar Linde wrote:
> Kirk McDonald wrote:
> 
>> renox 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.
>>>
>>>
>>>
>>> In ruby, they have this nice convention that a.function() leaves a unchanged and a.function!() modifies a.
>>>
>>> Something like this would be nice, the hard part is choosing the correct naming convention so that it is followed..
>>>
>>> functionXIP (eXecute In Place), functionWSD (With Side Effect)?
>>> Sigh, hard to achieve something as simple and elegant as '!' : caution this function modifies the object!
>>>
>>> In the absence of proper naming termination, an optionnal parameter could be used yes.
>>>
>>
>> What about:
>>
>> void   toupper(char[] s);  // Modifies s in-place
>> char[] asupper(char[] s);  // COW function
>>
>> Of course, this convention would only apply to functions named "tosomething", but I bet most/all of the functions for which an "in-place" operation makes sense are named that.
> 
> 
> It doesn't really apply to functions that are verbs, like capitalize, sort and map.
> 
> For those one option is: capitalized, sorted and mapped for COW versions.
> 
> /Oskar

Those make me think the function is /asking/ if the array/string is capitalized, sorted, &c. For sheer, bloodyminded consistency's sake, we could use ascapitalized, assorted, &c, but those read pretty poorly. Hrm. On second thought, your idea is better. :-)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Oskar Linde wrote:
> Dave wrote:
> 
> Again, not really. :) See Thomas Kuehne's post further up the thread. There are certain unicode case foldings where the number of UTF-8 element changes. This will be handled correctly by std.string.toupper/tolower, but the result can not be in-place.
> 

Not (pedantically) in-place for those cases, but for all cases you could still get around a complete .dup (and of course the string arguments would have to change to be passed inout for to/upper/lower, std.uni.encode, etc.).

>>>
>>> 2. copying default, in-place versions specially named
>>> -----------------------------------------------------
>>>
>>> Design:
>>> void toUpperInPlace(char[] str); // in-place
>>> char[] toUpper(char[] str); // copy
>>>
>>> Pros:
>>> * copying is safer, and is therefore a better default
>>
>> Only if the coder expects that is the default, *and* they most often need the original data intact later in the program.
>>
>> And that safety is not much of an advantage when your code is three-legged dog slow and eats up resources that could be used by other processes :) Walking to work may be safer than going 70 MPH on the freeway, but it would take me a week and I'd starve.
> 
> Is someone prejudiced here? :) I could counter that with how functional style programming is superior in all other ways, but I won't. ;)
> 

I didn't intend it that way <g> Just pointing out that I'm not overly concerned with complete safety with a language like D when it can cost a lot.

> I could live with either one. It is after all only a matter of naming. Consistency is the most important thing. The argument that there are only a small subset of all functions for which in-place as a concept is applicable is IMHO quite strong.

You're right, it is a very small subset in Phobos right now but 'CoW' seems to be the design pattern chosen for D. As this thread went on I became concerned that CoW for arrays is probably not the way to go for a language like D (all IMHO).

> 
> /Oskar