RFC: naming for FrontTransversal and Transversal ranges

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Fri, May 1, 2009 at 6:25 PM, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
>> Bill Baxter wrote:
>>> On Fri, May 1, 2009 at 4:23 PM, Andrei Alexandrescu 
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>> I guess at that point the would-be D user would be entitled to
>>>> make me a lavaliere out of my Matrix library and move on.
>>> Python, and therefore NumPy, are reference based.
>> In a language that's reference based, things can't be helped. They
>> can be helped in D though. I wouldn't want to later cringe that I
>> missed the opportunity.
>> 
>>> So far I haven't seen any scientists posting on the list about
>>> how having their arrays and matrices be references is driving
>>> them crazy. It may be surprising to some of them at first, but
>>> even non-hard-core coders seem to be able to handle it.
>> To me this sounds more like an opportunity to do the right thing.
> 
> Could be.  I'm not arguing that refs are best, just giving some 
> evidence from the NumPy community to counter your assertion that 
> scientists would be confused by reference-based array and matrix 
> types.
> 
> 
>>> It helps that dummy assignments like a = b are rare.   More often
>>> you have things like a = b + c, and that creates a new matrix.
>>> Or  a += b, which pretty clearly mutates a.
>> Oh rly. How about this then?
>> 
>> Matrix a, b, c; ... c = a; a += b;
>> 
>> Does the last operation mutate c as well?
> 
> I said "assignments like a = b are rare" and you put one of those in 
> your example.

You said it and I don't buy it one femtosecond. Code does need to copy
values around. It's a fundamental operation!

> Yes, when you have an a=b anywhere you've got to pay attention and
> make sure you didn't mean a=b.dup.

That is terrible. Anywhere == a portion of the code far, far away.

> And the other thing is that when you pass a matrix to a function, you
>  need to be aware of whether the function mutates that matrix or not.
>  That's really the biggest pain, and source of hardest to find bugs.

I bet. Things get even more unpleasant when you have object that have 
reference members. Then the default constructor does The Wrong Thing(tm) 
- many C++ pundits and authors have eaten many good lunches with the 
money they got discussing the problem.

> Matlab goes the other extreme and makes everything value semantics. 
> It does a lot of COW optimizations under the hood to make it
> tolerably efficient even when tossing around big matrices.  But it's
> annoying if you want to write a function to make a small update to an
> existing matrix.  You have no choice but to return a copy and hope
> that Matlab's optimizer is smart enough to eliminate the unnecessary
> copy.

Yah. In D, there's ref.


Andrei