April 22, 2005
Yep.

TZ

"Brad Beveridge" <brad@somewhere.net> wrote in message news:d494bj$qho$1@digitaldaemon.com...
>
> >> The problem with your example in this argument is that it's ambiguous.
> >>
> >> b := a+7
> >>
> >> Does it mean "take the actual value of the lvalue"?
> >
> >
> > It means call: b.opAssign(a+7);
> >
> > Regan
>
> Which, is exactly the same as regular "=" precidence, ie the assignment operation always happens last.
>
> Brad


April 22, 2005
"xs0" <xs0@xs0.com> wrote in message news:d48tfo$k26$1@digitaldaemon.com...
>
>
> Hmm, isn't there a problem that if you do
>
> func(T a)
> {
>      T b:=a;
> }
>
> b is null if T is reference-type, so it can't even have the value assigned? You can't explicitly new it, because that wouldn't work with primitive types again.
>
> It could get automatically allocated, but that'd require the class to have a zero-parameter constructor, which may again break, and in fact, calling it may cause unforeseen effects.
>

No, there's no problem with it at all.  You're thinking in C.

TZ


April 22, 2005
No, if the variable is uninitialized and a value is assigned, then assigning that value "is" the initialization.  You don't just throw a copy of the value where-ever the unitinitialized reference type happens to be pointing to. an implicit "new" would alocate the space for it.

The idea is to make a value assignment operator that works with both value and reference types, not to make one that works with value types and fails to accomodate reference types.  That wouldn't be any improvement over what we have now.

TZ

"xs0" <xs0@xs0.com> wrote in message news:d49aeq$1047$1@digitaldaemon.com...
>
> >>Hmm, isn't there a problem that if you do
> >>
> >>func(T a)
> >>{
> >>     T b:=a;
> >>}
> >>
> >>b is null if T is reference-type, so it can't even have the value assigned? You can't explicitly new it, because that wouldn't work with primitive types again.
> >>
> >>It could get automatically allocated, but that'd require the class to have a zero-parameter constructor, which may again break, and in fact, calling it may cause unforeseen effects.
> >
> > Please, look at my post in different branch of this thread: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/22165
>
> With .init on classes:
> - all uninitialized vars of a class will point to the same object
> - using := with any of them will change all the others
> - so, even trivial code like
>
> func(T a, T b)
> {
> T c:=a+b;
> T d:=a*b;
>
> return c/d;
> }
>
> will totally not work, because after the second line, c will have the same value as d, so the result will always be the same (1, assuming some normal numeric class). In a multithreaded app, things will get even uglier, because c and d may get modified from outside, which is not the case with =.
>
>
> xs0


April 22, 2005
:= wouldn't assign the value of a struct pointed to by it's right operand.  It would assign the value of it's right operand.  Even if that operand is a pointer, in which case it's value is the address of the location that it points to.  Not the data stored at that location.

In other words, no it wouldn't have the same problem.

TZ

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d48sn8$jbq$1@digitaldaemon.com...
>
> "pragma" <pragma_member@pathlink.com> wrote in message news:d48dib$57l$1@digitaldaemon.com...
> > In article <d46v3g$1n7o$1@digitaldaemon.com>, Ben Hinkle says...
> >>
> >>About the template problem: I'd prefer to look into something like
> >>extending
> >>".dup" to all types rather than invent a new operator.
> >
> > Ben, thank you.  You took the words right out of my mouth. :)
> >
> > For classes, there's no need to make this a formal 'operator'.  It could
> > merely
> > be added to Object as a shallow copy (return this;) and then overridden in
> > any
> > class where it's needed.
> >
> > So really, all that's needed is a 'dup' property for scalars.  The rest is
> > up to
> > the developer.
> [snip]
>
> One issue with .dup is that the expression x.dup calls the same thing if x is a struct or a ptr to a struct. Not that I'm complaining since I don't think the := does any better wrt pointers. In general I'm not optimistic about either := or .dup helping template programming by themselves. I'd like to see more motivating examples of what the problems are and what the workarounds look like. Sometimes the cure is worse than the disease.
>
>


April 22, 2005
pragma wrote:

> In article <d48pet$g4d$1@digitaldaemon.com>, Vladimir says...
>>
>>> Not that I think it's a good idea, but you could use something like '@' to mean 'value-of' (which would be akin to '&' meaning 'address-of').
>>> 
>>> { return @a; }
>>>
>>> This isn't too bad, but it still lands us in "create a new operator territory".
>>But what is so fundamental difference between "create a new property for fundamental data type" and "create a new operator" ?
> 
> Largely, the compiler impact is the biggest difference; a universal dup() property won't require anything new in the lexer and will likely be easily attached to the property evaluation bits already present.  Adding a ':=' operator requires changes to the lexer, and a expression handling branch, with quirks and rules all its own.
All these changes are trivial. I've done a patch for gdc-0.10 to allow
discussed above '@' operator, and it takes me about one hour. I've never
seen gdc sources before, so I belive for Walter it takes not more than five
minutes.
Adding ':=' will be more difficult, but I like challenges.

> IMO, adding ':=' would be much more work to do, and not worth it since D has already (partially) sovled the problem.


> 
> There is a smaller impact to D's grammar is a close second as ':=' is somewhat ambiguous when applied to certain cases; I'm welcome to be wrong about that. Regardless, .dup() is wholly unambiguous and meshes well with the present design.
> 
>>
>>> 
>>> I still think .dup() is the way to go.
>>For me it's just harder to type that @.
>>The only thing is that having @ operator it's too big tempting to allow T@
>>for creating class-value-type, which Walter will never accept, wont
>>he ? :-)
> 
> Probably not.  Again, I'd be willing to bet that extending .dup to everything would be cake to implement by comparison.
> 
> - EricAnderton at yahoo

