www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - opStarAssign?

reply "Janice Caron" <caron800 googlemail.com> writes:
So, are we going to get opStarAssign()?

I can do
    n = *p;

but not
    *p = n;

Also, are these overloads going to be renamed (e.g. opDeref(),
opDerefAssign()) as people here have suggested. I can think of many
names I might give to a dereferencing function - among them val(),
deref(), getValue(), getElement(), and so on, but for some reason
"opStar" would not be high on my list of choices.
Nov 22 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
Janice Caron wrote:
 but for some reason
 "opStar" would not be high on my list of choices.

Because the names for operator overloads should be based on what operator they're overloading, not the syntax for it. e.g. it's opMul, not opStar. opDiv, not opSlash. - Gregor Richards
Nov 22 2007
next sibling parent reply Leonard Dahlmann <leo.dahlmann gmail.com> writes:
Janice Caron Wrote:

 On 11/22/07, Gregor Richards <Richards codu.org> wrote:
 Janice Caron wrote:
 but for some reason
 "opStar" would not be high on my list of choices.

Because the names for operator overloads should be based on what operator they're overloading, not the syntax for it. e.g. it's opMul, not opStar. opDiv, not opSlash.

Yeah. Um. I was employing irony. Anyway, I'd hope Walter is considering changing the name, given the unanimous support here for doing that. The other part of my question though, was, is opWhateverAssign() on the cards any time soon. Any sign of an overload for *p = ?

What about *p *=, *p /=, *p ~=, ...? Wouldn't these need overloads, too?
Nov 23 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Leonard Dahlmann" <leo.dahlmann gmail.com> wrote in message 
news:fi6o8p$2i49$1 digitalmars.com...
 Janice Caron Wrote:

 On 11/22/07, Gregor Richards <Richards codu.org> wrote:
 Janice Caron wrote:
 but for some reason
 "opStar" would not be high on my list of choices.

Because the names for operator overloads should be based on what operator they're overloading, not the syntax for it. e.g. it's opMul, not opStar. opDiv, not opSlash.

Yeah. Um. I was employing irony. Anyway, I'd hope Walter is considering changing the name, given the unanimous support here for doing that. The other part of my question though, was, is opWhateverAssign() on the cards any time soon. Any sign of an overload for *p = ?

What about *p *=, *p /=, *p ~=, ...? Wouldn't these need overloads, too?

Which is why we need reference returns. Then you could do: class A { int myInt; ref int opDeref() { return myInt; } } A a = new A(); *a = 5; // sets myInt to 5 *a += 3; // sets myInt to 8 This would also solve the similar problems with opIndexAssign and with properties.
Nov 23 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:
 "Leonard Dahlmann" <leo.dahlmann gmail.com> wrote in message 
 news:fi6o8p$2i49$1 digitalmars.com...
 Janice Caron Wrote:

 On 11/22/07, Gregor Richards <Richards codu.org> wrote:
 Janice Caron wrote:
 but for some reason
 "opStar" would not be high on my list of choices.

operator they're overloading, not the syntax for it. e.g. it's opMul, not opStar. opDiv, not opSlash.

Anyway, I'd hope Walter is considering changing the name, given the unanimous support here for doing that. The other part of my question though, was, is opWhateverAssign() on the cards any time soon. Any sign of an overload for *p = ?

Wouldn't these need overloads, too?

Which is why we need reference returns. Then you could do: class A { int myInt; ref int opDeref() { return myInt; } } A a = new A(); *a = 5; // sets myInt to 5 *a += 3; // sets myInt to 8 This would also solve the similar problems with opIndexAssign and with properties.

I believe there was some mention of reference types at the conference.
Nov 23 2007
prev sibling next sibling parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Janice Caron wrote:
 My preference would be to have the compiler rewrite
     *p += n;
 
 as
     p.opDerefAssign(p.opDeref() + n);

