One final(ish) push for :=

I have suggested that "a := b;" be rewritten by the compiler as "a = new A(b)". I'm told that this would be merely syntactic sugar.

Well yeah, it is. But the phrase "syntactic sugar" is a loaded phrase, implying "bad thing". The fact is that we can write "a = b + c" instead of "a = b.opAdd(c)", and we LIKE it. Syntactic sugar is sometimes nice.

It's a very simple idea:

>       a = b;      // copy by reference
>       a := b;     // copy by value

This syntactic sugar would ALSO allow you to things like:

>       Int n := 5;

(Int is my big integer class) instead of:

>       Int n = new Int(5);

That sugary code is much more /smooth/. It /flows/.

If no-one likes this idea, I'll drop it, but realise that this would also work for arrays. That is, if a and b are arrays, then

>       a := b;

would be equivalent to:

>       a.length = b.length;
>       a[] = b[];

And as for structs, there would be no harm in allowing structs to have constructors (but not destructors), so it could work for them too.

Arcane Jill (throwing caution to the wind).

mmmmm.... sugar... so sweet....

I like the idea.  Why anyone would object to it? (I'm sure I'll find out
soon enough)

On Thu, 27 May 2004 07:30:55 +0000, Arcane Jill wrote:

> One final(ish) push for :=
> 
> I have suggested that "a := b;" be rewritten by the compiler as "a = new A(b)". I'm told that this would be merely syntactic sugar.
> 
> Well yeah, it is. But the phrase "syntactic sugar" is a loaded phrase, implying "bad thing". The fact is that we can write "a = b + c" instead of "a = b.opAdd(c)", and we LIKE it. Syntactic sugar is sometimes nice.
> 
> It's a very simple idea:
> 
>>       a = b;      // copy by reference
>>       a := b;     // copy by value
> 
> This syntactic sugar would ALSO allow you to things like:
> 
>>       Int n := 5;
> 
> (Int is my big integer class) instead of:
> 
>>       Int n = new Int(5);
> 
> That sugary code is much more /smooth/. It /flows/.
> 
> If no-one likes this idea, I'll drop it, but realise that this would also work for arrays. That is, if a and b are arrays, then
> 
>>       a := b;
> 
> would be equivalent to:
> 
>>       a.length = b.length;
>>       a[] = b[];
> 
> And as for structs, there would be no harm in allowing structs to have constructors (but not destructors), so it could work for them too.
> 
> Arcane Jill (throwing caution to the wind).

Sorry. I must strongly disagree with you. For a variety of reasons, D has opted to represent objects as references to instances. Given that I think it in appropriate to support any kind of implicit value semantics. It just leads to too many subtle contradictions. I recognise and agree that it can be inconvenient, but it's just impossible to have a perfect language, and the cost benefit for this feature doesn't warrant it.




"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c945ff$1q4a$1@digitaldaemon.com...
> One final(ish) push for :=
>
> I have suggested that "a := b;" be rewritten by the compiler as "a = new A(b)". I'm told that this would be merely syntactic sugar.
>
> Well yeah, it is. But the phrase "syntactic sugar" is a loaded phrase, implying "bad thing". The fact is that we can write "a = b + c" instead of "a = b.opAdd(c)", and we LIKE it. Syntactic sugar is sometimes nice.
>
> It's a very simple idea:
>
> >       a = b;      // copy by reference
> >       a := b;     // copy by value
>
> This syntactic sugar would ALSO allow you to things like:
>
> >       Int n := 5;
>
> (Int is my big integer class) instead of:
>
> >       Int n = new Int(5);
>
> That sugary code is much more /smooth/. It /flows/.
>
> If no-one likes this idea, I'll drop it, but realise that this would also work for arrays. That is, if a and b are arrays, then
>
> >       a := b;
>
> would be equivalent to:
>
> >       a.length = b.length;
> >       a[] = b[];
>
> And as for structs, there would be no harm in allowing structs to have constructors (but not destructors), so it could work for them too.
>
> Arcane Jill (throwing caution to the wind).
>
>

>One final(ish) push for :=
>
>I have suggested that "a := b;" be rewritten by the compiler as "a = new A(b)". I'm told that this would be merely syntactic sugar.

Yech. I still want := to be the assignment operator, and a bare = be invalid.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c945ff$1q4a$1@digitaldaemon.com...
> One final(ish) push for :=
>
> I have suggested that "a := b;" be rewritten by the compiler as "a = new
A(b)".
> I'm told that this would be merely syntactic sugar.

