Why Ruby?

Nick Sabalausky a at a.a
Mon Dec 13 09:12:27 PST 2010


"Ary Borenszweig" <ary at esperanto.org.ar> wrote in message 
news:ie4ui8$174a$1 at digitalmars.com...
> On 12/13/2010 12:23 AM, Adam D. Ruppe wrote:
>> Ary Borenszweig wrote:
>>> D should provide a yield keyword that basically
>>> rewrites the body of the method into the first code.
>>
>> Don't need to change the language for that.
>>
>> =========
>>
>> string yield(string what) {
>>    return `if(auto result = dg(`~what~`)) return result;`;
>> }
>>
>> class Foo
>> {
>>      uint array[2];
>>
>>      int opApply(int delegate(ref uint) dg) {
>>           mixin(yield("array[0]"));
>>           mixin(yield("array[1]"));
>>
>> return 0;
>>      }
>> }
>> =========
>>
>> Compiles and runs as expected, on today's D.
>
> Cool!!
>
> But it's kind of too much what you have to write. I like that you can do 
> it without modifying the language, but sometimes it's better to have it 
> directly in the language if it's you are going to use it often and it's 
> useful. Remembering to put mixin() and enclosing the expression in a 
> string is not very nice to the eyes.
>
> I really like string mixins as they are inserted as is into the code, so 
> there's no overhead in the call. It would be really cool if you could mark 
> a function as being a string mixin, and then to do:
>
> @mixin
> string yield(string what) {
>   return `if(auto result = dg(`~what~`)) return result;`;
> }
>
> class Foo
> {
>     uint array[2];
>
>     int opApply(int delegate(ref uint) dg) {
>          yield(array[0]);
>          yield(array[1]);
>
> return 0;
>     }
> }
>
> So that basically would work like this:
>
> - @mixin tells the compiler it's a string mixin because the function 
> returns a string.

I've suggested that before, but it only got applied to template mixins which 
IMO isn't nearly as useful or desireable as doing the same for string 
mixins. I still really want to see it.

> - In the semantic analysis the compiler needs to invoke yield(array[0]). 
> It can see that yield is marked as @mixin, so instead of applying semantic 
> analysis to array[0] it just converts it back to a string (I remember 
> there exists such thing in DMD's source code) and then passes it to yield.
>

The ability the get a string representation of the argument passd by the 
caller would definitely be a great thing to have. Although I think it would 
be better placed in __traits or the proposed magic "meta" namespace, etc. 
That way any function, @mixin or not, can use it or not use it whenever it 
wants, and it wouldn't add any potentially confusing semantic complexity.




More information about the Digitalmars-d mailing list