www.digitalmars.com         C & C++   DMDScript  

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

reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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