Walter wrote:
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message
> news:anrkjd$boh$1@digitaldaemon.com...
> 
>>They are using "passing by array reference", using which needs a deep
>>understanding of the low-level implementation of the arrays.
>>I understand that this is a result of the current (fast) implemetation of
>>arrays, but the result is *unacceptable*.
>>One easy solution would be to disallow passing arrays as "in" parameters
> 
> and
> 
>>require "inout". (I still like the "ref" keyword better than "inout")
>>But using "inout" parameters is slower, isn't it? It is "just another
> 
> level
> 
>>of indirection". So an effective solution would include redesigning the
>>low-level array implementation.
> 
> 
> Actually, I think simply disallowing resizing of 'in' arrays would do the
> trick.

That's unmotivated.  If one doesn't understand the nature of arrays, don't use the language.  Every language in my complement uses arrays totally differently.  In D's case, it's with the understanding that an array's references should be controlled until its dispersion point and that arrays which need to be modified later should have its throttle point where the appropriate references are updated.  It's a trivial part of engineering, not worth thinking about.

Pulling in any expectations from a previous language will get you killed in all of them.  Going into templated C++ with the expectation that arrays are passed by references as with Python is wrong; going into D with the expectation that arrays are distinct objects as with Python is wrong.  No expectations are being violated by D's behaviour because there aren't any, and anyone who says there are is myopic.

"Walter" <walter@digitalmars.com> wrote in message news:ao1pdi$26m5$3@digitaldaemon.com...
>
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:anrkjd$boh$1@digitaldaemon.com...
> > They are using "passing by array reference", using which needs a deep
> > understanding of the low-level implementation of the arrays.
> > I understand that this is a result of the current (fast) implemetation
of
> > arrays, but the result is *unacceptable*.
> > One easy solution would be to disallow passing arrays as "in" parameters
> and
> > require "inout". (I still like the "ref" keyword better than "inout") But using "inout" parameters is slower, isn't it? It is "just another
> level
> > of indirection". So an effective solution would include redesigning the low-level array implementation.
>
> Actually, I think simply disallowing resizing of 'in' arrays would do the trick.

Delphi does somthing like that, i cant remember the terminology there are two ways to pass an array, both effectivly by referance but only one of them allows resizing.

chris

> > you can't have a zero length array,
>
> Sure you can.
>
> > null dynamic arrays can be added to.
>
> A null dynamic array is just one with 0 length.
>
`null` and `new type[0]`  IHMO are not the same there are times when you want to return 'null' no list and new item[0] there is a list but its empty.

I remember some heated debateds about malloc and what it should return if you call it with 0, whilst I was working on a Java VM. the eventual outcome was that you should not be able to call malloc(0) thats an error but you should be able to create a 0 length collection.

especially as D heap allocated arrays are dynamic, and that I believe that
you should be able to set the available length as well as the number of
actual entries in the array
it makes sense (to me) that calling new type[0]  should be allocating space
for future expansion and not returning null. (or something that is = = =
null )

Mike.

It is not that arrays should be one way or another, but that their current behaviour is inconsistant with D aims of removing some of the pitfalls that you have in C++

learning a new behaviour is not a problem, but the current array behaviour is worse (IHMO) than C++ not defaulting destructors to be virtual.

if all the information related to the array is not stored in the array
"object" then
'in' arrays should either be immutable or copy-on-write (runtime or compile
time)
rather than partly mutable
I think disallowing extension but allowing modification is just a cludge to
fit in with the current implementation.
what would happen if someone wanted to write a D compiler for CLR ? would
the have to implement this behaviour ? or onto an architecture with hardware
accelerated GC ?