Wouldn't "p.opAssign(p.opDeref()+n);" be quite sufficient? regards, frank
Nov 23 2007
parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Janice Caron wrote:
 On 11/23/07, 0ffh <frank frankhirsch.youknow.what.todo.net> wrote:
 Janice Caron wrote:
 My preference would be to have the compiler rewrite
     *p += n;

 as
     p.opDerefAssign(p.opDeref() + n);


I think that would end up being equivalent to p = *p + n;

Si.
 whereas what we actually want is the equivalent of
     *p = *p + n;

Is that so? I'd guess that cases where both "x=y;" and "*x=y;" make sense are rare. So overloading opAssign for the parameter type might be quite sufficient.
 but I could be wrong. Maybe it depends on what we consider opAssign
 ought to be doing. In any case, we /do/ have opIndexAssign(), so
 opDerefAssign() ought to exist by analogy.

Well it's good that you know what ought to be - I'm sure I don't. ;-) regards, frank
Nov 23 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
0ffh wrote:
 Janice Caron wrote:
  > I think that would end up being equivalent to
  >     p = *p + n;
 
 Si.
 
  > whereas what we actually want is the equivalent of
  >     *p = *p + n;
 
 Is that so?
 I'd guess that cases where both "x=y;" and "*x=y;" make sense are rare.
 So overloading opAssign for the parameter type might be quite sufficient.

Even if they're rare, they *do* exist (for example, a variant type that can store both normal types and pointers). So for full functionality as well as plain consistency (also very important in a programming language) there should be an opDerefAssign. (And opDeref instead of opStar, obviously)
Nov 24 2007
parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Frits van Bommel wrote:
 0ffh wrote:
 I'd guess that cases where both "x=y;" and "*x=y;" make sense are 
 rare. So overloading opAssign for the parameter type might be quite 
 sufficient.

Even if they're rare, they *do* exist (for example, a variant type that can store both normal types and pointers).

You mean like: int y=0; Variant x=&y; *x=3; printf("%i\n",y); // prints 3 Wouldn't this be quite sufficient, without the need to "*x=": int y=0; Variant x=&y; int* z;z=x; *z=3; printf("%i\n",y); // prints 3 Variant is obviously a very special case. I wonder if we really need this... I think I see quite some potential for serious shootings of feet here... okay, I'm all for it now! =) regards, frank
Nov 24 2007
next sibling parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
I wonder: There are quite a few requests floating
around that would require changes to the D language.
If the D language is going to be changed, why not go all
the way and make the change to end all change requests:
A small compile-time API for AST walking and manipulation.
I don't just mean macros, but full scale metaprogramming.
It would even be possible to do refactoring and convert
the AST back to source from within the language.
The only problem I really see is that it would require the
AST structure to be part of the language specification.

regards, frank
Nov 24 2007
next sibling parent 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
0ffh wrote:
 [...]

Okay, maybe it's a bit too insane! =) I imagine it would tax the compile time execution capabilities of the compilers, maybe beyond their limits. But how about a compiler switch to spit out the AST in some text format (say, in Annotated Term Format), and a possibility to feed those files back to the compiler, instead of D source? I imagine that couldn't be too hard? regards, frank
Nov 24 2007
prev sibling next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
0ffh wrote:
 
 I wonder: There are quite a few requests floating
 around that would require changes to the D language.
 If the D language is going to be changed, why not go all
 the way and make the change to end all change requests:
 A small compile-time API for AST walking and manipulation.
 I don't just mean macros, but full scale metaprogramming.
 It would even be possible to do refactoring and convert
 the AST back to source from within the language.
 The only problem I really see is that it would require the
 AST structure to be part of the language specification.

... I think you just reinvented LISP :P. (Note: all those brackets are in there to encode the AST structure into the language)
Nov 24 2007
parent 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Frits van Bommel wrote:
 0ffh wrote:
 I wonder: [...]

