Regan Heath wrote:

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

The key difference is that "with" is a statement and we need it in an
expression. Maybe there is some way to make "with" useful in expressions.
Thinking off the top of my head we could use "with" as similar to "this":
 e[with.length-4 .. with.length]

In other words inside an expression "with" evaluates to the containing
array, class or struct reference. The second two uses come in handy for
handling overloaded indexing and slicing expressions. For example if
some_long_expression evaluates to an object reference "ref", then
 some_long_expression[0 .. with.length]
is equivalent to
 ref.opSlice(0,ref.length)

I don't know if parsing "with.foo" expressions conflicts with parsing "with{}" statements but if not it could be a fairly general construct.

-Ben

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

Will this work?

with (array)
{
    return this[0..3];
}

But if part of the reason for this feature was to save keystrokes (which I gather since with could do the same), then its no replacement. Not that I particularly like the feature in its current form. :-)

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

Just a general statement that using it for this purpose may preclude other uses for it. It is, after all, conceivable that more broad uses of it could be found. But as you say, it could have multiple meanings depending on context, if you like that.

On Wed, 1 Sep 2004 02:02:23 +0200, Bent Rasmussen <exo@bent-rasmussen.info> wrote:
>> This one, we *already* have this feature. :)
>> Lets just remove the length feature.
>
> Will this work?
>
> with (array)
> {
>     return this[0..3];
> }

actually no, not currently, I get "with expressions must be class objects, not 'char[]'" but I cannot see the reason to restrict it like this, in fact why not:

int i;
with(i) {
  printf("%d",sizeof);
}

> But if part of the reason for this feature was to save keystrokes (which I gather since with could do the same), then its no replacement. Not that I
> particularly like the feature in its current form. :-)

I think the reason was...

<quote source="Walter">
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.
</quote>

Regan

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

On Tue, 31 Aug 2004 23:46:25 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
> 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...

Currently this:

class A {
  int i;
  this(int _i) { i = _i; }
}

void main()
{
  A a = new A(5);
  int i;

  with(a) {
    printf("%d",i);
  }
}

compiles, runs and prints 5 (as you'd expect) but I would rather get a compile error saying "with(a) hides 'i' from enclosing scope" or something similar. To then have to either:
 - rename the 'int i' in the enclosing scope
 - rename the 'int i' in the class
 - explicitly reference the class 'i' as in:
   with(a) {
     printf("%d",this.i);
   }

to solve it. The only problem being, what if you meant the i from the enclosing scope? maybe .main.with.i? what if you have a with within a with? .main.with.with.i? ...

Regan

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

On Tue, 31 Aug 2004 20:02:01 -0400, Ben Hinkle <bhinkle4@juno.com> wrote:
> Regan Heath wrote:
>
>> 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
>>
>
> The key difference is that "with" is a statement and we need it in an
> expression.

Do we? can you give me an example?

> Maybe there is some way to make "with" useful in expressions.
> Thinking off the top of my head we could use "with" as similar to "this":
>  e[with.length-4 .. with.length]
>
> In other words inside an expression "with" evaluates to the containing
> array, class or struct reference. The second two uses come in handy for
> handling overloaded indexing and slicing expressions. For example if
> some_long_expression evaluates to an object reference "ref", then
>  some_long_expression[0 .. with.length]
> is equivalent to
>  ref.opSlice(0,ref.length)
>
> I don't know if parsing "with.foo" expressions conflicts with parsing
> "with{}" statements but if not it could be a fairly general construct.

Not a bad idea..

Regan

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

On Wed, 1 Sep 2004 01:55:45 +0200, Bent Rasmussen <exo@bent-rasmussen.info> wrote:
>> 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.

I think this is less immediately clear than a 'with' construct would be.

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

I think if you can generalise at no cost, then why not. After all no-one can think of everything someone is going to want to do.

I'd draw the line if you're creating several ways to do the same thing, as I think that is a bad thing.

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

with(e) {
  ..do stuff with e, reference e with 'this'..
}

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

even if 'e' is a really long templated expression, or a method call or function returning an array?

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

I agree.

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

I'd like to hear this idea too.

Regan


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

>> The key difference is that "with" is a statement and we need it in an expression.
> 
> Do we? can you give me an example?

the things inside the brackets must be expressions. For example in e[length - 4 .. length] both "length-4" and "length" are expressions. You can't put a statement where D expects an expression.

Since that slice expression might appear deep inside another expression it can be slightly painful to rewrite it all into a with statement.

I was surprised that Walter added this "length" sugar but it did generate some excitement before.

In article <ch2qm2$186l$1@digitaldaemon.com>, Bent Rasmussen says...
>
>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]

I, for one, love the above syntax simply because it cannot be confused for anything else but what its for.  Also, the python-esque negative indicies would also work very well for further reducing the need for referencing 'length' in a slice operation.

As nice a shortcut 'length' is in a slice, I have to put my $0.02 in that it hurts more than it helps in a lot of cases.  It also leads to some very ambiguous code if 'length' is declared elsewhere in the same scope as the slice operation. :(

Walter, thank you for making strides in adding all these great features to this language.  With all due respect, I'm looking forward to V0.102. :)

- Pragma
EricAnderton at (sig[0..]) yahoo dot com

On Wed, 1 Sep 2004 02:25:17 +0000 (UTC), pragma wrote:

> In article <ch2qm2$186l$1@digitaldaemon.com>, Bent Rasmussen says...
>>
>>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]
> 
> I, for one, love the above syntax simply because it cannot be confused for anything else but what its for.  Also, the python-esque negative indicies would also work very well for further reducing the need for referencing 'length' in a slice operation.

Using this scheme, how does one specify the 2nd last element, such as e[i..length-1]?

> As nice a shortcut 'length' is in a slice, I have to put my $0.02 in that it hurts more than it helps in a lot of cases.  It also leads to some very ambiguous code if 'length' is declared elsewhere in the same scope as the slice operation. :(

Agreed.

> Walter, thank you for making strides in adding all these great features to this language.

Agreed (with cherries on top).

>  With all due respect, I'm looking forward to V0.102. :)

I'm looking forward to v1.0  ;-)


-- 
Derek
Melbourne, Australia
1/Sep/04 2:31:09 PM