RFC: naming for FrontTransversal and Transversal ranges
sandford at jhu.edu
Sat May 2 15:52:17 PDT 2009
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
> 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:
> >> 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
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.
More information about the Digitalmars-d