What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

nesvarbu Pavarde
Why create illusion that you are sending a Fun to remote node to execute in a new process? If client node has to have same module loadable with the Fun defined as a server node anyway. Why not only spawn(Node, M, F, A) then, which makes it clear that you are sending a definition of a function call, not Fun itself.
I am experimenting with distributed Erlang and want it to pass clojures around "willy nilly", even through network. "Code is data" kinda thing.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

Nathaniel Waisbrot
> Why create illusion that you are sending a Fun to remote node to execute in a new process? If client node has to have same module loadable with the Fun defined as a server node anyway. Why not only spawn(Node, M, F, A) then, which makes it clear that you are sending a definition of a function call, not Fun itself.
> I am experimenting with distributed Erlang and want it to pass clojures around "willy nilly", even through network. "Code is data" kinda thing.



http://stackoverflow.com/q/39255471/1220269

Are you the same person as "Sharas" who posted this question on StackOverflow, or are you just copy/pasting it to this list?

It seems like several people already put good effort into answering there.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

Matthias Lang
In reply to this post by nesvarbu Pavarde
Hi,

Thanks Nathaniel for pointing out that this is a dupe of a
stackoverflow question. It's good form to indicate when you're
aware of previous discussion and, perhaps, why you're not satisifed.

My guess is OP isn't satisifed because

  a) The two top-voted stack overflow answers gloss over the
     difference between funs defined in the shell and funs
     defined in code.

  b) Neither of the top-voted answers deals with the question the
     OP opens with.

Kresten's blog post, which is linked from the stack overflow comments,
is good, but it causes confusion for people who don't read it
carefully. One source of confusion is that it gives an example of a
fun which _does_ include the definition, says that the definition
isn't included and then, seven paragraphs later, explains that the
first example did actually include the definition.

Similarly, Joe has a blog post which was up on Hacker News (again?)
just a few days ago with an example which borders on being overly cute:

  http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html

this similarly creates the impression that all you have to do is send
a fun to server and you're done, not even giving a nod to the problem
that you need to get the code to all 1171 nodes he wants to run the
code on.

---


I'd like to wrap up with a proper answer, the sort that Richard
Carlsson might write, but I don't have time for that. It would:

  - cover the difference between funs defined in the shell, funs which
    contain actual code and/or variables and funs which are pure
    references, e.g. fun io:fwrite/2

  - comment on the OP's mis-use of the word "definition" and cleaning
    up other language sloppiness to avoid disagreements and confusion
    caused by misunderstanding.

  - talk about how it's nice that the concept of funs is the same across
    lots of different uses, i.e. passing to lists:filter/2, sending
    to a local process, sending to a remote process and spawning, and
    that the cost of getting a fairly harmless surprise or two in the
    distributed case is low compared to the benefit of the concept being
    so simple.

  - speculate on the possibility of an Erlang system which
    automaticaly distributes code when you send a fun. It seems
    possible, the fun includes information about where it came from.

    My guess is that there's a simple, sane, useful case of
    distributed Erlang, which the case where you make sure all nodes
    have the same code from the start.

    Then there's the case where nodes don't all have the same code,
    and that case is messy and complicated. There are problems such as
    "what do you do if the fun refers to a different version of a module
    which is already loaded on the receiving node?". This feels like
    research, not "getting things done", and I'm into the latter.

Matthias

----------------------------------------------------------------------

Date: 01. September 2016
From: nesvarbu Pavarde <[hidden email]>
To [hidden email]
Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?


> Why create illusion that you are sending a Fun to remote node to execute in
> a new process? If client node has to have same module loadable with the Fun
> defined as a server node anyway. Why not only spawn(Node, M, F, A) then,
> which makes it clear that you are sending a definition of a function call,
> not Fun itself.
> I am experimenting with distributed Erlang and want it to pass clojures
> around "willy nilly", even through network. "Code is data" kinda thing.

> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

Joe Armstrong-2
I posted some information about why things are as they are:

http://erlang.org/pipermail/erlang-questions/2016-July/089809.html

The reason is historical - In the first distributed erlang all nodes
accessed a common file store - this is no longer true when the nodes
have separated stores.

"All you have to do" (TM) is make sure all nodes have the same
code before sending funs around. This is not easy in the general case,
since all the code the fun calls also needs to be copied, and all the
code it calls and so on. If the code is in more than two versions or
changing in different places in the system at the same time this sould
be very tricky.

A "stop all nodes, send code to all nodes, restart all nodes" solution is
easy to implement and pretty foolproof.

