Short list with things to finish for D2

[Travis Boucher]

aarti_pl wrote:
> Andrei Alexandrescu pisze:
>> We're entering the finale of D2 and I want to keep a short list of 
>> things that must be done and integrated in the release. It is clearly 
>> understood by all of us that there are many things that could and 
>> probably should be done.
>>
>> 1. Currently Walter and Don are diligently fixing the problems marked 
>> on the current manuscript.
>>
>> 2. User-defined operators must be revamped. Fortunately Don already 
>> put in an important piece of functionality (opDollar). What we're 
>> looking at is a two-pronged attack motivated by Don's proposal:
>>
>> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
>>
>> The two prongs are:
>>
>> * Encode operators by compile-time strings. For example, instead of 
>> the plethora of opAdd, opMul, ..., we'd have this:
>>
>> T opBinary(string op)(T rhs) { ... }
>>
>> The string is "+", "*", etc. We need to design what happens with 
>> read-modify-write operators like "+=" (should they be dispatch to a 
>> different function? etc.) and also what happens with index-and-modify 
>> operators like "[]=", "[]+=" etc. Should we go with proxies? Absorb 
>> them in opBinary? Define another dedicated method? etc.
>>
>> * Loop fusion that generalizes array-wise operations. This idea of 
>> Walter is, I think, very good because it generalizes and democratizes 
>> "magic". The idea is that, if you do
>>
>> a = b + c;
>>
>> and b + c does not make sense but b and c are ranges for which a.front 
>> = b.front + c.front does make sense, to automatically add the 
>> iteration paraphernalia.
>>
>> 3. It was mentioned in this group that if getopt() does not work in 
>> SafeD, then SafeD may as well pack and go home. I agree. We need to 
>> make it work. Three ideas discussed with Walter:
>>
>> * Allow taking addresses of locals, but in that case switch allocation 
>> from stack to heap, just like with delegates. If we only do that in 
>> SafeD, behavior will be different than with regular D. In any case, 
>> it's an inefficient proposition, particularly for getopt() which 
>> actually does not need to escape the addresses - just fills them up.
>>
>> * Allow @trusted (and maybe even @safe) functions to receive addresses 
>> of locals. Statically check that they never escape an address of a 
>> parameter. I think this is very interesting because it enlarges the 
>> common ground of D and SafeD.
>>
>> * Figure out a way to reconcile "ref" with variadics. This is the 
>> actual reason why getopt chose to traffic in addresses, and fixing it 
>> is the logical choice and my personal favorite.
>>
>> 4. Allow private members inside a template using the eponymous trick:
>>
>> template wyda(int x) {
>>    private enum geeba = x / 2;
>>    alias geeba wyda;
>> }
>>
>> The names inside an eponymous template are only accessible to the 
>> current instantiation. For example, wyda!5 cannot access 
>> wyda!(4).geeba, only its own geeba. That we we elegantly avoid the 
>> issue "where is this symbol looked up?"
>>
>> 5. Chain exceptions instead of having a recurrent exception terminate 
>> the program. I'll dedicate a separate post to this.
>>
>> 6. There must be many things I forgot to mention, or that cause grief 
>> to many of us. Please add to/comment on this list.
>>
>>
>>
>> Andrei
> 
> I kinda like this proposal. But I would rather call template like below:
> 
> T opInfix(string op)(T rhs) { ... }
> T opPrefix(string op)(T rhs) { ... }
> T opPostfix(string op)(T rhs) { ... }
> 
> and allow user to define her own operators (though it doesn't have to be 
> done now).
> 
> I know that quite a few people here doesn't like to allow users to 
> define their own operators, because it might obfuscate code. But it 
> doesn't have to be like this. Someone here already mentioned here that 
> it is not real problem for programs in C++. Good libraries don't abuse 
> this functionality.
> 
> User defined operators would allow easy definition of Domain Specific 
> Languages in D. I was already writing about it some time ago:
> 
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81026 
> 
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81352 
> 
> 
> BR
> Marcin Kuszczak
> (aarti_pl)

Sweet, I've been waiting for a way to implement brainfuck using operators!

auto bf = new BrainFuck();
bf++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.;
writef(bf.toString()); // outputs "Hello World!\n"