Mike.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:ao1qf5$27t3$1@digitaldaemon.com...
> Walter wrote:
> > "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:anrkjd$boh$1@digitaldaemon.com...
> >
> >>They are using "passing by array reference", using which needs a deep
> >>understanding of the low-level implementation of the arrays.
> >>I understand that this is a result of the current (fast) implemetation
of
> >>arrays, but the result is *unacceptable*.
> >>One easy solution would be to disallow passing arrays as "in" parameters
> >
> > and
> >
> >>require "inout". (I still like the "ref" keyword better than "inout") But using "inout" parameters is slower, isn't it? It is "just another
> >
> > level
> >
> >>of indirection". So an effective solution would include redesigning the low-level array implementation.
> >
> >
> > Actually, I think simply disallowing resizing of 'in' arrays would do
the
> > trick.
>
> That's unmotivated.  If one doesn't understand the nature of arrays, don't use the language.  Every language in my complement uses arrays totally differently.  In D's case, it's with the understanding that an array's references should be controlled until its dispersion point and that arrays which need to be modified later should have its throttle point where the appropriate references are updated.  It's a trivial part of engineering, not worth thinking about.
>
> Pulling in any expectations from a previous language will get you killed in all of them.  Going into templated C++ with the expectation that arrays are passed by references as with Python is wrong; going into D with the expectation that arrays are distinct objects as with Python is wrong.  No expectations are being violated by D's behaviour because there aren't any, and anyone who says there are is myopic.
>

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:ao1qf5$27t3$1@digitaldaemon.com...
> That's unmotivated.  If one doesn't understand the nature of arrays, don't use the language.  Every language in my complement uses arrays totally differently.  In D's case, it's with the understanding that an array's references should be controlled until its dispersion point and that arrays which need to be modified later should have its throttle point where the appropriate references are updated.  It's a trivial part of engineering, not worth thinking about.
>
> Pulling in any expectations from a previous language will get you killed in all of them.  Going into templated C++ with the expectation that arrays are passed by references as with Python is wrong; going into D with the expectation that arrays are distinct objects as with Python is wrong.  No expectations are being violated by D's behaviour because there aren't any, and anyone who says there are is myopic.

While I agree with your sentiment, I've always been uncomfortable with the side effects of resizing arrays. The semantics are the way they are in D because they allow well crafted array code to run like the wind. It's a tradeoff that makes sense.

I can see very few legitimate cases where one would like to resize an 'in' array, most of the time it's likely to be a bug. Disallowing it is workable because it has the effect of asking the programmer if he really means it. The workaround if it is desired to resize it is simple, just copy it:

    void foo(in int[] a)
    {
        a.length = 10;    // error, can't resize 'in' array
        int[] b = a;
        b.length = 10;    // ok
    }

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:ao26ps$2kuu$1@digitaldaemon.com...
>
> > > you can't have a zero length array,
> >
> > Sure you can.
> >
> > > null dynamic arrays can be added to.
> >
> > A null dynamic array is just one with 0 length.
> >
> `null` and `new type[0]`  IHMO are not the same there are times when you want to return 'null' no list and new item[0] there is a list but its
empty.
>
> I remember some heated debateds about malloc and what it should return if you call it with 0, whilst I was working on a Java VM. the eventual
outcome
> was that you should not be able to call malloc(0) thats an error but you should be able to create a 0 length collection.
>
> especially as D heap allocated arrays are dynamic, and that I believe that
> you should be able to set the available length as well as the number of
> actual entries in the array
> it makes sense (to me) that calling new type[0]  should be allocating
space
> for future expansion and not returning null. (or something that is = = =
> null )

Interestingly, I think the need to worry about the difference between 0 length and null just goes away with D arrays, i.e. they are just an artifact of how C does things.

They affect the speed with which you can test if something is null or not. You can't test the length for null first because to do so you must dereference the pointer, which if null is an error.  So to be safe, first you must test the pointer then the length for 0, and only then do you have enough information to know if you should start the loop.

I think there's still plenty of difference between null and an empty array. I'm sure they'd become apparent in the implementation at least.  It could affect performance of iteration features.