Not elegant but it gets the job done.

/Joe

On Fri, Sep 2, 2016 at 9:09 AM, Matthias Lang <[hidden email]> wrote:

> Hi,
>
> Thanks Nathaniel for pointing out that this is a dupe of a
> stackoverflow question. It's good form to indicate when you're
> aware of previous discussion and, perhaps, why you're not satisifed.
>
> My guess is OP isn't satisifed because
>
>   a) The two top-voted stack overflow answers gloss over the
>      difference between funs defined in the shell and funs
>      defined in code.
>
>   b) Neither of the top-voted answers deals with the question the
>      OP opens with.
>
> Kresten's blog post, which is linked from the stack overflow comments,
> is good, but it causes confusion for people who don't read it
> carefully. One source of confusion is that it gives an example of a
> fun which _does_ include the definition, says that the definition
> isn't included and then, seven paragraphs later, explains that the
> first example did actually include the definition.
>
> Similarly, Joe has a blog post which was up on Hacker News (again?)
> just a few days ago with an example which borders on being overly cute:
>
>   http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html
>
> this similarly creates the impression that all you have to do is send
> a fun to server and you're done, not even giving a nod to the problem
> that you need to get the code to all 1171 nodes he wants to run the
> code on.
>
> ---
>
>
> I'd like to wrap up with a proper answer, the sort that Richard
> Carlsson might write, but I don't have time for that. It would:
>
>   - cover the difference between funs defined in the shell, funs which
>     contain actual code and/or variables and funs which are pure
>     references, e.g. fun io:fwrite/2
>
>   - comment on the OP's mis-use of the word "definition" and cleaning
>     up other language sloppiness to avoid disagreements and confusion
>     caused by misunderstanding.
>
>   - talk about how it's nice that the concept of funs is the same across
>     lots of different uses, i.e. passing to lists:filter/2, sending
>     to a local process, sending to a remote process and spawning, and
>     that the cost of getting a fairly harmless surprise or two in the
>     distributed case is low compared to the benefit of the concept being
>     so simple.
>
>   - speculate on the possibility of an Erlang system which
>     automaticaly distributes code when you send a fun. It seems
>     possible, the fun includes information about where it came from.
>
>     My guess is that there's a simple, sane, useful case of
>     distributed Erlang, which the case where you make sure all nodes
>     have the same code from the start.
>
>     Then there's the case where nodes don't all have the same code,
>     and that case is messy and complicated. There are problems such as
>     "what do you do if the fun refers to a different version of a module
>     which is already loaded on the receiving node?". This feels like
>     research, not "getting things done", and I'm into the latter.
>
> Matthias
>
> ----------------------------------------------------------------------
>
> Date: 01. September 2016
> From: nesvarbu Pavarde <[hidden email]>
> To [hidden email]
> Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?
>
>
>> Why create illusion that you are sending a Fun to remote node to execute in
>> a new process? If client node has to have same module loadable with the Fun
>> defined as a server node anyway. Why not only spawn(Node, M, F, A) then,
>> which makes it clear that you are sending a definition of a function call,
>> not Fun itself.
>> I am experimenting with distributed Erlang and want it to pass clojures
>> around "willy nilly", even through network. "Code is data" kinda thing.
>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

Matthias Lang
Hi,

On 02. September 2016, Joe Armstrong wrote:

> I posted some information about why things are as they are:

> http://erlang.org/pipermail/erlang-questions/2016-July/089809.html

Interesting thread, shame I missed it during summer.

I thought a bit about how this could be hacked together and came up
with two ideas. One is to hack the code server. Tony showed how to
do that later in the thread you linked above.

The other is to use the 'inet' loader to do demand loading. I half
expected that to require some hacking, but it actually works straight
off. Here's an example of receiving a fun from a remote node and
running it without having a local copy of the .beam:

  >erl -sname a -loader inet -hosts 192.168.1.4
  Erlang/OTP 18 [erts-7.3] [source] ...
  Eshell V7.3  (abort with ^G)
  (a@hec)1> global:register_name(mml, self()).
  yes
  (a@hec)2> Y = receive X -> X end.
  #Fun<cc.0.109044139>
  (a@hec)3> code:is_loaded(cc).
  false
  (a@hec)4> erlang:fun_info(Y, module).
  {module,cc}
  (a@hec)5> erlang:fun_info(Y, pid).
  {pid,<7389.70.0>}
  (a@hec)6> Y().
  "this is a fun"

The fun I sent was defined, in a .beam, like this:

  d() -> fun() -> "this is a fun" end.

