RFC: naming for FrontTransversal and Transversal ranges

[Robert Jacques]

On Sat, 02 May 2009 17:59:53 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:
> Robert Jacques wrote:
>> Also, in a value semantics world, refs are third class citizens, but in  
>> a reference semantic world, value semantics get their own assignment  
>> operator ( []= ), and by convention, their own property ( .dup )
>
> The major problem is not assignment. That can be taken care of. The  
> problem is:
>
> 1. Passing an object into a function
>
> 2. Making the object as a member of another object
>
> 3. Yes, assigning to the object (which ought to be congruent with 1 and  
> 2).
>
> I have perused some more searches and documentation, and things don't  
> bode well for references. Consider the PyNum library. I have searched
>
> pynum pass by reference
>
> and found some interesting links. The first reveals differences between  
> numpy and matlab (notably reference semantics). The second is a  
> discussion entitled "beginner confused with numpy". Guess what the  
> confusion was about? Congratulations, you have won a 40'' LCD TV.  
> Reference semantics!
>
> Third hit:  
> https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-March/011509.html
>
> says:
>
>  >> Octave's pass-by-value mechanism (with lazy copy-on-write) is
>  >> something that is *far* more simple to grasp than NumPy's inherited
>  >> everything-is-a-reference semantics. I do regard myself as moderately
>  >> experienced Python programmer, yet every now and then I get shot in
>  >> the foot by the reference semantics in Python.
>
> I swear I didn't pay that guy.
>
> Also, getting back to Perl's Data language (http://tinyurl.com/derlrh) I  
> see the mention to references is clearly a WARNING, not an INTERESTING  
> AND DESIRABLE FEATURE.
>
> "It is important to keep the ``reference nature'' of piddles in mind  
> when passing piddles into subroutines. If you modify the input pdls you  
> modify the original argument,  not a copy of it. This is different from  
> some other array processing languages but makes for very efficient  
> passing of piddles between subroutines."
>
> So what I'm seeing is that reference semantics is not desirable and not  
> natural but was chosen for efficiency reasons. But you know, I don't  
> want to "keep in mind" extra stuff when coding, I have enough to worry  
> about. If I can get away with ref and/or refcounting, then I have taken  
> care of the efficiency issue and I don't need to keep in mind a weird  
> quirk.
>

I've said it before and I'll say it again. In high-level interpreted  
languages, with interactive consoles etc, you're generally doing  
prototyping work and value semantics are better for that. But D is a  
systems language. That doesn't make the arguments any less valid, but you  
might want to down weight them a bit.

> ============
>
> About undue copying of data: maybe that could be avoided by having  
> functions manipulate ranges (which are cheap to copy), not the  
> containers that use them. In C++ you need to pass the container more  
> often than not mostly because passing two iterators is amazingly  
> burdensome. In D we can pass ranges easily, so I think much D code that  
> wants to do stuff will just take ranges.

And ranges _are_ reference semantics. If as you say most of D's code would  
use ranges, doesn't that prove the counter point?

Although, I'm starting to see an interesting story: Here are containers.  
They have value semantics and are simple to use/prototype with. When  
you're done, you can move to ranges in the performance critical sections  
in order to boost performance. And some things, like high performance  
lock-free queues and stacks, might only exist as ranges.