I'm assuming that the .length property of a dynamic array can be set, causing the code to change the size, right?  This is not specified in the spec, that I can see.

Also, I assume that such a resize operation can (if expanding) result in an out-of-memory exception being thrown, just like operator new.  I don't see specs for either of those...

Walter may bash me down as wrong on this one, but it was always my understanding that the .length variable of arrays was a read only property of the array, exactly as in Java, initialized upon creation of the array.

-Brady

"Russ Lewis" <russ@deming-os.org> wrote in message news:3B96A34F.DABE45E5@deming-os.org...
> I'm assuming that the .length property of a dynamic array can be set, causing the code to change the size, right?  This is not specified in the spec, that I can see.
>
> Also, I assume that such a resize operation can (if expanding) result in an out-of-memory exception being thrown, just like operator new.  I don't see specs for either of those...
>

I've gone back and forth on this issue (whether setting .length resizes the array, or is it read-only). What do y'all think?


Russ Lewis wrote in message <3B96A34F.DABE45E5@deming-os.org>...
>I'm assuming that the .length property of a dynamic array can be set, causing the code to change the size, right?  This is not specified in the spec, that I can see.
>
>Also, I assume that such a resize operation can (if expanding) result in an out-of-memory exception being thrown, just like operator new.  I don't see specs for either of those...
>

	Resizing is good.  I don't mind the syntax.  If the setter/getter stuff
doesn't work out, the syntax might feel a bit like an anomaly.
	Not directly related, but have you though any more about
differentiating between attributes and members in structs?

Dan

Walter wrote:
> 
> I've gone back and forth on this issue (whether setting .length resizes the array, or is it read-only). What do y'all think?
> 
> Russ Lewis wrote in message <3B96A34F.DABE45E5@deming-os.org>...
> >I'm assuming that the .length property of a dynamic array can be set, causing the code to change the size, right?  This is not specified in the spec, that I can see.
> >
> >Also, I assume that such a resize operation can (if expanding) result in an out-of-memory exception being thrown, just like operator new.  I don't see specs for either of those...
> >

I think it should set the size of an array. I seem to remember from early
spec's that .length on character arrays would change if a longer string would
be assigned.
It would be cool to be able to truncate a string by just setting the .length.
(Just one thing). There are a lot more.

Jan



Walter wrote:

> I've gone back and forth on this issue (whether setting .length resizes the array, or is it read-only). What do y'all think?
>
> Russ Lewis wrote in message <3B96A34F.DABE45E5@deming-os.org>...
> >I'm assuming that the .length property of a dynamic array can be set, causing the code to change the size, right?  This is not specified in the spec, that I can see.
> >
> >Also, I assume that such a resize operation can (if expanding) result in an out-of-memory exception being thrown, just like operator new.  I don't see specs for either of those...
> >

> I'm assuming that the .length property of a dynamic array can be set, causing the code to change the size, right?  This is not specified in the spec, that I can see.
> 
> Also, I assume that such a resize operation can (if expanding) result in an out-of-memory exception being thrown, just like operator new.  I don't see specs for either of those...
> 

I don't want to be a constant critic, but I cannot see the real benefit of dynamic arrays been handeled by the language/compiler itself. Normally I would order this task to better fit in the languages standard library.

Sometimes you need just a little more intelligence for a spefic task than the normal dynamic array offers, in C++/Java/etc no problem you simply overload Vector and put your special stuff over it. After all thats the idea behind object oriented programming. How do you do this if the vector is already part of the language?

Will the compiler force a specific allocatation strategy? If you're a numerical algorihm freak for Vector classes you can even change it. Yes I know you'll proparly be able to do vector classes altough the compiler itself provides dynamic arrays nativly. But I personally hate the principle fact on languages that user written code has an other quality on use than compiler provided code. (Like write() in Pascal, a programmer could not make such a function himself, one of the biggest drawbacks of Pascal, as I see it, it gives you as a programmer a kind of depressive feeling beeing 2nd class only)

- Axel

Axel Kittenberger wrote:

> > I'm assuming that the .length property of a dynamic array can be set, causing the code to change the size, right?  This is not specified in the spec, that I can see.
> >
> > Also, I assume that such a resize operation can (if expanding) result in an out-of-memory exception being thrown, just like operator new.  I don't see specs for either of those...
> >
>
> I don't want to be a constant critic, but I cannot see the real benefit of dynamic arrays been handeled by the language/compiler itself. Normally I would order this task to better fit in the languages standard library.

Generally I agree that the compiler should be kept as simple as possible.  But I also think that it should handle the common cases and make them easy for the programmer to access.  Reallocation of arrays is a major headache in C/C++, and I am of the opinion that it (like native string handling, garbage collection, and other features) are a Good Thing to have in a modern language.

> Sometimes you need just a little more intelligence for a spefic task than the normal dynamic array offers, in C++/Java/etc no problem you simply overload Vector and put your special stuff over it. After all thats the idea behind object oriented programming. How do you do this if the vector is already part of the language?

If you're a massochist, implement a Vector class in D by allocating an array with new, saving a pointer to that array, and making people do everything by hand.

> Will the compiler force a specific allocatation strategy? If you're a numerical algorihm freak for Vector classes you can even change it. Yes I know you'll proparly be able to do vector classes altough the compiler itself provides dynamic arrays nativly. But I personally hate the principle fact on languages that user written code has an other quality on use than compiler provided code. (Like write() in Pascal, a programmer could not make such a function himself, one of the biggest drawbacks of Pascal, as I see it, it gives you as a programmer a kind of depressive feeling beeing 2nd class only)

