Agents -- two open operands to one ?

[Howard Thomson]

Hi,

I am familiar with the syntax for an agent with one open and one closed operand, as directly useable in:

expose_actions.extend (agent draw_date (?, l_grid_item))

which works in the original [single] context in which I wrote it.

Can I pass an agent to a routine with two open operands, and then close the second operand

within the routine which can then call expose_actions.extend with the modified agent ?

All my attempts have so far been rejected by EiffelStudio 19.12 ...

Regards,

Howard

[Gachoud Philippe]

Hi, take a look at stackoverflow -> eiffel agent. I remember I had a similar question....

https://stackoverflow.com/questions/55406410/eiffel-passing-argument-to-agent-received-as-argument

Maybe this one answers your question. The idea is to encapsulate your call into another with only one argument as far as I remember

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CAFsPJYJOiKMc-b0RvFkRv-Qwuuf9JrnydGd0sqffQgsE4YSmDw%40mail.gmail.com.

--

**********************************************

Philippe Gachoud

Puerto Williams 6657

Las Condes

Santiago de Chile

+56 934022210
ph.ga...@gmail.com

RUT: 26374747-k

**********************************************

[Alexander Kogtenkov]

You are talking about "currying". Routine classes are using tuples to pass arguments to feature calls. As a result, direct currying is impossible (as, I guess, you figured out by trial and error). A wrapper (as pointed out in another reply) can be used instead.

 

Let’s look at an example. Suppose, 3 local variables are declared and initialized as follows:

 

        local
            x: PROCEDURE [STRING, STRING]
            y, z: PROCEDURE [STRING]
        do
            x := agent (a, b: STRING) do print (a + b + "%N") end
            y := currying.close_1 (x, "a")
            z := currying.close_2 (x, "b")

 

The desired effect of the subsequent calls

 

            x ("a", "b")
            y ("y")
            z ("z")

 

is the following output:

 

ab
ay
zb

 

The wrapping is done using a helper feature `currying` declared as

 

    currying: CURRYING_2 [STRING, STRING] once create Result end

 

where CURRYING_2 is the class that performs wrapping and unwrapping of the tuples in the calls.

 

class CURRYING_2 [G1, G2]

feature -- Partial application

    close_1 (p: PROCEDURE [G1, G2]; a: G1): PROCEDURE [G2]
            -- Close argument #1 of `p` with `a`.
        do
            Result := agent curry (p, a, ?)
        end

    close_2 (p: PROCEDURE [G1, G2]; a: G2): PROCEDURE [G1]
            -- Close argument #2 of `p` with `a`.
        do
            Result := agent curry (p, ?, a)
        end

feature {NONE} -- Wrapper

    curry (p: PROCEDURE [G1, G2]; a1: G1; a2: G2)
            -- Call `p` with arguments `a1` and `a2`.
        do
            p (a1, a2)
        end

end

 

The class is generic, therefore, the actual parameters [STRING, STRING] at the client side can be replaced with the types suitable in your context.

 

Regards,

Alexander Kogtenkov

 

 

Howard Thomson <howard.a...@gmail.com>:
 

--

[Ulrich Windl]

>>> "'Alexander Kogtenkov' via Eiffel Users" <eiffel...@googlegroups.com>
schrieb am 08.04.2021 um 10:03 in Nachricht
<1617868989...@f301.i.mail.ru>:

> You are talking about "currying". Routine classes are using tuples to pass
> arguments to feature calls. As a result, direct currying is impossible (as,
I
> guess, you figured out by trial and error). A wrapper (as pointed out in
> another reply) can be used instead.
>
> Let’s look at an example. Suppose, 3 local variables are declared and
> initialized as follows:
>
> local
> x: PROCEDURE [STRING, STRING]
> y, z: PROCEDURE [STRING]
> do
> x := agent (a, b: STRING) do print (a + b + "%N") end
> y := currying.close_1 (x, "a")
> z := currying.close_2 (x, "b")
>
> The desired effect of the subsequent calls
>
> x ("a", "b")
> y ("y")
> z ("z")
>
> is the following output:
>
> ab
> ay
> zb

Sorry I couldn't resist doing it in Perl:
DB<1> $x = sub($$) { print "$_[0]$_[1]\n" }
DB<2> $y = sub($) { $x->("a", $_[0]) }
DB<3> $z = sub($) { $x->($_[0], "b") }

DB<4> $x->("a", "b")
ab
DB<5> $y->("y")
ay
DB<6> $z->("z")
zb

I think Perl's closures are much more elegant.

Regards,
Ulrich

https://groups.google.com/d/msgid/eiffel-users/1617868989.443136361%40f301.i.
> mail.ru.

[Alexander Kogtenkov]

Eiffel is constantly evolving in the direction of simplification. For example, the presented code uses much more readable PROCEDURE [STRING, STRING] instead of the old PROCEDURE [ANY, TUPLE [STRING, STRING]]. Similarly, at some point it should be possible to replace the boilerplate code (including the wrapper class) with

 

    y := agent x ("y", ?)

    z := agent x (?, "z")

 

The wrapper mentioned earlier addresses the need with the currently existing mechanisms, is reusable, and does not go too far from the version above.

 

Regards,

Alexander Kogtenkov

 

 

Ulrich Windl <ulrich...@rz.uni-regensburg.de>:
 

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/606EC829020000A1000403BA%40gwsmtp.uni-regensburg.de.

 

[howard.thomson]

Thanks to all -- My current problem resolved, and looking forward to further currying simplifications ...

Regards, Howard

[Philippe P]

To Alexander Kogtenkov : 

About the possible additional simplifications of currying that you mentioned, are they included in the working paper 

"Eiffel as a functional programming language" (created in 2012, last updated in 2014) ?

To Bertrand Meyer : 

The evolution of Eiffel has been ongoing for several years. Would it be possible to give some visibility to the Eiffel community ? 

Of course, this is not a request for a roadmap or unveiling current work, but some points of time would be appreciated.

Is it reasonable to think that a new revision of the ECMA could be published in the next 3 years ?

Thank you,

Philippe.

[Alexander Kogtenkov]

What a wonderful link — I could not imagine how many things were thought of so a long time ago. Moreover, many things have been implemented partially, completely or even with a better outcome than initially expected. But you are right, the document does not include all potential improvements, including currying. Still, new language mechanisms continue coming with every new release of EiffelStudio even when they are not mentioned in the document.

 

Regards,

Alexander Kogtenkov

 

 

Philippe P <pka...@gmail.com>:
 

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/c6fe4f0e-b654-4498-81c0-7c85ce444a40n%40googlegroups.com.