.... I think you just reinvented LISP :P. (Note: all those brackets are in there to encode the AST structure into the language)

Hummm... not quite. The good thing about Lisps, IMHO, is that they failed to acquire a syntax (apart from Dylan). That, together with the fact how ridiculously easy it is to write a simple Lisp interpreter, gives you a powerful metaprogramming language for a rather small investment. Another feature of the lack of syntax in Lisp is that the syntax the mathematicians have invented for other functional languages makes my hair stand on end... =) It is perfectly possible to have a functional language with a C-like syntax, as I gather will shortly be demonstrated by D2. It's also perfectly possible to have a syntax and still do heavy duty metaprogramming, as Stratego has already shown. regards, frank
Nov 25 2007
prev sibling parent reply =?ISO-8859-1?Q?Ma=ebl?= <mael.primet gmail.com> writes:
Take a look at OCaml / CamlP4, this is exactly what you are looking for, and
this is done in a truely nice and (extremely) fast (as always when it comes to
OCaml ...) way.
In my opinion, CamlP4 is one of the biggest advantage of OCaml, because it
truly permits to implement full DSL, or to couple a DSL to OCaml code in a
transparent way, so for instance you can define a logic DSL, and have things
like

<ocaml code...>
let F = Logic( A -> B \/ C ) in
my_solver F ;
<ocaml code again...>

and this would translate to
...
let F = Formula_Or(Formula_Imp(A,B),C) in
my_solver F ;
...

and this certainly is useful in many ways 
Nov 25 2007
parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
MaŽl wrote:
 Take a look at OCaml / CamlP4, this is exactly what you are looking for, and
this is done in a truely nice and (extremely) fast (as always when it comes to
OCaml ...) way.
 In my opinion, CamlP4 is one of the biggest advantage of OCaml, because it
truly permits to implement full DSL, or to couple a DSL to OCaml code in a
transparent way, so for instance you can define a logic DSL, and have things
like
 [...]
 and this certainly is useful in many ways 

