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.

http://www.digitalmars.com/drn-bin/wwwnews?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.


Hmm, for normal arrays have array.length, for multidimensional arrays, 
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.


 Hmm, for normal arrays have array.length, for multidimensional arrays,
 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.


 Hmm, for normal arrays have array.length, for multidimensional arrays,
 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

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

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

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

 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.
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

 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!

* 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

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!


Yes, I was thinking a keyword, simply because (assuming a name like 
"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.


Personally, I think that's far more ugly - a function that doesn't obey 
scoping rules?


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


I agree with you, but the point is, _directly_ 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:
 


..., 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...



 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


Either "end" or "dim" would get my vote.  "end", because it's the 
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:
 


 ..., 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...


 

 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


 Either "end" or "dim" would get my vote.  "end", because it's the
 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.


 Hmm, for normal arrays have array.length, for multidimensional arrays,
 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

 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


It's deprecated (and gives a fatal error IIRC?)


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


Volume is nice, I like the metaphor.


 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.


If it is going to be used in this way (which I think is a good idea), I 
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


 It's deprecated (and gives a fatal error IIRC?)


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


 It's deprecated (and gives a fatal error IIRC?)


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


 Volume is nice, I like the metaphor.


 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.


 If it is going to be used in this way (which I think is a good idea), I 
 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


 It's deprecated (and gives a fatal error IIRC?)


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


 Volume is nice, I like the metaphor.


 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.


 If it is going to be used in this way (which I think is a good idea), I
 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


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 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