View mode: basic / threaded / horizontal-split · Log in · Help
April 23, 2005
Re: How to bridge the gap between user defined types and built in
In article <d46t6k$1lja$1@digitaldaemon.com>, Brad Beveridge says...
>
>Christian Schüler wrote:
>> Just as I was expecting that a google search on "mathematical identity" would
>> turn up loads of examples, it fails on me...
>> 
>> The proper symbol for identity is really U+2261, "identity", a = with 3 dashes.
>> 
>> Besides that, I recall := being used in mathematical context for expressing
>> identity as opposed to equal values, which is what = stands for.
>> 
> From a practical programmers point of view, I don't think that the 
>operator we choose is particularly relevant.  I think that ":=" was 
>adopted because it has the "=" sign in it, it looks like an assignment 
>operation, and Pascal programmers will be familiar with it.
>I think it would be folly to try to use "=" for deep copy, and ":=" for 
>what we currently use "=" for.
>Anyhow - the real core of the issue is that many of us feel a "deep 
>copy" operator makes sense.
>
>Brad

What can you do with deep copy that you can't do with:

a = b.dup;

Or, do you mean "deeper" than that, as in, keep descending levels?  Or is
efficiency the primary reason to do a deep copy instead of that syntax?

Kevin
April 23, 2005
Re: How to bridge the gap between user defined types and built in
> 
> What can you do with deep copy that you can't do with:
> 
> a = b.dup;
> 
> Or, do you mean "deeper" than that, as in, keep descending levels?  Or is
> efficiency the primary reason to do a deep copy instead of that syntax?
> 
> Kevin
> 

Yes, I think that you should be able to override a function so that a 
deep copy descends levels.  But the primary problem with b.dup is that 
it doesn't work for built-in types.

Also in this discussion is the problem that you there is no way to fill 
out an object of type Foo from an object of type Bar, with C++ you could 
just override operator= so that
a = b;
would actually convert/copy b into a.

Cheers
Brad
April 23, 2005
Re: How to bridge the gap between user defined types and built in
As I pointed out in another thread, the following code doesn't work...

//_______________________________//
char[] source = "This is just for testing purposes.";
char[4] dest;
void main()
{
dest = source[8..12].dup;
assert(dest=="just");
}
//_______________________________//

So using .dup doesn't actually emulate a value assignment operator.

For clarification, in the following code...

//_______________________________//
char[] source = "This is just for testing purposes.";
char[4] dest;
void main()
{
dest := source[8..12];
assert(dest=="just");
}
//_______________________________//

the line...

dest := source[8..12];

...would mean set the contents of "dest" to the contents of "source[8..12]"

The value assignment operator would assign values.  Not identities.

If there are cases which Walter thinks are ambiguous, I would rather he simply leave no definition for the ":=" operator in those cases than to leave us without a value assignment operator over it... even if we're not given a way to be able to define the operator for those cases.

TZ




"Brad Beveridge" <brad@somewhere.net> wrote in message news:d4cp3i$v7c$1@digitaldaemon.com...
> >
> > What can you do with deep copy that you can't do with:
> >
> > a = b.dup;
> >
> > Or, do you mean "deeper" than that, as in, keep descending levels?  Or is
> > efficiency the primary reason to do a deep copy instead of that syntax?
> >
> > Kevin
> >
>
> Yes, I think that you should be able to override a function so that a
> deep copy descends levels.  But the primary problem with b.dup is that
> it doesn't work for built-in types.
>
> Also in this discussion is the problem that you there is no way to fill
> out an object of type Foo from an object of type Bar, with C++ you could
> just override operator= so that
> a = b;
> would actually convert/copy b into a.
>
> Cheers
> Brad
April 24, 2005
Re: How to bridge the gap between user defined types and built in
TechnoZeus wrote:
> As I pointed out in another thread, the following code doesn't work...
> 
> //_______________________________//
> char[] source = "This is just for testing purposes.";
> char[4] dest;
> void main()
> {
>  dest = source[8..12].dup;
>  assert(dest=="just");
> }
> //_______________________________//
> 
> So using .dup doesn't actually emulate a value assignment operator.

It was already answered: this is almost as trying to change a const.

> 
> For clarification, in the following code...
> 
> //_______________________________//
> char[] source = "This is just for testing purposes.";
> char[4] dest;
> void main()
> {
>  dest := source[8..12];
>  assert(dest=="just");
> }
> //_______________________________//
> 
> the line...
> 
>  dest := source[8..12];
> 
> ....would mean set the contents of "dest" to the contents of "source[8..12]"

Also already answered: dest[] = source[8..12]

-- 
Carlos Santander Bernal
April 24, 2005
Re: Comments on the proposed value assignment opperator [:=]
That's important too.  :)  Much appriated, of course.

TZ

"Vladimir" <kv11111@mail.ru> wrote in message news:d4bsfo$9j3$1@digitaldaemon.com...
> 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 24, 2005
Re: Comments on the proposed value assignment opperator [:=]
Ironically, since the "@" symbol is usually pronounced "at" (in English at least) it would have been a nice choice for an address operator, to tell where something is at.  Hehe.  Oh well... too late to change history.  We can get used to it.  :)

TZ

"Derek Parnell" <derek@psych.ward> wrote in message news:pqibzzcik9ez$.1nw19ysr1xxya$.dlg@40tude.net...
> 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 24, 2005
Re: Comments on the proposed value assignment opperator [:=]
Any binary operator could be made to act unary,
as long as the operator isn't restricted to being commutative.

As a crude example,
int a;
int b;
a + -b; // add negative b to a.
a - b; // subtract b from a.
a + (0-b); Much like "a + -b;" the subtraction doesn't need to know about "a" in this case.

TZ

"Brad Beveridge" <brad@somewhere.net> wrote in message news:d4c64h$goe$1@digitaldaemon.com...
> 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 24, 2005
Re: How to bridge the gap between user defined types and built in
"Carlos Santander B." <csantander619@gmail.com> wrote in message news:d4evp8$2qpv$1@digitaldaemon.com...
> TechnoZeus wrote:
> > As I pointed out in another thread, the following code doesn't work...
> >
> > //_______________________________//
> > char[] source = "This is just for testing purposes.";
> > char[4] dest;
> > void main()
> > {
> >  dest = source[8..12].dup;
> >  assert(dest=="just");
> > }
> > //_______________________________//
> >
> > So using .dup doesn't actually emulate a value assignment operator.
>
> It was already answered: this is almost as trying to change a const.
>
> >
> > For clarification, in the following code...
> >
> > //_______________________________//
> > char[] source = "This is just for testing purposes.";
> > char[4] dest;
> > void main()
> > {
> >  dest := source[8..12];
> >  assert(dest=="just");
> > }
> > //_______________________________//
> >
> > the line...
> >
> >  dest := source[8..12];
> >
> > ....would mean set the contents of "dest" to the contents of "source[8..12]"
>
> Also already answered: dest[] = source[8..12]
>
> -- 
> Carlos Santander Bernal

That's not an answer.  It's a work-around.

dest is an array, in that example, not a pointer.
It should be possible to assign the contents of an array to an array.

I like the way it is handled with the "=" operator, overall, but
my point is that .dup doesn't change what you're working with into
something that acts like a value type,
so the "=" operator thinks you want to change the destination
to point to the contents of the duplicate.

A value assignment operator wouldn't have to "figure out"
whether you wanted to change the value or the identity of
the destination operand.

TZ
April 24, 2005
Re: Comments on the proposed value assignment opperator [:=]
"Vladimir" <kv11111@mail.ru> wrote in message news:d4bsfo$9j3$1@digitaldaemon.com...
> Brad Beveridge wrote:
*snip*
> It's just my test how can it be done.
>
> -- 
>           Vladimir

Sorry.  I should snipped the quote.
What I meant to say was...
testing how it can be done is important.
Thanks for doing that.  It's very much appreciated.

TZ
April 24, 2005
Re: How to bridge the gap between user defined types and built in
On Sat, 23 Apr 2005 23:41:30 -0500, TechnoZeus wrote:

> "Carlos Santander B." <csantander619@gmail.com> wrote in message news:d4evp8$2qpv$1@digitaldaemon.com...
>> TechnoZeus wrote:
>>> As I pointed out in another thread, the following code doesn't work...
>>>
>>> //_______________________________//
>>> char[] source = "This is just for testing purposes.";
>>> char[4] dest;
>>> void main()
>>> {
>>>  dest = source[8..12].dup;
>>>  assert(dest=="just");
>>> }
>>> //_______________________________//
>>>
>>> So using .dup doesn't actually emulate a value assignment operator.
>>
>> It was already answered: this is almost as trying to change a const.
>>
>>>
>>> For clarification, in the following code...
>>>
>>> //_______________________________//
>>> char[] source = "This is just for testing purposes.";
>>> char[4] dest;
>>> void main()
>>> {
>>>  dest := source[8..12];
>>>  assert(dest=="just");
>>> }
>>> //_______________________________//
>>>
>>> the line...
>>>
>>>  dest := source[8..12];
>>>
>>> ....would mean set the contents of "dest" to the contents of "source[8..12]"
>>
>> Also already answered: dest[] = source[8..12]
>>
>> -- 
>> Carlos Santander Bernal
> 
> That's not an answer.  It's a work-around.

Are doing this deliberately? 

That is not a work around. It is the way to do it.

> dest is an array, in that example, not a pointer.
Yes, and 'source' is not an array, it is a dynamic array reference. 

> It should be possible to assign the contents of an array to an array.

It is.  And the way one does it is to specify which elements of the target
array you are updating. The syntax 'target[]' is shorthand for
'target[0..$]'.

Even in the case where the target is a dynamic array, 

  target = source; 

does not update the target array elements, it makes target point to the
same array as source. To update the elements you still need to do

target[] = source;


> I like the way it is handled with the "=" operator, overall, but
> my point is that .dup doesn't change what you're working with into
> something that acts like a value type,

Of course not. The .dup just takes a copy. 

> so the "=" operator thinks you want to change the destination
> to point to the contents of the duplicate.

Yes, because that's what you told it to do via the 'target = source;'
statement. If you wanted to update all the elements in target, you need to
use the correct syntax... 'target[] = source'

> A value assignment operator wouldn't have to "figure out"
> whether you wanted to change the value or the identity of
> the destination operand.

You seem to be saying, that you wish ':=' to be an alternative syntax to
update all the elements in an array, based on the elements in the source.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
24/04/2005 8:50:16 PM
7 8 9 10 11 12
Top | Discussion index | About this forum | D home