EXCLUDE Statement

15 views
Skip to first unread message

Brenda Holloway

unread,
Jul 1, 1993, 10:04:17 AM7/1/93
to
In preparation for implementing *my own* INTERCAL interpreter, I've been
thinking about ways to bring this language into the '90's... make it safe
and sane for a more urbane crowd.

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?

Brenda


Miguel Farah F.

unread,
Jul 1, 1993, 10:59:08 AM7/1/93
to
Brenda Holloway (bre...@netcom.com) wrote:
>
>EXCLUDE {label-list}
>{label-list} :: {label} | {label}+{label-list}

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


--
MIGUEL FARAH // "Trust me - I know what I'm doing."
mbf...@isluga.puc.cl // - Sledge Hammer
#include <disclaimer.h> //

Brenda Holloway

unread,
Jul 1, 1993, 12:09:17 PM7/1/93
to
Miguel Farah F. (mbf...@isluga.puc.cl) wrote:
: >EXCLUDE {label-list}
: >{label-list} :: {label} | {label}+{label-list}

: 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.

Brenda

Miguel Farah F.

unread,
Jul 1, 1993, 4:30:49 PM7/1/93
to

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...

Brenda Holloway

unread,
Jul 1, 1993, 6:07:12 PM7/1/93
to
Miguel Farah F. (mbf...@isluga.puc.cl) wrote:
: >Actually, that was just the BNF for the notation... it'd look more like

: >EXCLUDE (1)+(1000)+(1030)
: >in real life.

: 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!

Brenda

Jim Finnis

unread,
Jul 2, 1993, 5:37:03 AM7/2/93
to
In article <brendahC...@netcom.com>
bre...@netcom.com (Brenda Holloway) burbled:

>Actually, that was just the BNF for the notation... it'd look more like
>
>EXCLUDE (1)+(1000)+(1030)
>
>in real life.

Isn't that a bit limited? Perhaps it should be
EXCLUDE <expression>
where the interpreter excludes all the lines for which <expression>
is non-zero in the LSB at program start.

>
>Brenda
>


--
-----------------------------------------------------------------------------
Jim Finnis, | Unit 6A, Science Park, Aberystwyth, Dyfed, SY23 3AH
Clef Digital Systems |
cl...@aber.ac.uk | Tel.: 0970 626601 Overseas: +44 970 626601

Jonathan R. Ferro

unread,
Jul 2, 1993, 11:01:54 AM7/2/93
to
bre...@netcom.com (Brenda Holloway) writes:
> But, I like the "whirlpool" 8-) I'll bet there's something we could use it
> for!

In THE C-INTERCAL SUPPLEMENTAL REFERENCE MANUAL, Eric Raymond
(e...@snark.thyrsus.com) writes:
# In TriINTERCAL programs the '@' (whirlpool) symbol denotes the unary
# tritwise BUT operation. You can think of the whirlpool as drawing
# values preferentially towards the central value 1. Alternatively,
# you can think of it as drawing your soul and your sanity inexorably
# down...

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

-- Jon Ferro Einsprachigkeit ist heilbar

Louis H. Howell

unread,
Jul 2, 1993, 1:17:24 PM7/2/93
to

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)

"A few sums!" retorted Martens, with a trace of his old spirit. "A major
navigational change, like the one needed to break us away from the comet
and put us on an orbit to Earth, involves about a hundred thousand separate
calculations. Even the computer needs several minutes for the job."

Stephen P Spackman

unread,
Jul 2, 1993, 5:59:49 PM7/2/93
to
One thing you might consider, out of sheer bloody-mindedness, is to have
your EXCLUDE operation work by computing some hash code over the lines
to be excluded. I think this would add an extra level of intellectual
challenge to programming.

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 only problem I've found with this computational model, aside perhaps
from its excessive efficiency, is that the array end up narrower after
slitting up the middle, and when I tried to glue them back together to
make them full width again, I got this weird bottle....
----------------------------------------------------------------------
stephen p spackman +49 681 302 5288(o) 5282(sec) ste...@acm.org
dfki +1.24 / stuhlsatzenhausweg 3 / 66123 saarbruecken / germany
----------------------------------------------------------------------

charless

unread,
Jul 5, 1993, 9:33:48 AM7/5/93
to

In article <brendahC...@netcom.com> bre...@netcom.com (Brenda Holloway) writes:
>
>But, I like the "whirlpool" 8-) I'll bet there's something we could use it
>for!

It should be obvious, dammit. Intercal will never come into its
own until you can write an Intercal compiler in Intercal, and it
will never supplant C until you can write UNIX in it.

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!)
>-] -- guess -- uses Bayesian reasoning to guestimate
the next line to be executed, and jump
to that line (plus specified increment)

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


--
Charlie Stross ... char...@scol.sco.com ... cha...@antipope.demon.co.uk
UNIX oriented text mangler | This is a
"As soon as you pull out the pin, Mister | Kibo
Hand Grenade stops being your friend." | attractor: help stop newsgrepping!

Miguel Farah F.

unread,
Jul 8, 1993, 8:19:47 AM7/8/93
to
charless (char...@sco.COM) wrote:
>
>In article <brendahC...@netcom.com> bre...@netcom.com (Brenda Holloway) writes:
>>
>>But, I like the "whirlpool" 8-) I'll bet there's something we could use it
>>for!
>
>It should be obvious, dammit. Intercal will never come into its
>own until you can write an Intercal compiler in Intercal, and it
>will never supplant C until you can write UNIX in it.

Maybe GNU instead of UNIX? :-)


>
>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 .

I do not agree with that use for the whirlpool (it's been used for
this in a version of Pascal). I'd rather use (if they're still free)
the slat and backslat:
/.1 --> address pointed to by .1
\.1 --> address of .1

>
> [...]


>
>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.

What are you talking about? Instead of that it should be named

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

Reply all
Reply to author
Forward
0 new messages