www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Ruby reverse Index Arrays

reply Gowron <Gowron_member pathlink.com> writes:
It would be interesting if D borrowed the negative indexes of ruby.

Such as an array of number starts from 0 to 6 and the end of the array starts at
-1.   So a[1, -1] would be able to iterate over the array without length.
Jul 05 2004
next sibling parent Ant <Ant_member pathlink.com> writes:
In article <ccbtcr$2ft6$1 digitaldaemon.com>, Gowron says...
It would be interesting if D borrowed the negative indexes of ruby.

Such as an array of number starts from 0 to 6 and the end of the array starts at
-1.   So a[1, -1] would be able to iterate over the array without length.

This was suggested before. I don't remember Walter showing any interest at all. build an Array template, I can use it Ant
Jul 05 2004
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Gowron wrote:

 It would be interesting if D borrowed the negative indexes of ruby.
 
 Such as an array of number starts from 0 to 6 and the end of the 
 array starts at -1.

Been talked to death already. D/24082
 So a[1, -1] would be able to iterate over the array without length.

What do you mean by this? By your suggestion, that would simply mean a without the first and last elements. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Jul 05 2004
prev sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Gowron wrote:

 It would be interesting if D borrowed the negative indexes of ruby.
 
 Such as an array of number starts from 0 to 6 and the end of the array
 starts at
 -1.   So a[1, -1] would be able to iterate over the array without length.

That idea has been discussed a little while ago without clear resolution. I think the original idea (the same that you are stating) was discarded rather quickly: * for one, negative indices do have a certain meaning when used on pointers (just counting backwards) so it would be rather confusing to give them a different meaning for arrays. * for the other, checking for the sign would have to happen at runtime which would be costly at every array access. Currently, there is only bounds-checking happening, which can be switched off after the debugging phase of a program. The improved idea that was discussed lateron did appear in different variations. The version I liked most, was to introduce the symbol $ as a special symbol only within indexing expressions, meaning: the range of this dimension. This would allow you to write: a[1..$-1] instead of your suggestion. It looks nice and - as I think - rather intuitive. The drawback that I see, though, is that it uses up the character $ which could actually be used much better for some other, more important language extensions in the future. Alternative suggestions were similar, just using a keyword instead of the $ Nice thing would be, that you can also easily pick the middle of an array (at least for even ranges) Anyhow: Walter did not seem to show much interest and the matter is not really pressing. It would be neat to have, especially for people doing extensive string handling, but it should not be a problem to add at some later point of time.
Jul 05 2004
parent reply Sam McCall <tunah.d tunah.net> writes:
It's an interesting idea, but we'd lose the ability to catch some 
accidental out-of-bounds accesses, which is IMHO enough reason not to do it.

Norbert Nemec wrote:
 Gowron wrote:
 The improved idea that was discussed lateron did appear in different
 variations. The version I liked most, was to introduce the symbol $ as a
 special symbol only within indexing expressions, meaning: the range of this
 dimension.
 
 This would allow you to write:
         a[1..$-1]
 instead of your suggestion.

we're going to need a nice way to get the nth dimension anyway. Sam
Jul 05 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Sam McCall wrote:

 It's an interesting idea, but we'd lose the ability to catch some
 accidental out-of-bounds accesses, which is IMHO enough reason not to do
 it.
 
 Norbert Nemec wrote:
 Gowron wrote:
 The improved idea that was discussed lateron did appear in different
 variations. The version I liked most, was to introduce the symbol $ as a
 special symbol only within indexing expressions, meaning: the range of
 this dimension.
 
 This would allow you to write:
         a[1..$-1]
 instead of your suggestion.

we're going to need a nice way to get the nth dimension anyway. Sam

