F# client

Dec 31, 2012 at 9:50 AM

Hello!

There is already actor like communication in F# (Agents/Mailboxes).

I'm looking forward to see how this will communicate with F#-client. It shouldn't be too complex...

 

Apr 11, 2013 at 7:55 PM
Edited Apr 11, 2013 at 9:17 PM
The thing here is that if "Actor Framework" is a real Erlang style actor-model, the actor should be able to update its own functionality on the fly.
This is not easily done with F# mailbox as F# has (not only strong typing but also) static typing.

If you have watched this:
http://www.infoq.com/presentations/Message-Passing-Concurrency

And focus on slide 37, the corresponding F# would be something like this:
http://fssnip.net/h3
If you change the Actor's functionality on the fly, you would probably also like to change the type of the state.
But the static type system has already limited the state type signature and the function type signature.
(There are workarounds but not very pretty ones...)

It would need a dynamic language. C# has dynamic. Microsoft already serialize expression trees e.g. in StreamInsight 2.1 (see this video, 1:14:00-...). So Actor Framework could be more "real" Actor model... But I hope the programming interface / syntax would still be quite as easy as in Erlang or F#. :-)
Developer
May 9, 2013 at 3:12 PM
Hi Thorium,

I can't pretend to be an expert in either F# or Erlang. But, to answer some of your questions:

Re "If you change the Actor's functionality on the fly, you would probably also like to change the type of the state. ": No, because the type of the state (Dictionary<string,object>) is very general. Functionality is represented by method calls stored in the actor state, where the key is the method name and the value is the method represented as a Func<IActorState, object[], object>. Because all methods have this very general signature, it is easy to track and call them in a general fashion.

Re "It would need a dynamic language. C# has dynamic." : Well, you can get by without dynamic language support. The IActorState interface, an instance of which is provided to the method by the runtime, has generic calls allowing you to manipulate data in the underlying state, which is a Dictionary<string, object>. You just have to do a lot if casting to and from type "object" in the process.

That being said, we did add dynamic support fairly recently, so that your actor method can either be a Func<IActorState, object[], object> or a Func<dynamic, dynamic[], object>. That would allow you to rewrite this:
[ActorMethod]
public static object MyMethod(IActorState state, object[] args)
{
    var input = (int) args[0];
    state.Set("Foo", input);
    return state.Get("Bar");
} 
as this:
[ActorMethod]
public static object MyMethod(dynamic state, dynamic[] args)
{
    int input = args[0];
    state.Foo = input;
    return state.Bar;
} 
It allows for more terse coding, while giving up compile-time type checking.
Sep 5, 2013 at 5:33 AM
Thorium wrote:
The thing here is that if "Actor Framework" is a real Erlang style actor-model, the actor should be able to update its own functionality on the fly.
This is not easily done with F# mailbox as F# has (not only strong typing but also) static typing.

And focus on slide 37, the corresponding F# would be something like this:
http://fssnip.net/h3
If you change the Actor's functionality on the fly, you would probably also like to change the type of the state.
But the static type system has already limited the state type signature and the function type signature.
(There are workarounds but not very pretty ones...)
I don't think L'Agent is "not very pretty": http://code.msdn.microsoft.com/windowsdesktop/LAgent-an-agent-framework-6530ff5b

In addition, recent developments in building out F# interactive and SimpleCompilerServices provide additional means of leveraging either string- or quotation-formatted F# code to provide on the fly updates.
It would need a dynamic language. C# has dynamic. Microsoft already serialize expression trees e.g. in StreamInsight 2.1 (see this video, 1:14:00-...). So Actor Framework could be more "real" Actor model... But I hope the programming interface / syntax would still be quite as easy as in Erlang or F#. :-)
F#'s dynamic operators provide highly customizable dynamic access, so I'm not sure of your point here.
Sep 5, 2013 at 5:35 AM
joehoag wrote:
It allows for more terse coding, while giving up compile-time type checking.
How does it give up compile-time checking? You won't get IntelliSense, but dictionary keys are not checked by the compiler, so you won't get much help either way. Or does ActorFx come with additional targets that help with that?
Sep 5, 2013 at 5:45 AM
Sep 15, 2013 at 4:19 PM
Thanks Ryan, I'll try those!