I really think in parameters should be thoroughly immutable to the point of not being able to be passed as mutable array parameters themselves (to do so you must make a copy).  This feature limits references to array entries explicitly requested and thus can be tracked and contained by the compiler. Otherwise there's no way you can easily enforce a contract that clients not misuse your data.  The contract has to be visible in the language somehow, either implicit or explicit.  Then the callee has to guarantee not to write to its parms in order to be able to take parms which are constant or thru refs to read-only data.  Otherwise we'll just end up with an uncontrolled mess.

If you want to ensure that your client does not abuse your data, typecast your data to be const before passing it to them.  If it doesn't have the contract that says "I won't abuse your data" then the caller has to proactively make a copy of the constant and send that in just in case the routine decides to mess around with the data you pass it.  No other way to be safe.

The other way, (C++'s way) at least you can get a reasonable guarantee which is usually enforced pretty well by the compiler, that something won't misuse your data, without having to resort to expensive runtime data duplication.

Does that qualify as an optimization, or not?  It is, but only when the data is in fact unwritable and you care enough about it to make that copy.  Which isn't all that often in practice.  All nuts and bolts and hoses and adaptor sockets.  Usually you hook things up right (but that damn 5% when you get it wrong and have to figure out what went wrong!)  That's when a tool like const becomes handy.  It lets you track down overwrite bugs.  Hell it lets you prevent them.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ao2ntg$3bi$2@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:ao26ps$2kuu$1@digitaldaemon.com...
> >
> > > > you can't have a zero length array,
> > >
> > > Sure you can.
> > >
> > > > null dynamic arrays can be added to.
> > >
> > > A null dynamic array is just one with 0 length.
> > >
> > `null` and `new type[0]`  IHMO are not the same there are times when you want to return 'null' no list and new item[0] there is a list but its
> empty.
> >
> > I remember some heated debateds about malloc and what it should return
if
> > you call it with 0, whilst I was working on a Java VM. the eventual
> outcome
> > was that you should not be able to call malloc(0) thats an error but you should be able to create a 0 length collection.
> >
> > especially as D heap allocated arrays are dynamic, and that I believe
that
> > you should be able to set the available length as well as the number of
> > actual entries in the array
> > it makes sense (to me) that calling new type[0]  should be allocating
> space
> > for future expansion and not returning null. (or something that is = = =
> > null )
>
> Interestingly, I think the need to worry about the difference between 0 length and null just goes away with D arrays, i.e. they are just an
artifact
> of how C does things.

Dude why are you going off on Walter?  Just because his arrays aren't const-safe.

Sean

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:ao1qf5$27t3$1@digitaldaemon.com...
> Walter wrote:
> > "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:anrkjd$boh$1@digitaldaemon.com...
> >
> >>They are using "passing by array reference", using which needs a deep
> >>understanding of the low-level implementation of the arrays.
> >>I understand that this is a result of the current (fast) implemetation
of
> >>arrays, but the result is *unacceptable*.
> >>One easy solution would be to disallow passing arrays as "in" parameters
> >
> > and
> >
> >>require "inout". (I still like the "ref" keyword better than "inout") But using "inout" parameters is slower, isn't it? It is "just another
> >
> > level
> >
> >>of indirection". So an effective solution would include redesigning the low-level array implementation.
> >
> >
> > Actually, I think simply disallowing resizing of 'in' arrays would do
the
> > trick.
>
> That's unmotivated.  If one doesn't understand the nature of arrays, don't use the language.  Every language in my complement uses arrays totally differently.  In D's case, it's with the understanding that an array's references should be controlled until its dispersion point and that arrays which need to be modified later should have its throttle point where the appropriate references are updated.  It's a trivial part of engineering, not worth thinking about.
>
> Pulling in any expectations from a previous language will get you killed in all of them.  Going into templated C++ with the expectation that arrays are passed by references as with Python is wrong; going into D with the expectation that arrays are distinct objects as with Python is wrong.  No expectations are being violated by D's behaviour because there aren't any, and anyone who says there are is myopic.
>

Sean L. Palmer wrote:
> Dude why are you going off on Walter?  Just because his arrays aren't
> const-safe.

Huh?  Perhaps you're mistaking who I was talking about in the second sentence - people learning the language who don't want to understand it (we can do such limited error handling here that those are the only people this can effect), and largely as a response to this whole thread set.

I've never argued for const safety - where are you pulling that from?

> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:ao1qf5$27t3$1@digitaldaemon.com...
> 
>>Walter wrote:
>>
>>>"Sandor Hojtsy" <hojtsy@index.hu> wrote in message
>>>news:anrkjd$boh$1@digitaldaemon.com...
>>>
>>>>They are using "passing by array reference", using which needs a deep
>>>>understanding of the low-level implementation of the arrays.
>>>>I understand that this is a result of the current (fast) implemetation
> 
> of
> 
>>>>arrays, but the result is *unacceptable*.
>>>>One easy solution would be to disallow passing arrays as "in" parameters
>>>
>>>and
>>>
>>>
>>>>require "inout". (I still like the "ref" keyword better than "inout")
>>>>But using "inout" parameters is slower, isn't it? It is "just another
>>>
>>>level
>>>
>>>
>>>>of indirection". So an effective solution would include redesigning the
>>>>low-level array implementation.
>>>
>>>
>>>Actually, I think simply disallowing resizing of 'in' arrays would do
> 
> the
> 
>>>trick.
>>
>>That's unmotivated.  If one doesn't understand the nature of arrays,
>>don't use the language.  Every language in my complement uses arrays
>>totally differently.  In D's case, it's with the understanding that an
>>array's references should be controlled until its dispersion point and
>>that arrays which need to be modified later should have its throttle
>>point where the appropriate references are updated.  It's a trivial part
>>of engineering, not worth thinking about.
>>
>>Pulling in any expectations from a previous language will get you killed
>>in all of them.  Going into templated C++ with the expectation that
>>arrays are passed by references as with Python is wrong; going into D
>>with the expectation that arrays are distinct objects as with Python is
>>wrong.  No expectations are being violated by D's behaviour because
>>there aren't any, and anyone who says there are is myopic.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ao37ep$ine$1@digitaldaemon.com...
> They affect the speed with which you can test if something is null or not. You can't test the length for null first because to do so you must dereference the pointer, which if null is an error.  So to be safe, first you must test the pointer then the length for 0, and only then do you have enough information to know if you should start the loop.

This is incorrect. A reference to an array is a pair, one is the length and the other is the pointer. The length can therefore be tested without dereferencing any pointer.

> I really think in parameters should be thoroughly immutable to the point
of
> not being able to be passed as mutable array parameters themselves (to do
so
> you must make a copy).  This feature limits references to array entries explicitly requested and thus can be tracked and contained by the
compiler.
> Otherwise there's no way you can easily enforce a contract that clients
not
> misuse your data.  The contract has to be visible in the language somehow, either implicit or explicit.  Then the callee has to guarantee not to
write
> to its parms in order to be able to take parms which are constant or thru refs to read-only data.  Otherwise we'll just end up with an uncontrolled mess.

I think what you're arguing for is something like C++'s const& type modifier.

> If you want to ensure that your client does not abuse your data, typecast your data to be const before passing it to them.  If it doesn't have the contract that says "I won't abuse your data" then the caller has to proactively make a copy of the constant and send that in just in case the routine decides to mess around with the data you pass it.  No other way to be safe.
>
> The other way, (C++'s way) at least you can get a reasonable guarantee
which
> is usually enforced pretty well by the compiler, that something won't
misuse
> your data, without having to resort to expensive runtime data duplication.
>
> Does that qualify as an optimization, or not?  It is, but only when the
data
> is in fact unwritable and you care enough about it to make that copy.
Which
> isn't all that often in practice.  All nuts and bolts and hoses and
adaptor
> sockets.  Usually you hook things up right (but that damn 5% when you get
it
> wrong and have to figure out what went wrong!)  That's when a tool like const becomes handy.  It lets you track down overwrite bugs.  Hell it lets you prevent them.

I understand why you want const parameters and I know you rely on it to find bugs, but I am less convinced of its payback/cost.