www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Properties, opIndex, and expression rewriting.

reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
http://www.igsoft.net/dpolls/poll/results.php?pollid=1
* 111 votes total.
* Keep things as they are now: 1 vote.
* And where did that vote come from?
Jeremie Pelletier pisze:

 Oops, I got the only one "keep things as they are now" vote haha.
 I meant to vote for the one with resolved +=.


So, Walter, how about some expression rewriting logic to solve some of
the problems with properties, opIndex, and related lvalueness stuff?

(I refer to the expression rewriting in the Wiki4D article on
properties:
http://prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semantic)

Syntax can be broached later.

I've also attached some D-like pseudocode of what I think such an
expression rewriting algorithm would look like (propertyrewrite.d).  The
other file is a potential test-case.  I used it to figure out what a
trace of the algorithm might look like, and designed it accordingly.  If
it can wait a few weeks, I might try to put it into dmd and write a
patch.  I'll only do it if there's interest though.

Other notes about attached pseudocode:
* The types in this psuedocode are expected to be defined as D classes
are; that is, they are reference types.
* It seems worthwhile to call this after operator overloads are turned
into calls.  This would make it more clear which things potentially have
side effects.  (Just imagine how << is overloaded in C++.  As much as
it's frowned upon, something similar could happen in the future of D.
Marking overloads like '<<', '+', '-' as pure could potentially remove
any pessimisation.)
Aug 11 2009
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 11 Aug 2009 03:19:42 -0400, Chad J wrote:


 So, Walter, how about some expression rewriting logic to solve some of
 the problems with properties, opIndex, and related lvalueness stuff?
 
 (I refer to the expression rewriting in the Wiki4D article on
 properties:
 http://prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semantic)
 
 Syntax can be broached later.
 
 I've also attached some D-like pseudocode of what I think such an
 expression rewriting algorithm would look like (propertyrewrite.d).  The
 other file is a potential test-case.  I used it to figure out what a
 trace of the algorithm might look like, and designed it accordingly.  If
 it can wait a few weeks, I might try to put it into dmd and write a
 patch.  I'll only do it if there's interest though.


It would be nice if you made a patch.  This way we could see for
ourselves if it worked and vote for it.

I've noticed an optimization which reduces number of calls to a getter.
I think you shouldn't do that: you should call getter as many times as
the expression suggests, and leave the rest to the optimizer.
Aug 11 2009
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Sergey Gromov wrote:

 
 It would be nice if you made a patch.  This way we could see for
 ourselves if it worked and vote for it.
 


I know what you mean.

I can try, but right now really isn't a good time for me to be working
on this stuff.  :(  I can maybe handle it well in a month or two when I
start looking for a job and I get my higher-priority projects finished.
   Right now I'm trying to help my family with some necessary home
improvement/repair and also release a couple (finished but not ported)
games at the moment.


 I've noticed an optimization which reduces number of calls to a getter.
 I think you shouldn't do that: you should call getter as many times as
 the expression suggests, and leave the rest to the optimizer.


It's not so much an optimization.

I removed those extra calls because it would create an asymmetry between
how many times the getter is called and how many times the setter is
called.  I suppose it could be argued that the extra setter calls should
be left in as well, and maybe that would be alright.  To be honest, I'm
not too entirely sure how to deal with that.
Aug 11 2009
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 11 Aug 2009 22:15:15 -0400, Chad J wrote:


 I've noticed an optimization which reduces number of calls to a getter.
 I think you shouldn't do that: you should call getter as many times as
 the expression suggests, and leave the rest to the optimizer.


 
 It's not so much an optimization.
 
 I removed those extra calls because it would create an asymmetry between
 how many times the getter is called and how many times the setter is
 called.  I suppose it could be argued that the extra setter calls should
 be left in as well, and maybe that would be alright.  To be honest, I'm
 not too entirely sure how to deal with that.


I think it's a matter of definition.  Try to define the rewriting
behavior, in English, as simply and unambiguous as possible: how many
times getters and setters are called, and in which order.  I'm sure this
will filter away many behaviors as unpredictable.  Then you say that
compiler may optimize some calls if it can guarantee the same result and
order of side effects.  Then you make a straight-forward implementation
of your specification.  Then you see what you can do about
optimizations.

Sorry if it's all obvious.  I didn't mean to lecture you, honestly.
Aug 12 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Sergey Gromov wrote:

 
 I think it's a matter of definition.  Try to define the rewriting
 behavior, in English, as simply and unambiguous as possible: how many
 times getters and setters are called, and in which order.  I'm sure this
 will filter away many behaviors as unpredictable.  Then you say that
 compiler may optimize some calls if it can guarantee the same result and
 order of side effects.  Then you make a straight-forward implementation
 of your specification.  Then you see what you can do about
 optimizations.
 
 Sorry if it's all obvious.  I didn't mean to lecture you, honestly.


np.  I agree.

Given the liberty of defining this, I'd like to make it both easy to
implement and unsurprising to the user.  There may be examples that make
it clear which potential definition(s) are superior.  I'm just not sure
what they are.

I'll think about it more later.
Aug 12 2009