anything-to-INTERCAL translator???
Ross Presser
and Don Woods' ghost will probably COME FROM the future to strangle me
for proposing it -- but has anyone ever attempted to write a
translator that generates INTERCAL code from some other language? Even
a very simple one, perhaps, like Brainf*ck?
Claudio Calvelli
It would have to be done in a way no other translator would ever want to
imitate.
My compiler used to be able to generate INTERCAL as output. It could
be used as an INTERCAL obfuscator, and, by simply writing a parser for
some other language it could become a something-to-INTERCAL translator.
I removed the feature for some reason. Probably because porting it to
a recent version of CLC-INTERCAL would be a nightmare. However, now that
the core of CLC-INTERCAL is more or less stable this could be done.
Add a IACC program to parse, say, COBOL, and hey presto! a COBOL-to-INTERCAL
translator.
C
--
Real email address: intercal WHIRLPOOL freeshell SPOT org
It helps the spam filter if you include the word INTERLEAVING in the subject.
ais523
> On 2008-08-15, Ross Presser <rpre...@gmail.com> wrote:
> > I realize that it would be strictly against the spirit of INTERCAL --
> > and Don Woods' ghost will probably COME FROM the future to strangle me
> > for proposing it -- but has anyone ever attempted to write a
> > translator that generates INTERCAL code from some other language? Even
> > a very simple one, perhaps, like Brainf*ck?
>
> It would have to be done in a way no other translator would ever want to
> imitate.
>
Backtracking
INTERCAL compiler (no code yet, but the plans are in place), and on
inventing
a new language specifically to compile to INTERCAL. The second
language is
more interesting; I was planning to make a language that has all of
INTERCAL's
good points, plus additionally is usable, that compiles into INTERCAL
(or even
more ideally, happens to /be/ INTERCAL after the addition of a few
CREATE
statements, or possibly an expansion library). I added CREATE to C-
INTERCAL
partly for this reason (but with different semantics to CLC-INTERCAL
for what I
hope are obvious reasons).
For instance, INTERCAL would be a lot more usable and somewhat more
like
other languages with the addition of the following operators (^H means
backspace):
-^H| addition
- subtraction
x multiplication
-^H: division
but in both C-INTERCAL and CLC-INTERCAL, it's just a few CREATE
statements
and a simple implementation to add these operators to the language.
(Unfortunately,
they can't be used inside computed COME FROMs in C-INTERCAL to avoid
an
infinite regress, as in C-INTERCAL the code that implements them
necessarily
involves line numbers.) With a bit more difficulty, I think
traditional flow control
constructs could be added to the language too, but I admit I'm
somewhat partial
to the C-INTERCAL flow control construct set and may just leave it as
it is (with
practice, you can write an IF in two lines and a DO-WHILE in two
lines, for
instance, by using things like computed ABSTAIN and the AGAIN
modifier; computed
COME FROM is even more efficient command-wise for multiple-command
IFs).
As for the original topic, I think I saw a Brainfuck to INTERCAL
compiler once written
in English (i.e. it was a set of instructions that had to be followed
by a human, along
the same lines as IRP (see <http://esolangs.org/wiki/IRP> if you've
never heard of
IRP, it should appeal to the sort of people who like INTERCAL)), but
have been unable
to locate it again; it should be simple enough to reconstruct,
however. It's probably
also worth mentioning that I once tried to write a Brainfuck to C-
INTERCAL compiler
in which the resulting program used no assignment statements (see?
INTERCAL
/can/ be /entirely/ unlike any other language...), which I nearly
finished but is
both buggy and basically impossible to debug, so I gave up. (It stored
data on the
NEXT and choicepoint stacks of multiple threads, and the computed
ABSTAIN
status of various commands; the choicepoint stacks are unbounded, thus
can be
used to store unlimited amounts of data.)
Finally, anyone who's looked into the internals of CLC-INTERCAL
(probably only me
and Claudio) knows that there's a way to easily compile Perl into CLC-
INTERCAL by
relying on undocumented features of the compiler, but that's cheating
and really quite
against the spirit of using INTERCAL, so I won't elaborate on this
further. (I have a
hunch that it's possible to similarly compile arbitrary C into C-
INTERCAL by relying on
bugs in the compiler, but don't as yet know how to do this.)
--
ais523
C-INTERCAL maintainer
Claudio Calvelli
>
> Finally, anyone who's looked into the internals of CLC-INTERCAL (probably only me
> relying on undocumented features of the compiler, but that's cheating and really quite
> against the spirit of using INTERCAL, so I won't elaborate on this further.
Yes. It is part of the way the compiler works at present, and a small number
of sick's "options" work by using this feature. However it may be removed
without notice as I am forever planning to work on non-Perl backends for
CLC-INTERCAL.
> (I have a
> hunch that it's possible to similarly compile arbitrary C into C-INTERCAL by relying on
> bugs in the compiler, but don't as yet know how to do this.)
I confess I haven't looked into this, but I wouldn't be surprised. I'd
expect it would be more difficult than in CLC-INTERCAL.
Jim Kingdon
> points
INTERCAL has good points? Does that mean one of the language
designers messed up?
Claudio Calvelli
> INTERCAL has good points? Does that mean one of the language
> designers messed up?
The design goal is to make a language different from other languages.
In this sense INTERCAL has failed right from the start in some points.
However, all languages have bad points, so not having good points has
never been a design goal.
Ross Presser
<qwertyu...@asdfghjkl.zxcvbnm.not> wrote:
> On 2008-08-16, ais523 <ais...@bham.ac.uk> wrote:
>
>
>
> > Finally, anyone who's looked into the internals of CLC-INTERCAL (probably only me
> > and Claudio) knows that there's a way to easily compile Perl into CLC-INTERCAL by
> > relying on undocumented features of the compiler, but that's cheating and really quite
> > against the spirit of using INTERCAL, so I won't elaborate on this further.
>
> Yes. It is part of the way the compiler works at present, and a small number
> of sick's "options" work by using this feature. However it may be removed
> without notice as I am forever planning to work on non-Perl backends for
> CLC-INTERCAL.
>
> > (I have a
> > hunch that it's possible to similarly compile arbitrary C into C-INTERCAL by relying on
> > bugs in the compiler, but don't as yet know how to do this.)
>
> I confess I haven't looked into this, but I wouldn't be surprised. I'd
> expect it would be more difficult than in CLC-INTERCAL.
>
My original intent in asking this question was to see if there was any
way forward to the sometimes stated goal of unifying Don Woods's two
famous projects, INTERCAL and ADVENT. I was thinking that if someone
had implemented a braindf*ck -> INTERCAL compiler, then one could use
a brainf*ck backend to gcc or something to compile some existing
ADVENT source to brainf*ck, then compile that to INTERCAL.