Curious thoughts, regarding functional programming

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Wed Oct 12 09:18:37 PDT 2011


You never know when exactly and in which conditions will that delegate
get called. You can't decide to quit something you don't know anything
about.

On Wed, Oct 12, 2011 at 8:08 PM, Jacob Carlborg <doob at me.com> wrote:
> On 2011-10-12 14:35, Gor Gyolchanyan wrote:
>>
>> The semicolon technique has occurred to me, but seemed a bit too
>> radical (I loved it nonetheless).
>> The "hard" return should not be available IMO. The delegate should
>> never have control over who calls it.
>> It's totally wrong... IMO.
>
> It has it uses and it's possible to do so in Ruby.
>
>> On Wed, Oct 12, 2011 at 4:13 PM, Jacob Carlborg<doob at me.com>  wrote:
>>>
>>> On 2011-10-12 10:21, Gor Gyolchanyan wrote:
>>>>
>>>> I find myself constantly dreaming about a syntax sugar, which would
>>>> make me (and probably, many others) very happy.
>>>> An important and popular aspect of functional programming is the
>>>> ability to pass delegate literals to functions.
>>>> The downside to this is the ugliness of the resulting code, which
>>>> discourages doing so:
>>>> std.concurrency.spawn({ foreach(i, 0.100) {  } });
>>>> This piece of code has way too much punctuation. Worst of all, the
>>>> entire delegate literal is crammed inside the function call
>>>> parentheses.
>>>> It looks especially ugly when the delegate literal is not a one-liner.
>>>> The way I saw it in my dreams is:
>>>>
>>>> spawn()
>>>> {
>>>>     foreach(i; 0..100) { }
>>>> };
>>>>
>>>> What happened here is, that the delegate moved outside the parentheses.
>>>> This looks awfully like a function definition, right?
>>>> Wrong!
>>>> This does not have a return type, the parameters are not definitions,
>>>> they are values and there is a semicolon at the end (which quickly
>>>> gives a visual clue of what this thing actually is).
>>>> Hey, wait a minute! What about parameters to delegates and what about
>>>> other delegate parameters?
>>>> Well, this will work with only one delegate (or function) parameter
>>>> and the parameters could be specified in a second set of parentheses
>>>> (again this would look like a template, but it actually won't):
>>>>
>>>> spawn(5, 4, 65)(int x, int y, int z)
>>>> {
>>>>    /*...*/
>>>> };
>>>>
>>>> IMO, this looks WAY more beautiful, then what we have now.
>>>> I don't see any reason why this would break existing code.
>>>> I know, I know this is hard to implement and we got better things to do.
>>>> I'm just saying. This would look good.
>>>
>>> This has been proposed several times before. Something like, if a
>>> function
>>> takes a delegate as its last parameter then this syntax would work:
>>>
>>> void unless (bool condition, void delegate () dg)
>>> {
>>>    if (condition)
>>>        dg();
>>> }
>>>
>>> unless(a == b)
>>> {
>>>    // delegate
>>> }
>>>
>>> And passing arguments to the delegate:
>>>
>>> foo(1 ; 2){}
>>>
>>> Any arguments to the left of the semicolon would be passed to the
>>> delegate.
>>> When this feature is talked about you usually want more things, like,
>>> what I
>>> would like to call, "soft" and "hard" returns.
>>>
>>> void iterate (int start, int end, void delegate (int a) dg)
>>> {
>>>    foreach (a ; start .. end)
>>>        dg();
>>> }
>>>
>>> When this delegate is called you want to both be able to just return from
>>> the delegate but also return from "foo".
>>>
>>> iterate(1, 10 ; int a)
>>> {
>>>    if (a == 2)
>>>        yield; // soft return, just returns from the delegate
>>>
>>>    else if (a == 4)
>>>        return; // hard return, return from both the delegate and the
>>> function that called the delegate
>>> }
>>>
>>> Currently we only have "soft" returns from delegates.
>>>
>>> --
>>> /Jacob Carlborg
>>>
>
>
> --
> /Jacob Carlborg
>


More information about the Digitalmars-d mailing list