Thanks for the tip. I took a look at O'Caml earlier, but to be frank, functional languages turn me off... =) I have been imperating since I was a small boy, and I'm reasonably good at it. But when I look at, say Haskell, Clean, Caml, the syntax alone is enough to turn me off. I find those even more repulsive than Lisp. That's not to say that I do not appreciate how powerful those languages are. But it's perfectly possible to have metaprogramming in an imperative languages with C-style syntax, you don't need to go functional for that. regards, frank
Nov 25 2007
parent reply =?ISO-8859-1?Q?Ma=ebl?= <mael.removethis.primet gmail.com> writes:
I'm pretty sure that imperative language can (and will!) completely benefit
from such an API, and I wasn't trying to tell you to go with OCaml, but to take
some inspiration of the great work that has been done for CamlP4. As for the
syntax, it becomes natural only when you exercise it frequently, but once you
understand it, I tell you that frankly, you miss it in imperative languages.
However, I've heard that Walter was trying to build an hybrid
imperative/functionnal language (note that OCaml already is such an hybrid,
although the switch between functionnal and imperative, and the object system
aren't very "natural" to work with to be honest) and I'd really be happy it
this was the case!
Nov 25 2007
parent 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
MaŽl wrote:
 As for the syntax, it becomes natural only when you exercise it 
 frequently, but once you understand it, I tell you that frankly, you 
 miss it in imperative languages.

That's entirely possible... maybe I am missing out on that. But then again, by missing out on that I won't miss it in C or D! ;-)
 However, I've heard that Walter was trying to build an hybrid 
 imperative/functionnal language (note that OCaml already is such an 
 hybrid, although the switch between functionnal and imperative, and the 
 object system aren't very "natural" to work with to be honest) and I'd 
 really be happy it this was the case!

Me too! (Is this a candidate for moderation now?) regards, frank
Nov 25 2007
prev sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Janice Caron wrote:
 On 11/24/07, 0ffh <frank frankhirsch.youknow.what.todo.net> wrote:
 
    *x=3;
 Wouldn't this be quite sufficient, without the need to "*x=":

Both of those lines look like *x= to me.

I think you missed the intention of the ':' at the end. He wasn't referring to the previous lines, but the following ones: 0ffh wrote:
   int y=0;
   Variant x=&y;
   int* z;z=x;
   *z=3;
   printf("%i\n",y); // prints 3

Nov 24 2007
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:
 On 11/23/07, Leonard Dahlmann <leo.dahlmann gmail.com> wrote:
 What about *p *=, *p /=, *p ~=, ...?
 Wouldn't these need overloads, too?

I don't see why. We've done just fine without a[n]*=, a[n]/=, a[n]~= and so on, so why should * be any different? My preference would be to have the compiler rewrite *p += n; as p.opDerefAssign(p.opDeref() + n); (Ditto with .length, [] and so on). That way only two functions are needed, but you still get the full suite of expressability. Note that if the compiler is able to inline both opDeref() and opDerefAssign() then you'd still get the efficiency of ... er ... opDerefAddAssign ... without having the clutter of a zillion different functions. Of course, having functions return references is another approach too.

But the nice thing about the current approach is that it makes it easy to allow controlled or monitored access of your data. If you return a reference you have no idea what they're going to do with it. Of course you don't always care. If you're providing a container class then returning a reference to the data element is exactly the behavior you want. But if you don't want to expose your data in that way, then some automatic rewrite rules like you suggest would be nice. I think both approaches have legitimate uses. Implementing one does not eliminate the need for the other. --bb
Nov 23 2007
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
Mrs. Caron, I think You are mixing opStar with opMul* those two have 
totally different purpose, as You probably know...
Nov 25 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/22/07, Gregor Richards <Richards codu.org> wrote:
 Janice Caron wrote:
 but for some reason
 "opStar" would not be high on my list of choices.

Because the names for operator overloads should be based on what operator they're overloading, not the syntax for it. e.g. it's opMul, not opStar. opDiv, not opSlash.

Yeah. Um. I was employing irony. Anyway, I'd hope Walter is considering changing the name, given the unanimous support here for doing that. The other part of my question though, was, is opWhateverAssign() on the cards any time soon. Any sign of an overload for *p = ?
Nov 22 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/23/07, Leonard Dahlmann <leo.dahlmann gmail.com> wrote:
 What about *p *=, *p /=, *p ~=, ...?
 Wouldn't these need overloads, too?

I don't see why. We've done just fine without a[n]*=, a[n]/=, a[n]~= and so on, so why should * be any different? My preference would be to have the compiler rewrite *p += n; as p.opDerefAssign(p.opDeref() + n); (Ditto with .length, [] and so on). That way only two functions are needed, but you still get the full suite of expressability. Note that if the compiler is able to inline both opDeref() and opDerefAssign() then you'd still get the efficiency of ... er ... opDerefAddAssign ... without having the clutter of a zillion different functions. Of course, having functions return references is another approach too.
Nov 23 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/23/07, 0ffh <frank frankhirsch.youknow.what.todo.net> wrote:
 Janice Caron wrote:
 My preference would be to have the compiler rewrite
     *p += n;

 as
     p.opDerefAssign(p.opDeref() + n);

Wouldn't "p.opAssign(p.opDeref()+n);" be quite sufficient?

I think that would end up being equivalent to p = *p + n; whereas what we actually want is the equivalent of *p = *p + n; but I could be wrong. Maybe it depends on what we consider opAssign ought to be doing. In any case, we /do/ have opIndexAssign(), so opDerefAssign() ought to exist by analogy.
Nov 23 2007
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/24/07, 0ffh <frank frankhirsch.youknow.what.todo.net> wrote:

    *x=3;
 Wouldn't this be quite sufficient, without the need to "*x=":

Both of those lines look like *x= to me.
Nov 24 2007