and I sent it from the remote node like this:

  global:whereis_name(mml) ! cc:d().

the remote node was running a boot server, i.e.

  erl_boot_server:start(["192.168.1.4"]).

---

One limitation is that the code server has to contain all the code
that might be run in the network of nodes. You can specify multiple
code servers (the -hosts argument), but they don't get used
concurrently, it's just fail-over. So you can't have some modules
on one node and some on another and have it magically work.

Another limitation is that you can't run a code server on a diskless
node. 'erl_boot_server' uses erl_prim_loader:prim_get_file/2 which
only reads from the filesystem, unlike erl_prim_loader:get_file/2.
I'm not sure why, maybe just "keep it simple" and avoid problems with
cyclic code server graphs.

I briefly wondered why there's no 'get_code/1' BIF which gives you
loaded code even if no .beam file is present. I then remembered that
the beam loader rewrites things, so you'd have to store a copy of
the .beam anyway to provide that.

A comment at the top of 'erl_boot_server.erl' mentions CP and DP, so
I'm guessing the feature is courtesty of AXD-301 (CP = Central
Processor, DP = Device Processor) and also I'd guess that DPs were
diskless.

> The reason is historical - In the first distributed erlang all nodes
> accessed a common file store - this is no longer true when the nodes
> have separated stores.

It looks like AXD-301 moved forwards on this, though in a pragmatic
"change as little as possible" way.