For multi-dim arrays .length could return the total number of elements and another property (for argument's sake call it "dims") could return a static array of the size of each dimension. Then length = dims[0] * dims[1] * ... * dims[N-1]. There isn't any way around adding some property like "dims" since that information needs to be available outside of indexing expressions. Whether the "length" property returns the array or "dims" or something else it doesn't really matter. Personally I'm not a huge fan of $ since the properties are more readable and general.
Jul 05 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Ben Hinkle wrote:

 Sam McCall wrote:
 
 It's an interesting idea, but we'd lose the ability to catch some
 accidental out-of-bounds accesses, which is IMHO enough reason not to do
 it.
 
 Norbert Nemec wrote:
 Gowron wrote:
 The improved idea that was discussed lateron did appear in different
 variations. The version I liked most, was to introduce the symbol $ as a
 special symbol only within indexing expressions, meaning: the range of
 this dimension.
 
 This would allow you to write:
         a[1..$-1]
 instead of your suggestion.

we're going to need a nice way to get the nth dimension anyway. Sam

For multi-dim arrays .length could return the total number of elements and another property (for argument's sake call it "dims") could return a static array of the size of each dimension. Then length = dims[0] * dims[1] * ... * dims[N-1].

In my proposal, .length only exists for 1D-arrays. Here it is assignable with the magic of reallocating and copying the data if necessary. What you call "dims" is called .range in my proposal. It has itself the semantics of a fixed array of length N. Assigning to it is possible, but unsafe and without any magic (it boils down to assigning to the raw entries in the array-reference structure) The product of all ranges is implemented as a new, read-only property .volume The .size property equals .volume time the size of one entry.
 Personally I'm not a huge fan of $ since the properties are more readable
 and general.

You are sure about "readable"? S1.A[2..S1.A.range[0]-1,2..S1.A.range[1]-1] = S2.B[2..S2.B.range[0]-1,2..S2.B.range[1]-1]; vs. S1.A[2..$-1,2..$-1] = S2.B[2..$-1,2..$-1]; And don't tell me this is constructed. I'm working with Matlab, where I have code like this all over the place. Of course, the $ is not very general, but be honest: the range of and array is used so often in indexing it, that it would really make sense to think about a reasonable shorthand. My only concern about $ is, that it really uses up one character that is so far unused and might find some much more important role sometimes in the future. (Just like # which we should really preserve until we find some worthy application for it.)
Jul 05 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ccdd9k$1h4v$1 digitaldaemon.com>, Norbert Nemec says...

My only concern about $ is, that it really uses up one character that is so
far unused and might find some much more important role sometimes in the
future. (Just like # which we should really preserve until we find some
worthy application for it.)

Let's use the sign or the sign then. (The dollar is not the only currency on this planet <g> ). Arcane Jill PS. The EURO SIGN character is U+20AC (not U+0080 as Windows would have us believe).
Jul 06 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Arcane Jill wrote:

 In article <ccdd9k$1h4v$1 digitaldaemon.com>, Norbert Nemec says...
 
My only concern about $ is, that it really uses up one character that is
so far unused and might find some much more important role sometimes in
the future. (Just like # which we should really preserve until we find
some worthy application for it.)

Let's use the sign or the sign then. (The dollar is not the only currency on this planet <g> ).

But the only currency sign that made into the ASCII character set. I guess we just have to live with the fact that it is the "American Standard Code for Information Interchange" that we are using internationally now. And going Unicode for the basic language features would probably not be a good idea. It is nice to allow it for string constants and comments, but the language itself should better be editable with any good-old-editor.
 PS. The EURO SIGN character is U+20AC (not U+0080 as Windows would have us
 believe).

Is it true that Windows is misbehaving like that? In ISO-8859-15, the EURO SIGN is at position 80, but the Unicode table is based on ISO-8859-1. Maybe, Windows is just mixing up the names of the codes?
Jul 06 2004
parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <ccdt8a$2b4n$1 digitaldaemon.com>, Norbert Nemec says...

Is it true that Windows is misbehaving like that? In ISO-8859-15, the EURO
SIGN is at position 80, but the Unicode table is based on ISO-8859-1.
Maybe, Windows is just mixing up the names of the codes?

Depends what you mean by "misbehaving". Windows - at least in most English-speaking countries = prefers an encoding called "Windows code page 1252" (aka WINDOWS-1252), an 8-bit encoding which co-incides with ISO-8859-1 in the ranges 00-7F and A0-FF, and has some extra characters (which Microsoft imaagine will be commonly used by English speaking characters) in the range 80-9F, in place of the C1-controls. By itself, this is relatively harmless. Where it all goes wrong is that text files, Word documents, web pages, and so on, end up getting written in this encoding, and Windows is very, very naughty in that it will often deliberately misrepresent the encoding (presumably in the belief that if it incorrectly declares the encoding to be ISO-8859-1 then other endpoints will get most of the characters right, but if it declares it as WINDOWS-1252 then other endpoints might reject the document because it has a unknown encoding). Arcane Jill
Jul 06 2004
prev sibling next sibling parent reply Sam McCall <tunah.d tunah.net> writes:
Hmm, you do make a good point.
Norbert Nemec wrote:
 My only concern about $ is, that it really uses up one character that is so
 far unused and might find some much more important role sometimes in the
 future. (Just like # which we should really preserve until we find some
 worthy application for it.)

A keyword sounds like the answer, three alternatives: 1) Make "range" a keyword, and something like foo[2,range-1] would know that foo[2,foo.range[1]-1] was intended. In the case of nested array accesses, I would suggest that this gets the range of the inner one, and if you want the range of an outer one you must write it out in full as now. There are certainly ways of extending it, but I think they'd be complicated for little benefit. 2) Create a new keyword. Hard to find something short, descriptive, and where it won't be annoying that you can't use it as a variable name (in and out are bad enough). Maybe end? 3) Cleverly reuse an existing keyword in an unambiguous way, like "in" is used for assoc arrays and parameters[1]. The only one that is obvious is "final", and i'm not sure if that's good. [1] could we have foreach(char a in str) instead of/in addition to foreach(char a; str)? It's not much longer, it's clearer, it doesn't seem to be ambiguous, and it makes it completely obvious that the variable goes first, and the container after. Sam
Jul 06 2004
next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Sam McCall wrote:

 Hmm, you do make a good point.
 Norbert Nemec wrote:
 My only concern about $ is, that it really uses up one character that is
 so far unused and might find some much more important role sometimes in
 the future. (Just like # which we should really preserve until we find
 some worthy application for it.)

A keyword sounds like the answer, three alternatives: 1) Make "range" a keyword, and something like foo[2,range-1] would know that foo[2,foo.range[1]-1] was intended.

That might be an idea. Of course, with "range" being handled specially here, this would really be a mess for the syntax, which Walter definitely will not like (and I don't, either) What would "range" be? * A keyword? That would make it impossible to use it as identifier any other context. Ugly! * A argument-less function that is predefined only in this context? Maybe. It would not collide with the .range[] property, which always is used as qualifier for an array. And anybody using range as an unqualified identifier will have to live with the collision. Can argument-less functions generally be called without the parenthesis? Or is this only true for member functions (acting as properties)?
 In the case of nested array accesses, I would suggest that this gets the
 range of the inner one, and if you want the range of an outer one you
 must write it out in full as now. There are certainly ways of extending
 it, but I think they'd be complicated for little benefit.

There is no problem. "range" would of course always refer to that dimension where it is used for indexing.
Jul 06 2004
parent Sam McCall <tunah.d tunah.net> writes:
Norbert Nemec wrote:

 Sam McCall wrote:
 
 
Hmm, you do make a good point.
Norbert Nemec wrote:

My only concern about $ is, that it really uses up one character that is
so far unused and might find some much more important role sometimes in
the future. (Just like # which we should really preserve until we find
some worthy application for it.)

Exactly, we already have a "perfectly functional" Perl ;-) A keyword sounds like the answer, three alternatives: 1) Make "range" a keyword, and something like foo[2,range-1] would know that foo[2,foo.range[1]-1] was intended.

