view interps/clc-intercal/CLC-INTERCAL-Docs-1.-94.-2/doc/INTERNET/00README @ 9071:581584df6d82

<fizzie> revert 942e964c81c1
author HackBot
date Sun, 25 Sep 2016 20:17:31 +0000
parents 859f9b4339e6
children
line wrap: on
line source

The file "Usenet" contains the original proposal as posted on
alt.lang.intercal; some changes have been made to the proposal, as
described in this file. The documentation (under doc/html) has been
updated with all the changes.

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

MODIFICATIONS to the proposal.

1) Clarification about the representation of IP addresses.

   IP addresses are represented by converting the network byte order to the
   natural byte order of the computer running the program. In other words,
   an IP address of 127.0.0.1 corresponds to 2130706433, which of course
   should be entered by the programmer as #28672 ¢ #61441

2) IPv6.

   IPv6 is not yet supported, but plans are already in place for adding
   IPv6 support in CLC-INTERCAL 1.-94.-2.

   To represent IPv6 addresses, CLC-INTERCAL uses the address range normally
   reserved for multicast as follows. When a DNS lookup is performed, any
   IPv6 addresses (AAAA record) are stored in an internal register, and an
   address from the multicast range is returned to the user program. When this
   multicast address is used for STEALing the corresponding IPv6 address is
   retrieved and used instead. This allows to use 32-bit registers everywhere
   and still be able to look up 128-bit IPv6 addresses.

   A similar procedure applies to incoming IPv6 connections: the source address
   is stored in an internal register and mapped to the multicast range.

   The program will be able to store any IPv6 address in the translation
   register by using a DNS lookup. If register ,1 would produce the ASCII
   representation of an IPv6 address when READ OUT, a DNS lookup on that name
   will return the corresponding IPv6 address, which then gets automatically
   mapped to the multicast range as required.

   Note that there is a limit in the number of IPv6 addresses a program can
   access at any time.

   For inconsistency, a DNS lookup on a "dotted-quad" does not return the
   corresponding IPv4 address. The programmer must do the translation without
   cheating.

3) Theft server.

   The provisional port for the theft server is 64928, which can be changed
   by copying the file INTERCAL/Include/system.sickrc to $HOME/.sickrc, and
   editing the result.

   The protocol has changed since the Usenet article was posted. It is not
   yet documented but you don't need to access it directly unless you are
   porting the INTERNET to another INTERCAL compiler.

4) STEAL and SMUGGLE

   These accept a list of registers (separated, as usual, by intersections)
   rather than a single register. This allows to STEAL (or SMUGGLE) a list
   of registers from a single randomly selected process and/or computer.

   Note that there is no guarantee that the thefts are done in a particular
   order, and if one fails there is no rollback, so the theft may partly
   succeed and then splat. Same for smuggling of multiple registers.

5) CASE statement

   The final ESAC is optional. There is no real need for it.

6) Quantum statements

   Of course, one can say things like

   PLEASE STEAL .1 FROM #1234 ON #28672 ¢ #61441 WHILE NOT STEALING IT
   DO SMUGGLE .1 FROM #1234 ON #28672 ¢ #61441 WHILE NOT SMUGGLING IT

   with the obvious meaning. A Quantum CASE statement is also provided with
   a slightly unusual syntax:

   CASE (expression) WHILE NOT CASING IN (variable1) THEN (statement1)
   OR (variable2) THEN (statement2) ...

7) ABSTAIN and REINSTATE

   In addition to ABSTAIN FROM STEALING + SMUGGLING, one can also ABSTAIN FROM
   CASING and of course the corresponding REINSTATEs.

8) Overloaded registers

   STEALing or SMUGGLing an overloaded register can cause unexpected behaviour.