[erlang-questions] -pidname( <atom> ) Was: Why we need a -module() attribute?

[Richard A. O'Keefe]

On 3/03/16 10:19 pm, Éric Pailleau wrote:

I think it was Griswold, in the context of the SL5 programming language
(the one that came between SNOBOL and Icon), who coined the term
"The Window to Hell".  The SL5 group used the term for aspects of
SL5 that let you look down into the workings of the implementation, in
order to support tracing and debugging.  Here's the reference:

     The WIndow to Hell in SL5.
     Ralph E. Griswold.
     SL5 Project Document s5LD8a
     The University of Arizona
     June 1, 1976

(If anyone has electronic copies of the SL5 project documents, I'd be 
interested
in seeing them.  I read this one years ago, but never owned a copy.)

What's that got to do with Erlang?

First, Erlang can accept user-defined C code.
If you accept an incubus (otherwise known as a NIF) into your bed
(otherwise known as the Erlang VM), you must not be surprised
if you give birth to monsters.
Whatever integrity guarantees Erlang might offer are completely
void if you do that.

(This is not to say that there could not be some safety-checked subset
of C that could be safely added to Erlang, or better still, some sort of
BitC or D or Go variant that gets close to C speed without C's reckless
disregard for life, health, and sanity.  It just hasn't been done yet.
Maybe the right thing to do is like Squeak's Slang: use a variant of
Erlang itself as the safe+fast extension language?)

Second, even pure Erlang has a Window to Hell.
     exit(Pid, Reason) can kill *any* process that is not trapping exits.
     group_leader(Leader, Pid) can set the group leader of any process,
        willing or unwilling, knowing or unknowing
     list_to_pid(String) lets you forge pids
     erlang:ports() returns a list of all the ports on the local node
     erlang:processes() returns a list of all the processes on the local 
node
     erlang:resume_process(Pid) and
     erlang:suspend_process(Pid[, Options]) let you break things in a way
        that even Java's designers couldn't stomach any longer.
and those are just the ones I know about.  The result is that you can NEVER
assume, for example, that a process that has no reason to suspend *isn't*
permanently suspended.  In the Erlang shell, type
 > [erlang:suspend_process(P) || P <- erlang:processes(), P /= self()].
and watch your shell never come back...

IMHO all such dangerous operations should be moved out of 'erlang'
into some separate module (dangerous_internal_erlang_stuff, perhaps)
to be used by debugging and tracing tools, with the compiler warning by
default if you mention that module.  It ought to be even *easier* than
getting a cross-reference to KNOW that your application (including
any libraries or frameworks) doesn't use these operations.

When I try to design "safe" patterns of communication in Erlang,
I always have this tacit "no looking through the Window to Hell,
not inviting succubi into my bed" qualification in mind.
>
> However when you say " only processes that can send you messages are 
> yourself and
> your parent, until one of you passes the pid on to some
> other process. " I do not understand.
>
You are right that in unrestrained Erlang this is not true.
I had my "no hell, no succubi" qualification in mind.

So in a non-demon-haunted Erlang,
if process P spawns process C, then P knows C's pid and can
send messages to it, and C knows its own pid, and can send
messages to itself, but nobody else can until P or C tells them.
In the actual demon-haunted Erlang, very bad things can happen
and there is no way to stop them

Much the same objection was raised to Quintus Prolog.
The module system did many nice things for you, but
it completely failed to provide *trustworthy* isolation,
in order that the debugger (itself implemented in Prolog)
could do the things programmers wanted the debugger to
do.  (The same thing with the Common Lisp systems I
knew anything about, not that that was many of them.)
I not saying "don't HAVE a window to hell", what I'm saying
is that there needs to be a fence around it.



>
> Any process can list all running process at any time and potentially 
> send messages to them.
> You mean those pids have to be hidden,  while existing in process 
> registry ?
>