[erlang-questions] If you could rename ports, what would you call them?

[Masklinn]

On 2010-10-05, at 17:04 , Joe Armstrong wrote:
> On Tue, Oct 5, 2010 at 11:02 AM, Masklinn <masklinn@REDACTED> wrote:
>> On 2010-10-05, at 10:34 , Joe Armstrong wrote:
>>> Pids
>>> 
>>> There shouldn't be ports in the language at all (sorry) - ports should
>>> in all circumstances
>>> behave and be indistinguishable from Pids.  open_port(...) should
>>> return a Pid and not a port.
>>> 
>>> We should reduce the number of concepts in the langauge not increase
>>> them - all in the
>>> name of conceptual integrity.
>>> 
>>> /Joe
>> 
>> But they *are* two different concepts.
> 
> But they shouldn't have been different - sure they have a differnt way
> of being created.
> 
> There should be the notion of "creating a thing that behaves like a
> process" that is actually
> not a process, which which behaves like a process.
Some kind of "messageable" object protocol? Yeah that would be nice. But that wouldn't stop people from needing to refer to these messageables as what they are when discussing e.g. their implementation details. If you're implementing a port or a port driver, you have to talk about it as that, or go through hoops to express it. Which ends up the same.

> Ets tables and
> ports should have
> been "things that behave like processes" - they should respond to messages and
> send exits when they die and so on. If they had behaved like processes
> then life would be
> easier and more regular ... If ports where pids then one would be able
> to access ports on
> remote nodes via their pids (just like remote pids in distributed erlang).
From the user's (of the process/port/table) point of view, sure, I completely agree, but that doesn't solve the implementor's problem.

> The erlang view of the world is "everything is a process" - all you
> should need to know
> is how to create a process and what protocol the process obeys -
> otherwise these things should
> obey "process semantics" this should be true for ets tables and ports …
As I said, that's nice when you're using these objects/systems in implementing your program, but it's not feasible (or useless as you prefer) when you're implementing one of them: you don't implement a port the same way you implement a process, and you still might need to discuss them as that when discussing implementing them. Saying that everything is a process doesn't help there, it would just lead to people calling them "ets process" and "ports process" and we're back to square one.