Re: GNU INTERCAL front-end for GCC?

["Sam Lauber" <sam124 at operamail dot com>]

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