(I'm not advocating sending code around a distributed erlang system, I
can't think of a practical use where "just start off with all code on
all nodes" isn't the sane, robust approach. I just got curious.)

Matt
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

Richard A. O'Keefe-2
In reply to this post by Joe Armstrong-2


On 3/09/16 2:45 AM, Joe Armstrong wrote:
>
> "All you have to do" (TM) is make sure all nodes have the same
> code before sending funs around. This is not easy in the general case,
> since all the code the fun calls also needs to be copied, and all the
> code it calls and so on.

This could of course be done lazily, but that would (probably)
lead to unexpected and quite long delays later on, which is a
Bad Thing in a "soft real time" language.

This may be the best reason for not even trying to do it
(lazily OR eagerly).  When you send a message to another node,
you'd like to have some idea of how much you're sending and
(in very rough terms) how long it's likely to take, but quite
a small fun might drag in quite a lot of dependencies, or not,
depending on how much code the sender and receiver already
share.

Something of the sort *can* be done.  Kali Scheme used to
let you send code around.  Someone seems to be trying to
revive it: http://community.schemewiki.org/kali-scheme/
http://community.schemewiki.org/?kali-scheme-revival

In order to make something like this work, I think we really
need something like Chris Brown's ideas for SafeErlang, a
scheme in which multiple versions of modules can co-exist
without confusion.

> A "stop all nodes, send code to all nodes, restart all nodes" solution is
> easy to implement and pretty foolproof.
>
> Not elegant but it gets the job done.

I'm not sure that it's all that inelegant.
You pay the price when you *expect* to pay the price,
and you can check that the "upgrade" will land you in
a sensible state before you make any change..


There is of course another possibility.
If you need to send "pieces of behaviour" to another node,
you can define a mini-language represented as Erlang
data structures as part of the protocol, and send something
over that is a *scrutable* data structure in which general
Bad Things simply aren't expressible, and that can be
interpreted or compiled to Erlang by the receiver as it
chooses.  "Stuff we can run" doesn't have to be Erlang
any more than it has to be ARM assembly code.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

Alex Arnon
Would an Erlang AST do it?


On Mon, Sep 5, 2016 at 3:20 AM, Richard A. O'Keefe <[hidden email]> wrote:
 
[SNIP]

 
There is of course another possibility.
If you need to send "pieces of behaviour" to another node,
you can define a mini-language represented as Erlang
data structures as part of the protocol, and send something
over that is a *scrutable* data structure in which general
Bad Things simply aren't expressible, and that can be
interpreted or compiled to Erlang by the receiver as it
chooses.  "Stuff we can run" doesn't have to be Erlang
any more than it has to be ARM assembly code.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

Richard A. O'Keefe-2


On 6/09/16 5:23 PM, Alex Arnon wrote:
> Would an Erlang AST do it?

You missed the point.
We *have* an Erlang AST.
That can, of necessity, express ANYTHING that Erlang can.
The great benefit of a mini-language is that it CAN'T.
In general, such a mini-language

>     is a *scrutible* data structure in which general
>     Bad Things simply aren't expressible

Accepting code from a remote source is always a risk,
UNLESS it is tightly constrained so that you KNOW even
before you look that it can't be so very bad.
For example, if you want to write some sort of
distributed game, and have players send "scripts" for
their pieces to a game server, you want to KNOW that
the scripts execute in bounded time and can only do
game-related stuff.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

Josh Adams-2
In reply to this post by Joe Armstrong-2
"All you have to do" (TM) is make sure all nodes have the same
code before sending funs around. This is not easy in the general case,
since all the code the fun calls also needs to be copied, and all the
code it calls and so on. If the code is in more than two versions or
changing in different places in the system at the same time this sould
be very tricky.

I have been waiting for a chance to interject something into exactly this sort of discussion by Really Smart People.

Unison is a language.  Here's its 'about' page: http://unisonweb.org/2015-05-07/about.html#post-start .  Search for "distributed systems" to get to the meatiest/most-fun bit of the intro.  Here's a brief and incomplete/wrong summary:

- It's a typed language.
- It has distribution primitives.
- It has a semantic editor - programs don't require lexing/parsing from unicode.
- It covers the fundamental things Joe mentions in this article on IPFS: http://joearms.github.io/2015/03/12/The_web_of_names.html
- Here's a nice deeper-dive into its API for distributed evaluation / distributed systems: http://unisonweb.org/2015-06-02/distributed-evaluation.html

I desperately want to hear the super smart people on this Mailing List tell me (why it's dumb | zomg that's so neat! | we tried this in 2003 with BitDonkey2000 and it didn't work fundamentally because X | more nuanced responses).  Has anyone seen this before and/or on seeing it now does any of it strike you as interesting?

(also, and related: geez I wish I 'got' session types)

-Josh 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

Alex Arnon
In reply to this post by Richard A. O'Keefe-2
I know we have an AST, my question should have been phrased "would the Erlang AST itself be appropriate?".
Would it be appropriate in the scenario, where peer servers ship fun invocations around, without the need for security checks and constraints?

On Wed, Sep 7, 2016 at 3:08 AM, Richard A. O'Keefe <[hidden email]> wrote:


On 6/09/16 5:23 PM, Alex Arnon wrote:
Would an Erlang AST do it?

You missed the point.
We *have* an Erlang AST.
That can, of necessity, express ANYTHING that Erlang can.
The great benefit of a mini-language is that it CAN'T.
In general, such a mini-language

    is a *scrutible* data structure in which general
    Bad Things simply aren't expressible

Accepting code from a remote source is always a risk,
UNLESS it is tightly constrained so that you KNOW even
before you look that it can't be so very bad.
For example, if you want to write some sort of
distributed game, and have players send "scripts" for
their pieces to a game server, you want to KNOW that
the scripts execute in bounded time and can only do
game-related stuff.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

nesvarbu Pavarde
In reply to this post by Richard A. O'Keefe-2
It sounds to me as a question of authorization. Clients could potentially send arbitrary code to execute, and recipient node should be able to decide which clients are authorized for running the code on it.

On September 6, 2016 8:08:00 PM EDT, "Richard A. O'Keefe" <[hidden email]> wrote:


On 6/09/16 5:23 PM, Alex Arnon wrote:
Would an Erlang AST do it?

You missed the point.
We *have* an Erlang AST.
That can, of necessity, express ANYTHING that Erlang can.
The great benefit of a mini-language is that it CAN'T.
In general, such a mini-language

is a *scrutible* data structure in which general
Bad Things simply aren't expressible

Accepting code from a remote source is always a risk,
UNLESS it is tightly constrained so that you KNOW even
before you look that it can't be so very bad.
For example, if you want to write some sort of
distributed game, and have players send "scripts" for
their pieces to a game server, you want to KNOW that
the scripts execute in bounded time and can only do
game-related stuff.



erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

John Doe
In reply to this post by Alex Arnon
Also don't forget that funs are actually closures, so it is necessary to pass the context as well.

2016-09-07 13:15 GMT+03:00 Alex Arnon <[hidden email]>:
I know we have an AST, my question should have been phrased "would the Erlang AST itself be appropriate?".
Would it be appropriate in the scenario, where peer servers ship fun invocations around, without the need for security checks and constraints?

On Wed, Sep 7, 2016 at 3:08 AM, Richard A. O'Keefe <[hidden email]> wrote:


On 6/09/16 5:23 PM, Alex Arnon wrote:
Would an Erlang AST do it?

You missed the point.
We *have* an Erlang AST.
That can, of necessity, express ANYTHING that Erlang can.
The great benefit of a mini-language is that it CAN'T.
In general, such a mini-language

    is a *scrutible* data structure in which general
    Bad Things simply aren't expressible

Accepting code from a remote source is always a risk,
UNLESS it is tightly constrained so that you KNOW even
before you look that it can't be so very bad.
For example, if you want to write some sort of
distributed game, and have players send "scripts" for
their pieces to a game server, you want to KNOW that
the scripts execute in bounded time and can only do
game-related stuff.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

nesvarbu Pavarde
In reply to this post by Joe Armstrong-2
"A "stop all nodes, send code to all nodes, restart all nodes" solution is
easy to implement and pretty foolproof."

Where did 9 9ines availability with erlang go then? If you have to stop nodes.

How do you do code changes without stopping all nodes?

The bit that inspired my about erlang is ability to deploy your code in small batches and evolve your system as you learn. Mashes well with "let it crash" in my understanding: Let it crash, as in don't try to predict what will go wrong, learn from things going wrong, and adapt (change code) fast.


On September 2, 2016 10:45:12 AM EDT, Joe Armstrong <[hidden email]> wrote:
I posted some information about why things are as they are:

http://erlang.org/pipermail/erlang-questions/2016-July/089809.html

The reason is historical - In the first distributed erlang all nodes
accessed a common file store - this is no longer true when the nodes
have separated stores.

"All you have to do" (TM) is make sure all nodes have the same
code before sending funs around. This is not easy in the general case,
since all the code the fun calls also needs to be copied, and all the
code it calls and so on. If the code is in more than two versions or
changing in different places in the system at the same time this sould
be very tricky.

A "stop all nodes, send code to all nodes, restart all nodes" solution is
easy to implement and pretty foolproof.

Not elegant but it gets the job done.

/Joe

On Fri, Sep 2, 2016 at 9:09 AM, Matthias Lang <[hidden email]> wrote:
Hi,

Thanks Nathaniel for pointing out that this is a dupe of a
stackoverflow question. It's good form to indicate when you're
aware of previous discussion and, perhaps, why you're not satisifed.

My guess is OP isn't satisifed because

a) The two top-voted stack overflow answers gloss over the
difference between funs defined in the shell and funs
defined in code.

b) Neither of the top-voted answers deals with the question the
OP opens with.