Is A the dynamic type or the static type? In other words if "b" is an
instance of a subclass of A would "a" be an instance of the same subclass?
If the compiler hard-codes in "new A(b)" then it looks like it wouldn't be.
One way to get "value semantics" that gives the subclass complete control is
to use a ".dup" property
 a = b.dup;
The biggest difference from your proposal is that the class writer would
have to define the .dup property instead of having the compiler generate
one. I don't think that is so bad since dup'ing is fairly rare.

-Ben

I don't see any of those subtle contradictions... can you give an example?

On Thu, 27 May 2004 18:00:35 +1000, Matthew wrote:

> Sorry. I must strongly disagree with you. For a variety of reasons, D has opted to represent objects as references to instances. Given that I think it in appropriate to support any kind of implicit value semantics. It just leads to too many subtle contradictions. I recognise and agree that it can be inconvenient, but it's just impossible to have a perfect language, and the cost benefit for this feature doesn't warrant it.
> 
> 
> 
> 
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c945ff$1q4a$1@digitaldaemon.com...
>> One final(ish) push for :=
>>
>> I have suggested that "a := b;" be rewritten by the compiler as "a = new A(b)". I'm told that this would be merely syntactic sugar.
>>
>> Well yeah, it is. But the phrase "syntactic sugar" is a loaded phrase, implying "bad thing". The fact is that we can write "a = b + c" instead of "a = b.opAdd(c)", and we LIKE it. Syntactic sugar is sometimes nice.
>>
>> It's a very simple idea:
>>
>> >       a = b;      // copy by reference
>> >       a := b;     // copy by value
>>
>> This syntactic sugar would ALSO allow you to things like:
>>
>> >       Int n := 5;
>>
>> (Int is my big integer class) instead of:
>>
>> >       Int n = new Int(5);
>>
>> That sugary code is much more /smooth/. It /flows/.
>>
>> If no-one likes this idea, I'll drop it, but realise that this would also work for arrays. That is, if a and b are arrays, then
>>
>> >       a := b;
>>
>> would be equivalent to:
>>
>> >       a.length = b.length;
>> >       a[] = b[];
>>
>> And as for structs, there would be no harm in allowing structs to have constructors (but not destructors), so it could work for them too.
>>
>> Arcane Jill (throwing caution to the wind).
>>
>>
>>

Alas I cannot.

I'm one of those vexing people who do a lot of things
subconsciously, and often have just "feelings" about things for ages. I've had
qualms about certain things that have literally taken months to bubble up through
my tangled grey matter.

The way it works for me is that I'll remember that there are misgivings about
this issue, and when I come across the related issue(s) on which those misgivings
are
(unconsciously) founded, the bells will ring, and I'll rush back and write it
down, or post an NG message.

This works well for writing books/articles, and for developing software, but it can be quite a problem when having debates in person, or on newsgroups.

Given that, please feel free to ignore me as an irritating prick!

:-)

(I'm going a bike ride in a minute, and that often helps things bubble up ...)



"DemmeGod" <me@demmegod.com> wrote in message news:pan.2004.05.27.21.56.47.935562@demmegod.com...
> I don't see any of those subtle contradictions... can you give an example?
>
> On Thu, 27 May 2004 18:00:35 +1000, Matthew wrote:
>
> > Sorry. I must strongly disagree with you. For a variety of reasons, D has opted to represent objects as references to instances. Given that I think it in appropriate to support any kind of implicit value semantics. It just leads to too many subtle contradictions. I recognise and agree that it can be inconvenient, but it's just impossible to have a perfect language, and the cost benefit for this feature doesn't warrant it.
> >
> >
> >
> >
> > "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c945ff$1q4a$1@digitaldaemon.com...
> >> One final(ish) push for :=
> >>
> >> I have suggested that "a := b;" be rewritten by the compiler as "a = new A(b)". I'm told that this would be merely syntactic sugar.
> >>
> >> Well yeah, it is. But the phrase "syntactic sugar" is a loaded phrase, implying "bad thing". The fact is that we can write "a = b + c" instead of "a = b.opAdd(c)", and we LIKE it. Syntactic sugar is sometimes nice.
> >>
> >> It's a very simple idea:
> >>
> >> >       a = b;      // copy by reference
> >> >       a := b;     // copy by value
> >>
> >> This syntactic sugar would ALSO allow you to things like:
> >>
> >> >       Int n := 5;
> >>
> >> (Int is my big integer class) instead of:
> >>
> >> >       Int n = new Int(5);
> >>
> >> That sugary code is much more /smooth/. It /flows/.
> >>
> >> If no-one likes this idea, I'll drop it, but realise that this would also work for arrays. That is, if a and b are arrays, then
> >>
> >> >       a := b;
> >>
> >> would be equivalent to:
> >>
> >> >       a.length = b.length;
> >> >       a[] = b[];
> >>
> >> And as for structs, there would be no harm in allowing structs to have constructors (but not destructors), so it could work for them too.
> >>
> >> Arcane Jill (throwing caution to the wind).
> >>
> >>
> >>
>

On Thu, 27 May 2004 07:30:55 +0000 (UTC), Arcane Jill wrote:

> One final(ish) push for :=
> 
> I have suggested that "a := b;" be rewritten by the compiler as "a = new A(b)". I'm told that this would be merely syntactic sugar.
> 
> Well yeah, it is. But the phrase "syntactic sugar" is a loaded phrase, implying "bad thing". The fact is that we can write "a = b + c" instead of "a = b.opAdd(c)", and we LIKE it. Syntactic sugar is sometimes nice.

I'm with you on this one too. What you are suggesting is a SHORTHAND method
of doing something which is commonly written out in long hand. You are not
saying that the current way should be abandonded, just supplemented with an
alternative to make life easier for coders, and readers of code alike.

> It's a very simple idea:
> 
>>       a = b;      // copy by reference
>>       a := b;     // copy by value

Yes. Nothing to taxing for my brain here. Sometimes we need to copy the reference to 'X' and sometimes we need to copy the value contained in 'X'. Or in other words, using the examples above, in the first one we want to copy what 'b' is, and in the second we want to copy what 'b' refers to. For simple datatypes (int, float, char, etc...) the two are identical in meaning. The difference appears when we are talking about classes, arrays, and structs.

> This syntactic sugar would ALSO allow you to things like:
> 
>>       Int n := 5;
> 
> (Int is my big integer class) instead of:
> 
>>       Int n = new Int(5);
> 
> That sugary code is much more /smooth/. It /flows/.

Yep, sure does.  And it doesn't stop somebody from coding the long way or from coding ...

         Int n = new BaseInt(5);
when Int and BaseInt are related.

> If no-one likes this idea, I'll drop it, but realise that this would also work for arrays. That is, if a and b are arrays, then
> 
>>       a := b;
> 
> would be equivalent to:
> 
>>       a.length = b.length;
>>       a[] = b[];

Much shorter and to the point. You are simply saying that you wish to make a duplicate of the array 'b'.

> And as for structs, there would be no harm in allowing structs to have constructors (but not destructors), so it could work for them too.

Still makes sense to me. I'm all in favour in making writing code and reading code easier.

-- 
Derek
28/May/04 10:19:50 AM

On Thu, 27 May 2004 18:00:35 +1000, Matthew wrote:

> Sorry. I must strongly disagree with you. For a variety of reasons, D has opted to represent objects as references to instances. Given that I think it in appropriate to support any kind of implicit value semantics. It just leads to too many subtle contradictions. I recognise and agree that it can be inconvenient, but it's just impossible to have a perfect language, and the cost benefit for this feature doesn't warrant it.
> 

Que? Strongly disagree with what? Its only a syntax change not a semantic one. It doesn't break any exiting code. It doesn't make life harder.

I'm not sure what you mean by "conrtadiction". Are you saying that, in some situations, you can envisage that the phrase " a := b " will not mean what we expect it to mean? It will always mean " Set the value of whatever 'a' refers to, to be identical to the value of whatever 'b' refers to". In other words, make a duplicate of b's object. If 'b' is an integer then take a copy of the integer value. If 'b' is a class object then create a new object of the same class, copy the RAM values to the new object and then assign 'a' to refer to the new object. Just like you might do in longhand. Maybe the compiler can check if the class has a 'dup' method and use that if it does exist?

We aren't expecting the "perfect language", just a better one.

And which cost-benefit study are you referring to? What are the costs? What are the benefits? And how do you measure them against each other?

-- 
Derek
28/May/04 10:32:46 AM

Arcane Jill wrote:
> One final(ish) push for :=
> 
> I have suggested that "a := b;" be rewritten by the compiler as "a = new A(b)".
> I'm told that this would be merely syntactic sugar.

I like the way the word "new" alerts me to fact that I'm creating a new object. Also, if I'm wondering where I create new objects, I can just search for "new".

James McComb