"Bent Rasmussen" <exo@bent-rasmussen.info> wrote in message news:ch2qm2$186l$1@digitaldaemon.com...
> Nice, but it doesn't scale as well.  The 'length' keyword lets us do things like
>
>     e[length - 4 .. length]
>
> Python evades this problem by shamelessly disregarding runtime performance and interpreting negative subscripts as being taken from the end.  D doesn't have that option. :)

I see and that argument ties in with Walters argument. If it were not for that argument I would say  that it is no big deal because it doesn't have to scale, as far as I can see; but that's a matter of oppinion. Its also possible to do the other way around, although with near no benefit except symmetry (I'm a sucker for that though)

e[i..]
e[..j]
e[i..j]

It boils down to having something short that stands for length. It could be some special symbol of course, but who wants to sacrifice $ for such a purpose

e[..$]
e[..$-c]

=================================

But all of this is strictly for array lengths. What happens, for example, if you need to apply the other properties of array? Say, .sort, or .sizeof ? Now you've got to start exposing all of these names in the same manner as the [length] thing we're discussing. Not good.

And again, this is only for expressions returning arrays. What about all the other kinds of expressions you might wish to handle in the general case? You still have to do things the original way (with all the potential for side-effects) for each of those.

If there were a means of rewriting:

# e[length - 4 .. length]

as

# tmp = e
# tmp [tmp.length-4 .. tmp.length]

then this special-case 'length' scenario would go away, and the whole thing would become more powerful (and symmetrical), since you could handle all the other non-array cases in the same manner. Trying to do too much in a single expression is unwieldly and error-prone. Perhaps that's why functions and subroutines were invented :-)

Makes you wonder whether literal functions could take care of this instead ...

In article <ch2rt3$18um$1@digitaldaemon.com>, antiAlias says...
>
>
>But all of this is strictly for array lengths. What happens, for example, if you need to apply the other properties of array? Say, .sort, or .sizeof ? Now you've got to start exposing all of these names in the same manner as the [length] thing we're discussing. Not good.

Perhaps all parameters of a type should be implicitly accessible in the subscript expression?  The only issue then becomes visibility of other variables.  It would mean another keyword, but you could do something like this:

# void func()
# {
#     int length;
#     char[] array;
#     array[0..length]; // references array.length
#     array[0..local.length]; // references int length
# }

I'll admit it's kind of ugly and I don't like the keyword I've chosen, but if the goal truly is to simplify expressions with anonymous types then it seems a reasonable approach.


Sean

On Tue, 31 Aug 2004 11:57:03 -0700, Walter <newshound@digitalmars.com> wrote:
> "antiAlias" <fu@bar.com> wrote in message
> news:ch2fml$126h$1@digitaldaemon.com...
>> Mango was bitten by it too. The silent bugs are a glaring minefield, so
>> something has to change. Frankly, there was nothing wrong with how it was
>> before; e.g.
>>
>> char[] substring = text [index .. text.length];
>>
>> What's wrong with being explicit about where the 'length' property is
> coming
>> from? Introducing this new 'special case' within the bounds of a [] pair
>> provides no tangible value to the programmer, and is an impediment to
>> catching subtle bugs.
>>
>> Permit me to ask the obvious question: why was this changed in the first
>> place?
>
> It's a problem for things like:
>
>     e[0..e.length]
>
> when e is an arbitrarilly complex expression with side effects. For example,
> e could be a function returning an array. Or a template instantiation. Or a
> combination of the two.

So isn't the 'with' idea the best solution eg.

void foo() {
  with(methodReturningAnArray(..complex set of parameters..)) {
    this[1..length];
  }
}

in the above 'this' is used to reference the array, as in a class method, 'length' refers to this.length.

The same error checking which is used (I assume) for class methods, scope blocks, and normal with statements should be applied. eg

void foo() {
  int length;
  with(methodReturningAnArray(..complex set of parameters..)) {
    this[1..length];   //error: this.length or outer 'int length'?
  }
}

Regan

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

On Tue, 31 Aug 2004 14:54:55 -0700, antiAlias <fu@bar.com> wrote:

<snip>

> If there were a means of rewriting:
>
> # e[length - 4 .. length]
>
> as
>
> # tmp = e
> # tmp [tmp.length-4 .. tmp.length]

Isn't that what 'with' is for? I quote...

http://www.digitalmars.com/d/statement.html#with

"The with statement

with (expression)
{
    ...
    ident;
}

is semantically equivalent to:

{
    Object tmp;
    tmp = expression;
    ...
    tmp.ident;
}"

Regan

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

Vathix wrote:

>> > I think it should be an error to declare something with the name length,
>> so
>> > that you catch these mistakes easily. length is a popular name.
>>
>> I was bitten by that in recompiling Phobos, too. But I'm a bit reluctant
> to
>> make it a keyword as it is popular.

I was the only one to grep for length in my code before upgrading?


> How about a vote?
>    1) Leave it how it is now; having all these silent bugs and possible
> future misunderstandings.
Ugly, but easy to fix (grep and not declaring anything with the length
name).