That might be an idea. Of course, with "range" being handled specially here, this would really be a mess for the syntax, which Walter definitely will not like (and I don't, either) What would "range" be? * A keyword? That would make it impossible to use it as identifier any other context. Ugly!

"range" that is a valid identifier) if it wasn't a keyword, then there would be ambiguity with identifiers. For example: make it a function, and then people who do int range = max-min; a[foo..foo+range]; get confusing behaviour/confusing error messages.
 * A argument-less function that is predefined only in this context? Maybe.

scoping rules?
 There is no problem. "range" would of course always refer to that dimension
 where it is used for indexing.

array[range-foo]; // fine array[foo(range)]; // fine array[foo[range]]; // bad, should be array[foo[array.length]] Sam
Jul 06 2004
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Sam McCall wrote:
 Hmm, you do make a good point.
 Norbert Nemec wrote:
 

 A keyword sounds like the answer, three alternatives:
 1) Make "range" a keyword, and something like foo[2,range-1] would...

 2) Create a new keyword. Hard to find something short, descriptive, ... 
  Maybe end?
 3) Cleverly reuse an existing keyword in an unambiguous way, like "in" 
...
 
 [1] could we have
   foreach(char a in str)
 instead of/in addition to
   foreach(char a; str)?
 It's not much longer, it's clearer, it doesn't seem to be ambiguous, and 
 it makes it completely obvious that the variable goes first, and the 
 container after.
 
 Sam