-- 
          Vladimir

April 22, 2005
Vladimir - can you please explain the new behaviour of your patch?
From looking at the patch, it appears that when you type
@object it gets translated into object.opValue() - is this correct?
Does the @ operator handle built-in types?

I think this is great work, now if we could just figure out a way to convert from one type to another, such as
Foo a = new Foo();
Bar b = new Bar();
b := a;

then most issues raised in this discussion would be solved (I think)

Brad
April 22, 2005
Brad Beveridge wrote:

> Vladimir - can you please explain the new behaviour of your patch?
>  From looking at the patch, it appears that when you type
> @object it gets translated into object.opValue() - is this correct?
Correct.
But may be we need some default behavior here, such as recursively apply @
for all members stopping at built-in types.

> Does the @ operator handle built-in types?
Yes, but not arrays yet.

> I think this is great work, now if we could just figure out a way to
> convert from one type to another, such as
> Foo a = new Foo();
> Bar b = new Bar();
> b := a;
I have an idea about it, I'll try when I'll find a new piece of free time.

> then most issues raised in this discussion would be solved (I think)
Does not take is so serious :-) I just like to play with code :-)
It is not in D trunk and may be never get there. It's just my test how can
it be done.

> Brad

-- 
          Vladimir
April 23, 2005
On Sat, 23 Apr 2005 08:35:18 +1200, Brad Beveridge wrote:

> Vladimir - can you please explain the new behaviour of your patch?
>  From looking at the patch, it appears that when you type
> @object it gets translated into object.opValue() - is this correct?
> Does the @ operator handle built-in types?
> 
> I think this is great work, now if we could just figure out a way to
> convert from one type to another, such as
> Foo a = new Foo();
> Bar b = new Bar();
> b := a;
> 
> then most issues raised in this discussion would be solved (I think)

This '@' proposal is the one that I'm liking the most so far.

In other words use '&' to get something's RAM address, and use '@' to get something's value. For things that support methods, the '@' could translate to a call to the things opValue() method. For things that do not support methods, it would invoke opValue_r() if defined otherwise, its identical to the current D behaviour for casting. Of course, if the undocumented syntax relating to arrays is propagated to all types (see last example below), we could really have a useful programming construct.

 Foo a = new Foo();
 Bar b = new Bar();
 int c;
 real d;
 char[] e;

 b = @a;  // b.opValue(a);
 a = @b;  // a.opValue(b);
 c = @b;  // b.opValue_r(inout c);
 c = @d;  // c = cast(int)d;
 a = @d;  // a.opValue(d);
 e = @a;  // a.opValue_r(inout e);
 d = @e;  // d = opValue(in d, e);

This idea would work for all things making it suitable for template usage too.

-- 
Derek Parnell
Melbourne, Australia
23/04/2005 10:27:19 AM
April 23, 2005
Derek Parnell wrote:
> On Sat, 23 Apr 2005 08:35:18 +1200, Brad Beveridge wrote:
> 
> 
>>Vladimir - can you please explain the new behaviour of your patch?
>> From looking at the patch, it appears that when you type
>>@object it gets translated into object.opValue() - is this correct?
>>Does the @ operator handle built-in types?
>>
>>I think this is great work, now if we could just figure out a way to convert from one type to another, such as
>>Foo a = new Foo();
>>Bar b = new Bar();
>>b := a;
>>
>>then most issues raised in this discussion would be solved (I think)
> 
> 
> This '@' proposal is the one that I'm liking the most so far.
> 
> In other words use '&' to get something's RAM address, and use '@' to get
> something's value. For things that support methods, the '@' could translate
> to a call to the things opValue() method. For things that do not support
> methods, it would invoke opValue_r() if defined otherwise, its identical to
> the current D behaviour for casting. Of course, if the undocumented syntax
> relating to arrays is propagated to all types (see last example below), we
> could really have a useful programming construct.
> 
>  Foo a = new Foo();
>  Bar b = new Bar();
>  int c;
>  real d;
>  char[] e;
> 
>  b = @a;  // b.opValue(a);
>  a = @b;  // a.opValue(b);
>  c = @b;  // b.opValue_r(inout c);
>  c = @d;  // c = cast(int)d;
>  a = @d;  // a.opValue(d);
>  e = @a;  // a.opValue_r(inout e);
>  d = @e;  // d = opValue(in d, e);
> 
> This idea would work for all things making it suitable for template usage
> too. 
> 
The @ operator is currently unary, so there really is no notion of opValue_r() - at least as I understand it.  Ie, this suffers the same problem that the cast operator does - because it is unary there is no notion of the LHS.
Is it possible to have an operator that is both unary and binary - depending on context?  I can't think how.

Brad
April 23, 2005
> The @ operator is currently unary, so there really is no notion of opValue_r() - at least as I understand it.  Ie, this suffers the same problem that the cast operator does - because it is unary there is no notion of the LHS.
> Is it possible to have an operator that is both unary and binary - depending on context?  I can't think how.
> 
> Brad
Poor form answering my own question, perhaps we should add @= as an operator, which will call opValue with a parameter
@a -- calls a.opValue()
a @= b -- calls a.opValue(b), or b.opValue_r(a)

Since if you think about it, a conversion must create a new object.

Brad