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
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
parent reply "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
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.


 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. 
 
 


I believe there was some mention of reference types at the conference.
Nov 23 2007
prev sibling parent reply "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
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 "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
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);


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


 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 next 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 reply oldrev <oldrev gmail.com> writes:
0ffh Wrote:


 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


Anonymous AST macro is the ultimate way to solve it:

macro(args, "=>", expr)
{
    mixin("delegate(" ~ args.stringof ~ ")" ~ "{ return " ~ expr.stringof ~ ";
};");
}

void foo(int delegate(int, int)){ 
...
}

foo(int x, int y => x + y);

Hope it's helpful :)

Regards,
Wei
Nov 25 2007
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Why would anyone need this in a general-purpose, OO language, is beyond 
me...
Nov 25 2007
parent reply 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Dejan Lekic wrote:

 Why would anyone need this in a general-purpose, OO language, is beyond 
 me...


A few examples of what would be possible to add to any program
you have the source of, by just including an appropriate module:

  - Stack backtraces
  - Runtime statistics & profiling
  - Array access range checking
  - Integral overflow checks
  - New numeric types that behave like primitive
    types without any need for syntax overloading
  - Anything

regards, frank
Nov 25 2007
parent reply =?ISO-8859-1?Q?Ma=ebl?= <someone somewhere.com> writes:
Plus, if it is implemented as a pre-processor (CamlP4-like) you could make
powerful domain-specific languages and directly embbed them in D programs
Nov 25 2007
parent 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
Maël wrote:

 Plus, if it is implemented as a pre-processor (CamlP4-like) you could
 make powerful domain-specific languages and directly embbed them in D
 programs


You wouldn't even need CTFE for it, if you'd just add a compiler switch to
output 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.
Hacking the compiler would become a breeze. =)

regards, frank
Nov 25 2007
prev sibling parent reply "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
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