On Sat, 02 May 2009 17:59:53 -0400, Andrei Alexandrescu
<seewebsiteforem...@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.
