December 18, 2007
Bill Baxter wrote:
> It's not so niche I don't think.  It's pretty widely used in numerical computing.  It's just a question of whether it's useful enough to warrant the extra syntactical and memory baggage it would require.  I think it would require all arrays to carry around a third value, no?

Yes, I also think it would, therefore growing the array record by 50%.
That doesn't sound very wholesome to me; I'd rather waive the feature
than suffer the added memory and runtime overhead.
We may hope that those who would compromise on their ressource usage
will at some future point of time be able to do so by using a dedicated
library array class or struct which implements this feature.

regards, frank
December 18, 2007
> What things are better with arbitrary-lower-bound arrays?  I honestly can't think of a time where I was like "damn!  I wish I could start this array at 17!" or something.


Well one reason is because some people prefer starting arrays at 1 (like myself). As for numbers other than 0 or 1, there are situations where that makes sense. Right now I am experimenting with an artificial intelligence concept of my own in another base zero only language and sometimes I'm doing things like copying and processing a portion of an image. There have been alot of situations were it would have been nice if I could simply have those arrays have starting and ending bounds that conform to the portion of the image they represent.

Obviously this isn't a necesity but it would be a helpfull feature for something like that if I decide to rewrite it in d some day.
December 18, 2007
> 
> That's a quite... daring and improbable claim!


Well I was only born in 1978 so I don't have any first hand experience and could be wrong but from what I've read Fortran, PL/1, Algol, Simula, and Pascal all had this feature. I don't know what Cobol and Lisp used but I'm guessing it wasn't base zero.

December 18, 2007
Thank you bearophile.

Mike
December 18, 2007
Why would there be a need for an extra memory in normall zero based arrays? I would think this would only affect people who decide to use the non-standard arrays to hold the lower bounds. And if bounds checking is turned off I would think it wouldn't make any difference. Then again I've never written a compiler so maybe I'm missing something.
December 18, 2007
"Mike Marquard" <mike_marquard@hotmail.com> wrote in message news:fk9g3a$73v$1@digitalmars.com...

> I'm doing things like copying and processing a portion of an image. There have been alot of situations were it would have been nice if I could simply have those arrays have starting and ending bounds that conform to the portion of the image they represent.

Wouldn't slices be perfect for this?


December 18, 2007
"Mike Marquard" <mike_marquard@hotmail.com> wrote in message news:fk9hid$adm$1@digitalmars.com...
> Why would there be a need for an extra memory in normall zero based arrays? I would think this would only affect people who decide to use the non-standard arrays to hold the lower bounds. And if bounds checking is turned off I would think it wouldn't make any difference. Then again I've never written a compiler so maybe I'm missing something.

You're right, this could be made to work by introducing another array type, a "bounded array" with explicit lower and upper bounds.  But the thing is with that, and with the T[new] array type that Walter wants to introduce, we'd have static arrays, dynamic arrays, bounded arrays, T[new] arrays, and associative arrays :O  That's an awfully large number of array types!


December 18, 2007
Mike Marquard wrote:
> Why would there be a need for an extra memory in normall zero based
> arrays? I would think this would only affect people who decide to use
> the non-standard arrays to hold the lower bounds. And if bounds checking
> is turned off I would think it wouldn't make any difference. Then again
> I've never written a compiler so maybe I'm missing something.

Indeed it would only concern those who use the non-standard arrays /if/
you are actually proposing to add a second array type which is inherently
incompatible with the current native array type (yes, of course it would
be possible to cast between them, if you are prepared to loose the extra
information when casting). But that situation seems... ugly, sorry.
I propose leaving the current array type as it is; you can have your own
(albeit imperfect) array type with any kind if indexing you like right
now - just write it. And sooner or later, you can probably even add the
last bit of perfection you could want (just wait for D to evolve - Rome
wasn't built in a day, or even a decade).

regards, frank
December 18, 2007
Mike Marquard wrote:
> Well one reason is because some people prefer starting arrays at 1 (like
> myself). As for numbers other than 0 or 1, there are situations where
> that makes sense. Right now I am experimenting with an artificial
> intelligence concept of my own in another base zero only language and
> sometimes I'm doing things like copying and processing a portion of an
> image. There have been alot of situations were it would have been nice
> if I could simply have those arrays have starting and ending bounds that
> conform to the portion of the image they represent.

Sorry, IMHO zero-starting arrays are the logically most consistent choice
in a language that also offers pointers, starting at 1 is awkward.

> Obviously this isn't a necesity but it would be a helpfull feature for
> something like that if I decide to rewrite it in d some day.

You could just scrap the extra element and fill your array starting at 1,
if you absolutely must. Check the 0th element for change with asserts or
contracts, to catch errors.

regards, frank
December 18, 2007
Mike Marquard wrote:
> Well I was only born in 1978 so I don't have any first hand experience
> and could be wrong but from what I've read Fortran, PL/1, Algol, Simula,
> and Pascal all had this feature. I don't know what Cobol and Lisp used
> but I'm guessing it wasn't base zero.

Well, I know about Pascal, and can't be bothered to look up the other
languages you mentioned. But let's get this straight:

a) You have not enumerated "just about every language that came before
c became popular" here, even remotely. Although a few popular ones.

b) Pascal (and probably all other languages you actually have enumerated)
knows only static arrays! That means it was easy for the compiler writer
to magically vanish the funny offsets away at compile time, which Walter
won't be able to do with D's dynamic arrays.

regards, frank