Kresten's blog post, which is linked from the stack overflow comments,
is good, but it causes confusion for people who don't read it
carefully. One source of confusion is that it gives a n example of a
fun which _does_ include the definition, says that the definition
isn't included and then, seven paragraphs later, explains that the
first example did actually include the definition.

Similarly, Joe has a blog post which was up on Hacker News (again?)
just a few days ago with an example which borders on being overly cute:

http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html

this similarly creates the impression that all you have to do is send
a fun to server and you're done, not even giving a nod to the problem
that you need to get the code to all 1171 nodes he wants to run the
code on.

---


I'd like to wrap up with a proper answer, the sort that Richard
Carlsson might write, but I don't have time for that. It would:

- cover the difference b etween funs defined in the shell, funs which
contain actual code and/or variables and funs which are pure
references, e.g. fun io:fwrite/2

- comment on the OP's mis-use of the word "definition" and cleaning
up other language sloppiness to avoid disagreements and confusion
caused by misunderstanding.

- talk about how it's nice that the concept of funs is the same across
lots of different uses, i.e. passing to lists:filter/2, sending
to a local process, sending to a remote process and spawning, and
that the cost of getting a fairly harmless surprise or two in the
distributed case is low compared to the benefit of the concept being
so simple.

- speculate on the possibility of an Erlang system which
automaticaly distributes code when you send a fun. It seems
possible, the fun includes information about where it came from.

My guess is that there's a simple, sane, useful case of
distributed Erlang, which the case where you make sure all nodes
have the same code from the start.

Then there's the case where nodes don't all have the same code,
and that case is messy and complicated. There are problems such as
"what do you do if the fun refers to a different version of a module
which is already loaded on the receiving node?". This feels like
research, not "getting things done", and I'm into the latter.

Matthias




Date: 01. September 2016
From: nesvarbu Pavarde <[hidden email]>
To [hidden email]
Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?


Why create illusion that you are sending a Fun to remote node to execute in
a new process? If client node has to have same module loadable with the Fun
defined as a server node anyway. Why not only spawn(Node, M, F, A) then,
which makes it clear that you are sending a definition of a function call,
not Fun itself.
I am experimenting with distributed Erlang and want it to pass clojures
around "willy nilly", even through network. "Code is data" kinda thing.



erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions