April 24, 2005
"Derek Parnell" <derek@psych.ward> wrote in message news:nvs7ocyuwj7$.5srfzovygnpv$.dlg@40tude.net...
> On Sat, 23 Apr 2005 23:41:30 -0500, TechnoZeus wrote:
>
*snip*
>
> 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

Among othger things, yes... that is what I am saying I would like it to do.

More generally, I would like := to update the contents of the destination operand with the contents of the source operand.   That's what value assignment is.

As for source being a dynamic array reference rather than an array,
I think that is a matter of perspective.
The "=" operator does treat it as a dynamic array reference,
we all know there's more to "what it is" than simply how it's treated.
I'm not tring to tell anyone that their point of view is wrong.
I'm trying to point out that alternative points of view may be
equally valid, and potentially productive.

Having a value assignment operator available would support an alternative way of thinking, and by extension, increase potential productivity.

People who don't like it wouldn't have to use it.
People who do like it wouldn't have to use it "exclusively".

TZ


April 25, 2005
TechnoZeus wrote:
> No, if the variable is uninitialized and a value is assigned, then
> assigning that value "is" the initialization. 

How exactly do you expect the compiler to know what is and what isn't the value of an object?

For example, if the object is just a wrapper for another object, the other object is the value, so it won't help to shallow-copy the original. OTOH, doing a deep-copy by default sucks, because in many cases it's not needed (w/ unmodifiable objects), and/or not desired (you don't want to have 25000 connections to a database open).

So, the only sensible option is to make the object provide its own duplicate. You can already do that. OK, so you have two versions of the template. If you don't want two versions of the main template, write an assign template, specialize it for Objects and arrays, and use wherever you'd use a=b.

Again, note that this issue only applies to simple assignments "a=b". In the case of expression "a=b+c", a new object will be constructed as-is, so there is no need for another operator.


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

You'd always allocate a new object, even if it was already allocated?


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

Duh!


xs0



> 
> "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 25, 2005
Hello All !
Here is patch for gdc-0.10 implementing @ and @= operators. This patch is
not intended for direct use, this is just my test how can it be done.

@ is unary operator which currently:
  tries to overwrite expression as rvalue.opValue()
  returns rvalue for structs without opValue
  returns rvalue for arithmetic types
  fails to compile otherwise.

@= is binary operator which currently:
  tries to overwrite expression as lvalue.opValueAssign(rvalue)
  overwrites expression as lvalue = rvalue for structs without opValueAssign
  overwrites expression as lvalue = rvalue for arithmetic types
  fails otherwise

'@' symbol means 'at' which emphasizes it's meaning in language: @a means "get value *at* given location" and a@= means "store value *at* given location"

':=' is bad because D already has too many meanings for symbol ':'.

TODO:
  overwrite @array as array.dup (recursion here ?)
  overwrite a@=array as a=array.dup (recursion here ?)
  decide what to do with pointers
    (possibilities:
       return rvalue
       return *rvalue
       return **...*rvalue (recursively))

Other ideas related to general template programming:

Allow static .init property for classes which will return new instance of class for default variable initializing (by default return null).

For any type T allow T& and T@ for reference (pointer?) and value types. Multiple-applying should behave as: T&& equals T& and T@@ equals T@. For classes T& equals T, for structs and built-in types T@ equals T. May be this is too global change to be accepted, but it has a lot of benefits.

-- 
          Vladimir

April 25, 2005
In article <d4ipf2$1poj$1@digitaldaemon.com>, Vladimir says...
>
>--nextPart1356870.LVNHTvSSDs
>Content-Type: text/plain; charset=koi8-r
>Content-Transfer-Encoding: 8Bit
>
>Hello All !
>Here is patch for gdc-0.10 implementing @ and @= operators. This patch is
>not intended for direct use, this is just my test how can it be done.
> [snip]

Vlad,
Thank you for taking the bazaar concept (or 'microfork' if you will) seriously
and writing a reference implementation for this feature concept.  I only hope
that this stands as an example for how to more effectively communicate new
language concepts from here on out (as has been discussed to death in this forum
before).

One question remains: what is the most effective way to apply such a patch for us *nix neophytes?

- EricAnderton at yahoo
April 25, 2005
pragma wrote:

> One question remains: what is the most effective way to apply such a
> patch for us *nix neophytes?

Change to the "d" directory (where you unpacked GDC 0.10) and:
patch -p1 -i d-opValue.patch

Sometimes linefeeds will give you trouble... (ie. UNIX vs. DOS)
Then you need to translate the Windows files to drop the '\r'.

--anders

PS. See also http://www.gnu.org/software/diffutils/manual/
April 25, 2005
Vladimir wrote:
> TODO:
>   overwrite @array as array.dup (recursion here ?)
>   overwrite a@=array as a=array.dup (recursion here ?)
>   decide what to do with pointers
>     (possibilities:
>        return rvalue
>        return *rvalue
>        return **...*rvalue (recursively))
After thinking again:
TODO:
1. By default (if not overloaded) recursively apply @= to all members if
lvalue and rvalue are of the same aggregate type (class, struct or array).
Overloading are still need for (a) type conversion and (b) external
resources handling.
2. By default (if not overloaded) try to rewrite @a as
  { typeof(a) __t; __t @= a; return __t; }

This needs either

a. Somehow redefine @= for correct handling null lvalue
   (for example change overloading signature to:
    static T opAssignValue(inout T to, T from);
    so that inside function one can check
    if to is null react appropriate)

b. Implement .init property for classes.

Without this the following examples will cause seg-v:

/* Can be solved by overloading opAssignValue for struct S */
class C { ... }
struct S {
        C c;
}
S a, b;
a = @b;

/* Can't be solved */
C[] array1 = new C[1];
C[] array2 = new C[1];
array2[0] = new C;
array1 = @array2;


-- 
          Vladimir
April 25, 2005
pragma wrote:
> Vlad,
> Thank you for taking the bazaar concept (or 'microfork' if you will)
> seriously
> and writing a reference implementation for this feature concept.  I only
> hope that this stands as an example for how to more effectively
> communicate new language concepts from here on out (as has been discussed
> to death in this forum before).
Thanks for your support !
Actually while implementing this patch I've found some places where I was
wrong in discussion and got some new ideas about how to do it better.


> One question remains: what is the most effective way to apply such a patch for us *nix neophytes?
> 
> - EricAnderton at yahoo

-- 
          Vladimir
April 27, 2005
"xs0" <xs0@xs0.com> wrote in message news:d4ilv1$1m84$1@digitaldaemon.com...
> TechnoZeus wrote:
>
> How exactly do you expect the compiler to know what is and what isn't the value of an object?
>
*snip*
>
> xs0
>

I don't expect the compiler to know the difference at that level.  Right now, it doesn't know the difference at "any" level.  It simply copies identities or values depending on what it is dealing with.  All I'm asking for is a way to remove the "depending on what it is dealing with" and replace it with "depending on what it was asked to do" so that it will if the value of an item is an address, or a wrapper, or whatever, we can compare or assign that "value" without having to first establish what syntax we have to use based on what the value is contained in.
In other words, a:=b should "always" mean...  copy the contents of "b" into "a"
no matter whther "a" and "b" are classes, integers, arrays, or what ever,
as long as it is possible to change the value of "a" and as long as the
data contained in "b" is capable of being stored in "a"  ... period.

TZ


April 28, 2005
TechnoZeus wrote:
> "xs0" <xs0@xs0.com> wrote in message news:d4ilv1$1m84$1@digitaldaemon.com...
> 
>>TechnoZeus wrote:
>>
>>How exactly do you expect the compiler to know what is and what isn't
>>the value of an object?
>>
> 
> *snip*
> 
>>xs0
>>
> 
> 
> I don't expect the compiler to know the difference at that level.  Right now, it doesn't know the difference at "any" level.  It simply copies identities or values depending on what it is dealing with.

No, it always copies the value. You just seem to think that the value of a reference is the object it's pointing to, not the reference itself.


> All I'm asking for is a way to remove the "depending on what it is dealing with" and replace it with "depending on what it was asked to do" 

OK then, how do you expect the compiler to know what it was asked to do? Again, you assume it is possible for the compiler to automatically know what _you_ consider a value.

> so that it will if the value of an item is an address, or a
>  wrapper, or whatever, we can compare or assign that "value" without having to first establish what syntax we have to use based on what the value is contained in.

Again, the only reasonable way to do this is to let the object itself determine what its value is (in other words, to let you determine it). If you do that, you will still have to use different syntax, it will just be shifted elsewhere.

int a:=b; // OK
Object c:=d; // not OK, because c is null


> In other words, a:=b should "always" mean...  copy the contents of "b" into "a"
> no matter whther "a" and "b" are classes, integers, arrays, or what ever,
> as long as it is possible to change the value of "a" and as long as the
> data contained in "b" is capable of being stored in "a"  ... period.

See the above example for why you need to handle things differently in any case. Using dummy init values is a somewhat naive solution, and just copying bit-by-bit is only an option if both sides are of the exact same type, even if you disregard what a source of bugs it can be.

I feel you don't realize that it's not possible to somehow magically treat globals, stack variables (locals) and heap variables (objects) all the same. Each have their specifics which you have to be aware of in order to use them correctly. Even a local int and a global int differ in important ways, and they're both ints. You're just so used to their differences (like their lifetime), you don't see it as an issue.


xs0
April 29, 2005
"xs0" <xs0@xs0.com> wrote in message news:d4qt4a$unl$1@digitaldaemon.com...
> TechnoZeus wrote:
> > "xs0" <xs0@xs0.com> wrote in message news:d4ilv1$1m84$1@digitaldaemon.com...
> >
> >>TechnoZeus wrote:
> >>
> >>How exactly do you expect the compiler to know what is and what isn't the value of an object?
> >>
> >
> > *snip*
> >
> >>xs0
> >>
> >
> >
> > I don't expect the compiler to know the difference at that level. Right now, it doesn't know the difference at "any" level.  It simply copies identities or values depending on what it is dealing with.
>
> No, it always copies the value. You just seem to think that the value of a reference is the object it's pointing to, not the reference itself.
>
>
> > All I'm asking for is a way to remove the "depending on what it is dealing with" and replace it with "depending on what it was asked to do"
>
> OK then, how do you expect the compiler to know what it was asked to do? Again, you assume it is possible for the compiler to automatically know what _you_ consider a value.
>
> > so that it will if the value of an item is an address, or a
> >  wrapper, or whatever, we can compare or assign that "value" without
> > having to first establish what syntax we have to use based on what
> > the value is contained in.
>
> Again, the only reasonable way to do this is to let the object itself determine what its value is (in other words, to let you determine it). If you do that, you will still have to use different syntax, it will just be shifted elsewhere.
>
> int a:=b; // OK
> Object c:=d; // not OK, because c is null
>
>
> > In other words, a:=b should "always" mean...  copy the contents of "b" into "a"
> > no matter whther "a" and "b" are classes, integers, arrays, or what ever,
> > as long as it is possible to change the value of "a" and as long as the
> > data contained in "b" is capable of being stored in "a"  ... period.
>
> See the above example for why you need to handle things differently in any case. Using dummy init values is a somewhat naive solution, and just copying bit-by-bit is only an option if both sides are of the exact same type, even if you disregard what a source of bugs it can be.
>
> I feel you don't realize that it's not possible to somehow magically treat globals, stack variables (locals) and heap variables (objects) all the same. Each have their specifics which you have to be aware of in order to use them correctly. Even a local int and a global int differ in important ways, and they're both ints. You're just so used to their differences (like their lifetime), you don't see it as an issue.
>
>
> xs0

I realize more than you are aparently capable of comprehending.
What you are stating as imutable fact is actually implementation dependant.
Unfortunatley, I don't know how it was implemented in D, but I know there is
more than one way of looking at it, and more than one way of implementing it.

In case you hadn't noticed, the compiler does know the difference between a reference type and a value type.

Well... Obviously, either those who want the same thing I want are either the minority, or mostly quiet people... so I'm giving up.

I've stated my case, and I'm getting insults for it rather than discussion. I have better things to do.

Donald A. Kronos, PhD. - TechnoZeus



2 3 4 5 6 7 8 9 10 11 12
Next ›   Last »