index of the end of the vector, or "dim", because it's the size of the dimension...Note that dim == end + 1. End is the last element's index, and dim is the count of elements. This word would be special only within an index...but that would make it a "serious warning" to use it as a variable, and perhaps it should be prohibited. Range is just too long. I suppose it's better than doing "arrayFoo[3..arrayFoo.size - 1]", but that leaves a lot of room for improvement.
Jul 07 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Charles Hixson wrote:

 Sam McCall wrote:
 Hmm, you do make a good point.
 Norbert Nemec wrote:
 

 A keyword sounds like the answer, three alternatives:
 1) Make "range" a keyword, and something like foo[2,range-1] would...

 2) Create a new keyword. Hard to find something short, descriptive, ...
  Maybe end?
 3) Cleverly reuse an existing keyword in an unambiguous way, like "in"
...
 
 [1] could we have
   foreach(char a in str)
 instead of/in addition to
   foreach(char a; str)?
 It's not much longer, it's clearer, it doesn't seem to be ambiguous, and
 it makes it completely obvious that the variable goes first, and the
 container after.
 
 Sam

index of the end of the vector, or "dim", because it's the size of the dimension...Note that dim == end + 1.

I actually prefer to use the term "dimension" with respect to the "number of dimension" that a multidimensional array has. Of course, this gets confusion, since a vector in tree-dimensional space would be a one-dimensional array of length 3 in that terminology. Anyhow: this confusion cannot be avoided but is just another sign showing how important a clear terminology is. I think, the cleanest solution actually is "length" - not very short, but readable, and together with the idea by Regan Heath to make the inside an indexing expression an implicit "with" environment, this fits very cleanly into the language.
Jul 07 2004
prev sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Norbert Nemec wrote:

 Ben Hinkle wrote:
 
 Sam McCall wrote:
 
 It's an interesting idea, but we'd lose the ability to catch some
 accidental out-of-bounds accesses, which is IMHO enough reason not to do
 it.
 
 Norbert Nemec wrote:
 Gowron wrote:
 The improved idea that was discussed lateron did appear in different
 variations. The version I liked most, was to introduce the symbol $ as
 a special symbol only within indexing expressions, meaning: the range
 of this dimension.
 
 This would allow you to write:
         a[1..$-1]
 instead of your suggestion.

we're going to need a nice way to get the nth dimension anyway. Sam

