I mean, this thing doesn't even know about FILES! The Standard Library
is just sort of assumed to be there, but it makes it very hard to add
functions.

So, how about an "EXCLUDE" statement? Usually INTERCAL includes all the
standard files, EXCLUDE would tell which labeled lines NOT to include, so
that they might be overridden by the INTERCAL program.

EXCLUDE {label-list}
{label-list} :: {label} | {label}+{label-list}

Anything else I shoulf think about adding?

: Instead of using two 2-spots, maybe you should use a whirlpool (@)...
: just an idea.

Actually, that was just the BNF for the notation... it'd look more like

EXCLUDE (1)+(1000)+(1030)

in real life.

EXCLUDE ^1@^1000@^1030

The sharkfin may refer to the label (it isn't used yet, is it?)
and the whirlpool may be the list concatenator.
Just an idea...

: Hmmm... it's way too obvious put it that way... let's obfuscate it a
: little more: something like this:

: EXCLUDE ^1@^1000@^1030

: The sharkfin may refer to the label (it isn't used yet, is it?)
: and the whirlpool may be the list concatenator.
: Just an idea...

The labels are used in the DO (label) NEXT and PLEASE ABSTAIN FROM (label)
statements. The "+" for list separators are used in DON'T STASH .1+.03+;2,
so I was just using the existing stuff. NOT THAT consistency should be a
real thing to go for, here!

But, I like the "whirlpool" 8-) I'll bet there's something we could use it
for!

# On the other hand, maybe it's best you NOT think of it that way.

Actually, the TriINTERCAL stuff was mine, though Eric has incorporated
it into the new manual.  It isn't really an addition to INTERCAL proper,
more a related language.  Uses ternary representation of numbers,
operators manipulate trits the same way INTERCAL operators manipulate
bits, and so on.  Introduces meanings for '@' and '^' as operators.

As for the EXCLUDE statement, you need a coherent, though obfuscated,
picture of how INTERCAL sees the file system in order to make it
meaningful.  Even then, EXCLUDING lines by number won't work for lines
that aren't numbered, like many in the standard library.  Also makes
the language diverge even more from the Princeton standard, which
interferes with the retrocomputing goal of Eric's compiler.

If you want something really useful :-) to do, how about implementing
some I/O tools using the character I/O that was recently added?  There
still isn't a floating point library, though it might be better to
skip floating point entirely and go directly to a more powerful system
like symmetric level-index arithmetic.  For that we need log and exp
functions.

  C. W. Clenshaw and F. W. J. Olver, "Level-index arithmetic operations",
  SIAM J. Numer. Anal. 24 (1987), pp. 470--485.

(I am going to be out of town for the next week, so followups in the
group will probably expire before I see them.  I'll see email replies
when I get back, of course.)

--
Louis Howell  (naz...@llnl.gov)

I have thought for some time that the world was far from ready for an
INTERCAL 9X effort, and in particular, the last thing INTERCAL needs is
high-level data structurng facilities. What came to mind was the Moebius
List.

A Moebius List is sort of like a circular array of integers. You can
push a number onto an existing list (it then becomes "current"); you can
extract the current number; and you can step the list forward one
position at a time. Of course, if you step forward more times than there
are items in the list, you see previous values all over again, but with
the bits exchanged left to right.

There is no operation to remove items from a list, but lists with even
lengths can be "scissored": this cuts them down the middle to form two
*interlinked* arrays and returns the left hand (most significant) one.
Because they are linked, the other one doesn't drop off, though; I think
it might be best if there was an operation that given a list returns a
list randomly chosen from among those linked through it (some kind of
exclusion control might be useful here, I'm not sure).

The biggest ommission from the Intercal standard is obviously the
ability to handle indirect addressing. I'd propose that the
whirlpool (@) symbol be used for address dereferencing and
pointer operations. Unlike C, which uses *p to indicate the
address pointed to by p, and &p to indicate the address of p, we
can economize by using only the one symbol. Position sensitivity
is the name of the game. For example, @.1 should mean the address
pointed to by .1 and .1@ should mean the address of .1 .

Note that Intercal pointers should operate on 7-bit word
boundaries, so a complicated mingle-and-twiddle operation is
required to convert from 16 or 32 bit addresses to 7-bit Intercal
addresses. Oh, and of course Intercal assumes a segmented address
space, so all the 8086 assembly hackers should be happy.

I'd also like to propose the addition of an augmented operator
namespace for Intercal. It's obvious that we're using up the
single character operators pretty fast. I'd like to propose a new
class of three-character operators. Lexical analysis relies on
the fact that the middle character is a "-", so the regular
expression defining the pattern space is:

        [;:@<>?#$%&(]-[][(){}<>]

Example operators include:

:-)     -- happy        -- always returns TRUE
:-(     -- sad          -- always returns FALSE
;-)     -- sly          -- always returns TRUE or FALSE, depending
                           on how polite the program is
:-]     -- hcf          -- if TRUE, halt and catch fire
:-[     -- dracula      -- deallocates a byte of memory from the
                           specified address (leaving a leak --
                           so bite me)
;-}     -- loopy        -- allocates two 7-bit words and returns
                           a pointer to the first nonzero bit in
                           the first word (no zero-on-demand clearing
                           necessary for Intercal gurus!)

This augmented address space will give us lots of room to
implement all those wonderful advanced features we envy in
languages such as C++, Ada, Snobol-4, and Perl. It should
keep us all happy with new features while we await with
bated breath the draft ANSI standard for Objective-Intercal.

-- Charlie

    'VINTERCALc#1'~'#0$#65535'