> > I am thinking of including a front-end for INTERCAL for GCC. INTERCAL
> > is an estoric programming langauge that was created in 1972 with the
> > goal of having nothing in common with other langauges (see
> > http://catb.org/~esr/intercal). There is a C implementation of
> > INTERCAL (called C-INTERCAL) that is avalible there. I think it would
> > be a good project(1) as a front-end(2) to GCC.
>
> Show us your patch.
>
> Any ideas how GCC could implement the implicit COME FROM multitasking?
>
> Would a VM-based solution satisfy you? (No I'm not comparing Java to
> INTERCAL.) Otherwise I think you might have to introduce new (fork ...)
> RTL expressions. No, not fork(2); more line Linux clone(2).
I don't think that's needed. We could just put in the RTL
insns to call fork(2).
But since I am typing this up with DJGPP open (which
dosen't have fork(2)), I would sincerly like it if we could
implement Threaded INTERCAL some other way (pseudo-threads
which alternate control every few microseconds?).
> > (2) -> Some of us would like
>
> LOL. BTW has anyone ever else put "Programming skills: INTERCAL on
> their CV?" I've never had this queried, even when I've mentioned this
> hot skill in interviews (for jobs I was offered)?
>
> > DO .1 <- #0
>
> Not very polite, are you?
Funny.
> > to be translated into movl $0, v1
> How do you propose we (read: you :) write a testsuite that allows for
> the (language-mandated, IIRC) indeterminacy of the success of compiling
> the same program multiple times? (IIRC I'm thinking of E774 - is that
> the random sometimes-requirement for PLEASE? And how do you test for
> the sometimes-ness?)
E778 is the unexplained compiler bug. E774 is random compiler bug. The PLEASE
requirement is not random:
If fewer then 1/5 of the statements begin with PLEASE, the
program is insufficently polite. If more then 1/3, too
polite.
You mean `random compiler bug'. A quick look through
`lose.h' from C-INTERCAL found:
/* A compiler error has occured (see section 8.1). */
#define E774 "774 RANDOM COMPILER BUG\n\
ON THE WAY TO %d\n"
and under it
/* An unexplainible compiler error has occured (see J. Lyon or D. Woods). */
#define E778 "778 UNEXPLAINED COMPILER BUG\n\
ON THE WAY TO %d\n"
The random compiler bug test could be made by running the
compiler about 10 times, and executing each of the 10
executables until one of them random-compiler-bugs.
PLEASE test could be made by the following code:
DO .1 <- #0
DO .2 <- #0
DO .3 <- #0
(which is insufficently polite) and the too-polite test
could be made by changing the first two DOs to PLEASEs.
COME FROMs could be handled the same way they are done in
C-INTERCAL; set a bit in the tree structure. A comment in
the C-INTERCAL `ick.h' next to a member of a `tuple'
structure:
/* if NZ, a COME FROM touches this line */
Anyway, about the frontend, what does my frontend have to
do?
Samuel Lauber
P.S. Could an ICE make an E778? (Trapping the ICE is left
as an exercise to the reader :-)
--
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.
Powered by Outblaze