For multi-dim arrays .length could return the total number of elements and another property (for argument's sake call it "dims") could return a static array of the size of each dimension. Then length = dims[0] * dims[1] * ... * dims[N-1].

In my proposal, .length only exists for 1D-arrays. Here it is assignable with the magic of reallocating and copying the data if necessary. What you call "dims" is called .range in my proposal. It has itself the semantics of a fixed array of length N. Assigning to it is possible, but unsafe and without any magic (it boils down to assigning to the raw entries in the array-reference structure) The product of all ranges is implemented as a new, read-only property .volume The .size property equals .volume time the size of one entry.

sounds ok to me. I hadn't checked again with your proposal before posting. MATLAB uses "size" for dims/range and "numel" for length/volume
 Personally I'm not a huge fan of $ since the properties are more readable
 and general.

You are sure about "readable"? S1.A[2..S1.A.range[0]-1,2..S1.A.range[1]-1] = S2.B[2..S2.B.range[0]-1,2..S2.B.range[1]-1]; vs. S1.A[2..$-1,2..$-1] = S2.B[2..$-1,2..$-1];

yup - more verbose but to me more readable if I don't already know what $ means in D. Readability can be improved in the more verbose one by doing something like: int[2] end = S1.A.range; S1.A[2 .. end[0]-1, 2 .. end[1]-1] = S2.B[2 .. end[0]-1, 2 .. end[1]-1];
 And don't tell me this is constructed. I'm working with Matlab, where I
 have code like this all over the place.
 
 Of course, the $ is not very general, but be honest: the range of and
 array is used so often in indexing it, that it would really make sense to
 think about a reasonable shorthand.

It's true that MATLAB uses "end" - and even lets you override it in class definitions. But I honestly think $ won't be used as much in D as end is in MATLAB. A shorthand would be nice but it shouldn't stick out too much, I think. Using $ just looks like a random character thrown into the code.
 My only concern about $ is, that it really uses up one character that is
 so far unused and might find some much more important role sometimes in
 the future. (Just like # which we should really preserve until we find
 some worthy application for it.)

Jul 06 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Ben Hinkle wrote:

 MATLAB uses "size" for dims/range and "numel" for length/volume

True, but size is already taken for the physical size and "numel" - well probably just a matter of taste and getting used to it... I just think "volume" is easier to recognize.
 Readability can be improved in the more verbose one by doing
 something like:
  int[2] end = S1.A.range;
  S1.A[2 .. end[0]-1, 2 .. end[1]-1] =
     S2.B[2 .. end[0]-1, 2 .. end[1]-1];

 But I honestly think $ won't be used as much in D as end is
 in MATLAB.

That's nonsense. Of course - if you don't use arrays, you don't need to access their range. Proportionally, arrays in D will certainly never be as important as in Matlab, since the latter is specialized on them. But what you are effectivly saying is similar to: "D is not specialized on array handling, so why should we worry about sophisticated syntax for arrays? Anybody doing numerics or string handling will use arrays very intensely. And in all array-handling code, the density of range-accesses in indexing expressions certainly is just as high as in Matlab code...
 A shorthand would be nice but it shouldn't stick out too much,
 I think. Using $ just looks like a random character thrown into the code.

OK, forget about the "$" - how about that alternative proposal: "range" as an argumentless, unqualified indentifier defined only within indexing/slicing expressions. I don't know how it would fit into the parser to have this identifier stick out without being a keyword (maybe as argumentless function?) but there might be some simple way.
Jul 06 2004
parent reply Sam McCall <tunah.d tunah.net> writes:
Norbert Nemec wrote:

 Ben Hinkle wrote:
 
MATLAB uses "size" for dims/range and "numel" for length/volume

True, but size is already taken for the physical size

 and "numel" - well
 probably just a matter of taste and getting used to it... I just think
 "volume" is easier to recognize.

 OK, forget about the "$" - how about that alternative proposal: "range" as
 an argumentless, unqualified indentifier defined only within
 indexing/slicing expressions. I don't know how it would fit into the parser
 to have this identifier stick out without being a keyword (maybe as
 argumentless function?) but there might be some simple way.

think that in practice that would mean making it a keyword, because as a de facto variable it could shadow or at least cause ambiguity with local variables (which we can't currently disambiguate) if they are allowed to have the same name. I don't think making it a keyword is too harsh though, certainly no worse than in/out, and length/size/extent are all valid identifiers. Sam
Jul 06 2004
next sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Sam McCall wrote:

 Norbert Nemec wrote:
 
 Ben Hinkle wrote:
 
MATLAB uses "size" for dims/range and "numel" for length/volume

True, but size is already taken for the physical size


In D? Why that? The specs say nothing about that.
Jul 06 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 07 Jul 2004 02:03:59 +1200, Sam McCall <tunah.d tunah.net> wrote:
 Norbert Nemec wrote:

 Ben Hinkle wrote:

 MATLAB uses "size" for dims/range and "numel" for length/volume

True, but size is already taken for the physical size

 and "numel" - well
 probably just a matter of taste and getting used to it... I just think
 "volume" is easier to recognize.

 OK, forget about the "$" - how about that alternative proposal: "range" 
 as
 an argumentless, unqualified indentifier defined only within
 indexing/slicing expressions. I don't know how it would fit into the 
 parser
 to have this identifier stick out without being a keyword (maybe as
 argumentless function?) but there might be some simple way.

think that in practice that would mean making it a keyword, because as a de facto variable it could shadow or at least cause ambiguity with local variables (which we can't currently disambiguate) if they are allowed to have the same name. I don't think making it a keyword is too harsh though, certainly no worse than in/out, and length/size/extent are all valid identifiers.

I was thinking, if the scope inside [] was the scope of the array, then you could reference it's properties/methods without the name of the array, kinda like the 'with' block/statement does. The same sort of rules that apply to 'with' would apply to this. eg. char[] p; p[0..length]; Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 06 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsaqiouic5a2sq9 digitalmars.com...
 On Wed, 07 Jul 2004 02:03:59 +1200, Sam McCall <tunah.d tunah.net> wrote:
 Norbert Nemec wrote:

 Ben Hinkle wrote:

 MATLAB uses "size" for dims/range and "numel" for length/volume

True, but size is already taken for the physical size

 and "numel" - well
 probably just a matter of taste and getting used to it... I just think
 "volume" is easier to recognize.

 OK, forget about the "$" - how about that alternative proposal: "range"
 as
 an argumentless, unqualified indentifier defined only within
 indexing/slicing expressions. I don't know how it would fit into the
 parser
 to have this identifier stick out without being a keyword (maybe as
 argumentless function?) but there might be some simple way.

think that in practice that would mean making it a keyword, because as a de facto variable it could shadow or at least cause ambiguity with local variables (which we can't currently disambiguate) if they are allowed to have the same name. I don't think making it a keyword is too harsh though, certainly no worse than in/out, and length/size/extent are all valid identifiers.

I was thinking, if the scope inside [] was the scope of the array, then you could reference it's properties/methods without the name of the array, kinda like the 'with' block/statement does. The same sort of rules that apply to 'with' would apply to this. eg. char[] p; p[0..length];

nifty. I like it. I'm also starting to like "length" in place of "range" to be more like dynamic arrays. The length property for an n-dimensional dynamic array is a static array of the lengths in each dimension. Continuing your example: char[] p; p[0..length]; char[[2]] q; // proposed syntax for N-D dynamic arrays q[0..length[0], 0..length[1]] It looks very natural to me and nicely extends the existing dynamic array concept. The only technical challenge I can think of is that "with" blocks are statements and indexing expressions are expressions so some funky bridging might be needed inside the compiler.
 Regan

 -- 
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Jul 07 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Ben Hinkle wrote:

 I was thinking, if the scope inside [] was the scope of the array, then
 you could reference it's properties/methods without the name of the
 array, kinda like the 'with' block/statement does.

 The same sort of rules that apply to 'with' would apply to this.

 eg.

 char[] p;
 p[0..length];

nifty. I like it. I'm also starting to like "length" in place of "range" to be more like dynamic arrays.

One problem I see: for 1-dimensional arrays, range is of type int[1] while length is of type int - this was the original reason for introducing the new name "range". Furthermore, assignments to "range" are raw-assignments, while assignments to length contain the magic of reallocation. Maybe "range" takes a bit to get used to, but mixing it with the existing "length" property would really be oversimplifying a bit. Anyhow: for the problem at hand, "length" might actually do even better! If we follow that implicit "with" idea, everything would be fine for 1-dim arrays. For N-dim arrays (with N!=1), the ".length" does not exist, so we could do a bit more magic and introduce it within indexing expressions with an automatic index. Ben Hinkles example:
  char[] p;
  p[0..length];
  char[[2]] q; // proposed syntax for N-D dynamic arrays
  q[0..length[0], 0..length[1]]

would thereby be simplified to: char[] p; p[0..length]; char[[2]] q; // proposed syntax for N-D dynamic arrays q[0..length, 0..length] Effectivly, length would have become a replacement for the hated $ in the original idea. Intuitively understandable and with clean syntactic and semantic meaning (based on the implicit "with")
Jul 07 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:cchdjc$1gb9$1 digitaldaemon.com...
 Ben Hinkle wrote:

 I was thinking, if the scope inside [] was the scope of the array, then
 you could reference it's properties/methods without the name of the
 array, kinda like the 'with' block/statement does.

 The same sort of rules that apply to 'with' would apply to this.

 eg.

 char[] p;
 p[0..length];

nifty. I like it. I'm also starting to like "length" in place of "range" to be more like dynamic arrays.

One problem I see: for 1-dimensional arrays, range is of type int[1] while length is of type int - this was the original reason for introducing the new name "range".

oh - I think that's a benefit instead of a problem. :-) The type "char[]" is distinct from "char[[1]]". The type of the length property of the former is int and the latter is int[1]. Seems natural to me.
 Furthermore, assignments to "range" are raw-assignments, while assignments
 to length contain the magic of reallocation.

Yeah - it would be nice to allow code like char[[2]] q; q.length[0] = 4; q.length[1] = 5; and have it magically allocate space. I'd be willing to live with raw assignment, though.
 Maybe "range" takes a bit to get used to, but mixing it with the existing
 "length" property would really be oversimplifying a bit.

could be
 Anyhow: for the problem at hand, "length" might actually do even better!

 If we follow that implicit "with" idea, everything would be fine for 1-dim
 arrays. For N-dim arrays (with N!=1), the ".length" does not exist, so we
 could do a bit more magic and introduce it within indexing expressions

 an automatic index. Ben Hinkles example:

  char[] p;
  p[0..length];
  char[[2]] q; // proposed syntax for N-D dynamic arrays
  q[0..length[0], 0..length[1]]

would thereby be simplified to: char[] p; p[0..length]; char[[2]] q; // proposed syntax for N-D dynamic arrays q[0..length, 0..length] Effectivly, length would have become a replacement for the hated $ in the original idea. Intuitively understandable and with clean syntactic and semantic meaning (based on the implicit "with")

Jul 07 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Ben Hinkle wrote:

 
 "Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
 news:cchdjc$1gb9$1 digitaldaemon.com...
 Ben Hinkle wrote:

 I was thinking, if the scope inside [] was the scope of the array,
 then you could reference it's properties/methods without the name of
 the array, kinda like the 'with' block/statement does.

 The same sort of rules that apply to 'with' would apply to this.

 eg.

 char[] p;
 p[0..length];

nifty. I like it. I'm also starting to like "length" in place of "range" to be more like dynamic arrays.

One problem I see: for 1-dimensional arrays, range is of type int[1] while length is of type int - this was the original reason for introducing the new name "range".

oh - I think that's a benefit instead of a problem. :-) The type "char[]" is distinct from "char[[1]]". The type of the length property of the former is int and the latter is int[1]. Seems natural to me.

That's another way to see it. Good point. Actually, I chose the name "range" before that split was so clear cut. By now, it might really be obsolete.
 
 Furthermore, assignments to "range" are raw-assignments, while
 assignments to length contain the magic of reallocation.

Yeah - it would be nice to allow code like char[[2]] q; q.length[0] = 4; q.length[1] = 5; and have it magically allocate space. I'd be willing to live with raw assignment, though.

How about char[[2]] q = new char[4,5]; ? I never liked that assignment to .length for one-dimensional arrays too much, but I'm giving in more and more. Maybe I'll be convinced one day. There is plenty of time left before N-dim arrays have a chance to really get into the language, anyway... In any case: if length were to be a magic assignment, should the language provide raw assignment at all? Or should that be left to brute-force casting methods? Same thing with the .ptr which my proposal still contains. Without raw-writing, the .ptr should probably be dropped completely, since reading can just be done by a simple cast.
Jul 07 2004