Why Ruby?

[Andrej Mitrovic]

Currently this will call unaryFunImpl, which tries to evaluate foo(a)
at compile-time, but foo isn't visible from std.functional, where
unaryFunImpl is defined.

I don't know, maybe Phobos could construct a closure out of the string
somehow if it detected that there's a function call in that string,
here's some pseudocode modified from std.functional:

template unaryFunImpl(alias fun, bool byRef, string parmName = "a")
{
   static if (is(typeof(fun) : string))
   {
       // added: detect if there's a function call in that string
       static if (hasFunctionCalls(fun))
       {
           // if so construct a closure, and that should be it
           alias newclosure result;
       }
       else
       {
           // Otherwise do as usual in std.functional.unaryFunImpl
           template Body(ElementType)
           {
           }
           // old code...
       }
   }
   else
   {
       alias fun result;
   }
}

On 12/19/10, Nick Sabalausky <a at a.a> wrote:
> "Walter Bright" <newshound2 at digitalmars.com> wrote in message
> news:iejl6i$16f5$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> Yes, because in practice "a>b" must end up being evaluated in the wrong
>>> scope. I've used std.algorithm very little so far, and yet I've still
>>> found that limitation to be a problem.
>>
>> But it works fine for trivial lambdas, and if you're going beyond that,
>> there's the fuller, complete syntax.
>
> int foo(int x) { ... }
> map!"foo(a) * 2" // Trivial lambda, but it fails
>
> void bar(int delegate(int) dg) { ... }
> bar("a+7") // Also fails
>
> I don't think it's at all unreasonable to expect both of those to work with
> a short lambda syntax. That neither of them do I think is a clear sign that
> it's more of a clever hack than a real solution.
>
>
>