>    2) Make it an error to declare something with the name 'length'.
This makes sense to me.

In article <opsdmc4bd65a2sq9@digitalmars.com>, Regan Heath says...
>
>On Tue, 31 Aug 2004 14:54:55 -0700, antiAlias <fu@bar.com> wrote:
>
><snip>
>
>> If there were a means of rewriting:
>>
>> # e[length - 4 .. length]
>>
>> as
>>
>> # tmp = e
>> # tmp [tmp.length-4 .. tmp.length]
>
>Isn't that what 'with' is for? I quote...
>
>http://www.digitalmars.com/d/statement.html#with

Egads, I'd totally forgotten that D already had this feature.  In light of that, I think the special case for length should probably be removed.


Sean

On Tue, 31 Aug 2004 13:49:37 -0400, Vathix <vathixSpamFix@dprogramming.com> wrote:
>    3) Replace the feature with:  with(array)statement

This one, we *already* have this feature. :)
Lets just remove the length feature.

Regan

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

In article <opsdmc1c065a2sq9@digitalmars.com>, Regan Heath says...
>
>So isn't the 'with' idea the best solution eg.
>
>void foo() {
>   with(methodReturningAnArray(..complex set of parameters..)) {
>     this[1..length];
>   }
>}
>
>in the above 'this' is used to reference the array, as in a class method, 'length' refers to this.length.

This is probably the best general solution, but I don't think the meaning of 'this' should be changed.  I'm inclined to want to allow declarations inside a with block, but then the problem becomes how the type should be determined. Maybe the current solution isn't so bad after all...


Sean

> But all of this is strictly for array lengths. What happens, for example,
> if
> you need to apply the other properties of array? Say, .sort, or .sizeof ?
> Now you've got to start exposing all of these names in the same manner as
> the [length] thing we're discussing. Not good.

That assumes you want to do that; I wouldn't. I don't see the problem with a temporal for such things; in fact I'd prefer the e[i..] and e[..i] syntax without any implicit temporal generation.

The general syntax should be okay for most cases but its a matter of preference where to draw the line here. But just because something can be generalized doesn't mean it should be.

> And again, this is only for expressions returning arrays. What about all
> the
> other kinds of expressions you might wish to handle in the general case?
> You
> still have to do things the original way (with all the potential for
> side-effects) for each of those.
>
> If there were a means of rewriting:
>
> # e[length - 4 .. length]
>
> as
>
> # tmp = e
> # tmp [tmp.length-4 .. tmp.length]

temporal(e)[length - 4 .. length] // semi-yuck

> then this special-case 'length' scenario would go away, and the whole
> thing
> would become more powerful (and symmetrical), since you could handle all
> the
> other non-array cases in the same manner. Trying to do too much in a
> single
> expression is unwieldly and error-prone. Perhaps that's why functions and
> subroutines were invented :-)

I don't think e.g. e[i..] is unwieldly, nor e[0..length-5] although I almost prefer not having length get special treatment (as per the current implementation) because of name confusion and as you say/imply, the old explicit syntax/semantics can be more readable; again though, I see e[i..] as quite readable.

But I definitely would not like to have the current practice of implicit qualification of length expanded/generalized to other properties/functions. Perhaps its an unjustified worry, but it doesn't feel that "clean" to me.

> Makes you wonder whether literal functions could take care of this instead

Let's not get carried away here; unless you have something cool up your sleeve. :-)

> ...

On Tue, 31 Aug 2004 23:30:46 +0200, Bent Rasmussen wrote:

>> Nice, but it doesn't scale as well.  The 'length' keyword lets us do things like
>>
>>     e[length - 4 .. length]
>>
>> Python evades this problem by shamelessly disregarding runtime performance and interpreting negative subscripts as being taken from the end.  D doesn't have that option. :)
> 
> I see and that argument ties in with Walters argument. If it were not for that argument I would say  that it is no big deal because it doesn't have to scale, as far as I can see; but that's a matter of oppinion. Its also possible to do the other way around, although with near no benefit except symmetry (I'm a sucker for that though)
> 
> e[i..]
> e[..j]
> e[i..j]
> 
> It boils down to having something short that stands for length. It could be some special symbol of course, but who wants to sacrifice $ for such a purpose
> 
> e[..$]
> e[..$-c]

Me. What sacrifice? We already have '*' for multiplication and pointers, depending on context. Its short. Its not currently used. It has precedence (regular expressions). It doesn't clash with used-defined identifiers. It only has this meaning within [].


-- 
Derek
Melbourne, Australia
1/Sep/04 9:55:25 AM