Proposal to add a call system to CLC-INTERCAL
coppro
I was wondering why the Compiler Language with No Pronouncable Acronym
doesn't support a system of function calls. After all, it is an
integral part of most programming languages. Therefore, I propose the
following statements:
DIAL:
The DIAL statement needs no qualification. When the statement is
encountered, the program initiates a phone call to another section of
a program. When a call is initiated, a new instance of the program is
created at this point with all registers set the same as the current
program, and all statements are ABSTAINED FROM until an ANSWER
statement is reached. (this means that COME FROMS are followed). Once
an ANSWER statement is reached, the programs each execute one
instruction alternately, starting with the phoning program, otherwise
continuing as normal (with the call still in existence). It is an
error if an ANSWER statement is not reached.
If a call is currently going on, this new phone call happens
simultaneously with the other one. It is an error for a single program
to try and talk over more than 4 phone calls at once, or for more than
25 calls to happen at the same time, regardless of how many any single
program is currently talking over.
When a call is made to an ANSWER statement that is currently running
as another program, another line is opened to that program. It is an
error to call a program that you are already talking to, or to call
yourself.
ANSWER:
The ANSWER statement needs no other qualification. It answers a phone
call. It is an error for an ANSWER statement to be encountered without
a call having made.
GOSSIP ABOUT:
The GOSSIP ABOUT statement must be followed by a register. It gossips
about the register given, allowing information to be heard by other
programs. The current register to gossip about is gossiped about until
either a SHUT UP statement is executed, or a random number from 10 to
100 instructions are executed, at which point the program becomes
bored and stops. If the program is already gossiping at the time, this
statement is ignored.
It is not an error to GOSSIP without a phone call.
SHUT UP:
The program stops gossiping if it is gossiping at the time.
GET GOODS:
This must be followed by a register. When it is encountered, the
program checks all programs that it is currently on the line with and
stores all data about the register in the program that most recently
started gossipping into this program. The registers must be of the
same type, or else it is an error. All data is copied, including
enrollment, slaves, masters, file handles, values, and overloading.
It is an error to GET GOODS while not talking to any other programs,
or while no connected program is talking.
HANG UP:
This statement hangs up from the most recently started phone
conversation. When hanging up, if the program still has open lines, or
if the program is the main program, it continues normally. If the last
line is hung up on, and program was created via a DIAL statement, then
the program may (50% chance), if it has GOSSIPED successfully
statement since the last time a call was made in or out, dial up
another program as if executing a DIAL statement. Otherwise, it
terminates (the other thread continues, though). It is an error to
GIVE UP on an open phone line, or to HANG UP when no line is open.
NOTES:
Program excitement level should be some crazy mathematical function
that ideally is 1 for 0, 0
Using a GET GOODS statement.
Having another program use GET GOODS on your GOSSIP
Errors (splat codes not given):
BUSY SIGNAL: You tried to phone a program that already had 4 open
lines.
I DON'T HAVE 5 EARS: You tried to dial out when you already have 4
conversations.
HONEY, I'M BUSY: You tried to GIVE UP with an open phone line.
I CAN'T FIND THE CRADLE: You tried to HANG UP with conversations.
THE NUMBER CANNOT BE CONNECTED AS DIALED: No ANSWER statement found
(this happens if the DIAL statement encounters either the dialing
program's ANSWER statement, the ANSWER statement of a program already
connected, or the DIAL statement itself)
I THINK I'M GOING DEAF: Attempted to GET GOODS with no one talking, or
no lines open.
ALL LINES BUSY: You attempted to dial with 25 lines already open.
I'M NOT INTERESTED IN THAT: You attempted to get a different type of
goods than those provided
ABSTAINING FROM ABSTAINING does in fact significantly change the
behavior of DIAL.
RATIONALE:
This interface is sufficiently unpredictable and difficult that all
but the most simple functions must be handled with care, and so I
believe that it is safe to allow it in without risking making easy
programs (like the NEXT statement did). Writing a safe function ending
is difficult enough as is, and so I'm not worried about using it
inappropriately. Still, it's up to you whether to change it, IGNORE
it, or STASH it for later.
;1 out.
coppro
Claudio Calvelli
> Don't worry, I'm not sane.
That's OK, I am. No, really.
As for the rest, I'm sure it can be implemented by having a multithreaded
program STEALing from itself and some clever programming. This, of course,
is not saying that there cannot be two ways of achieving the same results.
> DIAL:
If one extend slightly the syntax for gerunds, DIAL can be implemented
as:
PLEASE ABSTAIN FROM EVERYTHING EXCEPT COMING FROM + ANSWERING
WHILE REINSTATING THEM
With the added advantage that there is a less obvious connection between
the above statement and ANSWER.
> ANSWER:
> HANG UP:
No comments on this at the moment (pending further thought or whatever
passes for it inside my skull)
> GOSSIP ABOUT:
> GET GOODS:
This can probably be achieved with a suitable use of STEAL / SMUGGLE
and IGNORE, but there may be a case for a small coating of syntactic
saccharine to that. I would however point out that the definition of
"the same type" in CLC-INTERCAL is a bit hazy, as any value can be
overloaded to anything else.
> SHUT UP:
No I won't :-)
> This interface is sufficiently unpredictable and difficult that all
> but the most simple functions must be handled with care, and so I
> believe that it is safe to allow it in without risking making easy
> programs (like the NEXT statement did). Writing a safe function ending
> is difficult enough as is, and so I'm not worried about using it
> inappropriately. Still, it's up to you whether to change it, IGNORE
> it, or STASH it for later.
I'll STASH it for later, unless somebody volunteers to implement it.
(If that happen, PLEASE email me but REMEMBER to IGNORE the address
in the headers and use intercal whirlpool intercal spot dyn worm o
worm saur spot com)
> coppro
C