matz wrote: > For your request for optional type system for hint to improve > performance, I don't say neither "yes" or "no", but "wait" and discuss > more deeply. You can put it in RCR. No one complains about good This is a very fair answer. I really wanted to provide some ideas instead of concreate solutions. Is there some RCR list, anyway? matz wrote: > Why hate "<<" so much? I think it's good to mention side effect > explicitly in code appearance. I don't hate "<<". I use it, I love it, therefore, I would like to have it for all other operators!!! I think, I have not expressed myself clearly: I don't want to optimize the sring class at all: I can live with the "<<" operator. I don't want reference counting either. (If Ruby had it, it would be OK., but I don't think it needs it in general. It would violate backwards compatibility, anyway.) If I wanted to optimize the String class, then I would simply do it, not post to this list. I used the string class only as an example, because there is a benchmark which shows the potential of the approach I suggested. Stefan Nobis wrote: > What about only make it an option to not only overwrite operator + but also to > overwrite operator +=. So if anyone is concerned about speed, he may overwrite > + and += and the rest can just work with overwriting operator +. So if Ruby > finds only operator +, everything works just like it does now, but Ruby now > looks, if it can find operator +=, this one is used and it is not > automatically generated. Of course one could allow to redefine the += operator but, then you would loose the the connection a+=b equibvalent to a=a+b which is nice. Basically I suggested the same, but perhaps you should see my postings with subject "operator idea". Of course one must be cautios: this is not as simple as it would seem at the first time. I don't think of violating backwards-compatibility. My modified suggestion would be: For each type of oparator ???, we could have three (!) variants: ??? () ???= () ???=!() ("!" denotes that it alters the undarlying object!!!!) ??? and ???= would redefine each other but would not define ???!= . ???!= would in turn define both ??? and ???= by mapping: a ??? b to (a.dup ???=! b) E.g. for the strings : "<<" would be the same as "+=!" using this feature. Given this syntax, I would normally always define the ???=! and let the interpreter automatically define the others. Why would it help? Complicated formulas such as a=b ??? c ??? d could be performed magnitudes faster. Or Take for example: x = (a+b)*(c+d) It could be mapped as (a.dup += b)*=(c.dup+=d), The more complicated is your formula, the more temporaries can you win. Even in the case: for i in (0..100) a ???= b end A good optimizer could prevent generating temporaries. Future optimizers (compilers) could perform a lot of optimization based on this subtle relationship between ???,???= and ???=!. Note that the most important thing is: the allocation does not occure in ???= but is generated by the interpreter/compiler on need, which would really boost speed. The main application of such a feature would not be the string class, but mathematical classes such as Matrix and Polynomial,... I think, it would be quite essential for an efficient computer algebra systems based on Ruby. I am playing with the idea of an NTL-interface to Ruby, but the current operator approach in ruby is quite suboptimal for such applications. (I don't think unnecessary copy/allocation of large matrices to be a good idea...) matz wrote: > The only elegant solution I can think of: > > * introduce reference counting. Tanaka wrote: > I have another idea; > > * + concat to self, if reference count is *0*, which means > there's no *reference* to the object. > Of course, in some reference/counted language... Anyway, is there some way in Ruby to introduce reference counting in some way? I don't see how could I override assignment (I'm just a newbie). However, I don't consider programmer-side reference counting to be optimal from a software-engineering point of you: 1) Either the languge has it, so possible future compilers can optimize accordingly. 2) Or you should use it only in exceptional situations when it is really necessary. Best Regards, Christian