I don't know what you mean about "allocation strategy" exactly.  The "append" operation appends a single element onto an array, presumably increasing it by only one element.  That's a simple increase by one...nice for algorithms, although it's kind of wasteful if you end up having to do it a lot.  If you want to increase the size of an array by more, just extend it to whatever size you want by (if Walter allows it) setting .length, or by reallocating the array:



int[] myArray;
// time to extend it
int len = myArray.length;
(myArray = new int[len*2])[0..len-1] = myArray[];



(at least, I think that syntax would work...)

Walter, I'm really thinking that making .length settable would be a Good Thing.  It would be good to have some sort of primitive that allows the programmer to extend arrays in place (when space is available).  If there is no such primitive, then we have no choice but to do a allocate-copy-release algorithm, which will discourage use of dynamic arrays for performance reasons.

Walter wrote:

> I've gone back and forth on this issue (whether setting .length resizes the
> array, or is it read-only). What do y'all think?
> 
> 
> Russ Lewis wrote in message <3B96A34F.DABE45E5@deming-os.org>...
> 
>>I'm assuming that the .length property of a dynamic array can be set,
>>causing the code to change the size, right?  This is not specified in
>>the spec, that I can see.
>>
>>Also, I assume that such a resize operation can (if expanding) result in
>>an out-of-memory exception being thrown, just like operator new.  I
>>don't see specs for either of those...
>>
>>
> 
> 

Are you resizing the array, or just changing the length of it that is counted as filled?  If you are resizing the array, then I don't like that syntax.  It seems to imply that what you are doing is taking a string, and then saying "I'm interested in *this* much of it".  I.e., it implies that all that you are doing is changing a variable.  If this includes an implicit resize and potentially string copying and garbage collection, then it seems to be to be the wrong syntax.  On the other hand, it would frequently be nice to take a block of text and say "this variable represents 20 characters starting at character 97".  (But this doesn't seem to be what D strings are.  Pity. Could you consider string range variables?)

I absolutely concur, there is no single paradigm that fits every need and this applies here.

Dynamic arrays and associate ones are very good tools, but not necessarily language features. We need to distinguish between the foundation layer and the ones above it.

We have integer and floating point numbers, why ? Because they are provided by the machine. There is a natural need for them to be present in the language itself. They are data units. What else can we do after this on a mechanical continuous memory world ? Perhaps place some of these units together one after another, that way we can index them by memory location, sounds right doesn't it ? Mathematicians calls this a vector, bah, lets just call it an array and get on with it. Now we have a one-to-one logic representation of the machine. This is what C was going after with moderate success.

Data units must exist and vectors of these must exist too or it would be a very short memory circuit die. So, the bottom layer is set. Dynamic arrays are built on top of it, they use indirection to access a block of memory outside the fixed memory environment where the program is running. One indirection away from the machine, one indirection slower, but yes, one indirection more flexible. The associate array follows a much more fun and didactic indirection graph.

I already gave my opinion on the need for concrete types precisely because of this. Polymorphism needs indirection, fixed memory access doesn't. The way we organize blocks of memory beyond linear space is what makes our programs tick. Faster or slower. Flexibly or statically. Effectively or sub-optimally. I would like to have a choice on this basic organization. After all, it is my program, not the compiler's one.

The language specs of these built-in types are sound and have a good dose of common sense, but they should be more useful as a basis for either a foundation library or as part of a much broader and fundamental major feature of the language capable of reflection properties. Dan suggested to work at the parse tree/symbol table level, well, I think this is a much better approach to pursue than to try to enforce a way of thinking. That is either a job for domain specific script languages or for ones coming from a less than stellar Rapid Application Development world.

To choose D as a name for this language and totally abandon the systems programming level instead of building layers of abstraction around it is not exactly paying an homage to C.

Avoid the Kitchen Sink allure.

-Rui Ferreira

The length variable doesn't refer to how much of the array is filled.  It refers to the capacity of the array.  Keep in mind, a length 20 int[] is always filled with 20 ints - even if they were just initialized to zilch.

The debate is about whether or not length is a read only variable to learn something about that particular array, or a property that can be set to dynamically change the size of the array.

I agree with you on that note - changing the size of the array can potentially be a process that's more invovled that just changing a length variable.  That syntax doesn't seem appropriate for those circumstances.  I think alot of the array implementation in D is shooting for similarities to Java, and one thing that makes .length and other array properties work in Java is that arrays are create-once, read-only.  Dynamic arrays are implemented in a class (Vector) which takes care of capacity vs size, and other administrative issues.

Which is why I'm still not exactly sure how D intends to do dynamic arrays. Or, I guess, where it's going by trying to provide them.  In Java, .length and other properties are handled by arrays being instances of the array class, and the [bracket] notation merely being syntactic sugar on top of the array object.  Try to provide the same facilities as Java's "Array", much less the same facilities as Java's "Vector" as built in, primitive parts of the language has never quite made sense to me (as to how it will actually work).

-Brady

>
> Are you resizing the array, or just changing the length of it that is counted as filled?  If you are resizing the array, then I don't like that syntax.  It seems to imply that what you are doing is taking a string, and then saying "I'm interested in *this* much of it".  I.e., it implies that all that you are doing is changing a variable.  If this includes an implicit resize and potentially string copying and garbage collection, then it seems to be to be the wrong syntax.  On the other hand, it would frequently be nice to take a block of text and say "this variable represents 20 characters starting at character 97".  (But this doesn't seem to be what D strings are.  Pity. Could you consider string range variables?)
>