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?
On 2008-08-15, Ross Presser <rpres...@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.
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.
Claudio Calvelli wrote: > On 2008-08-15, Ross Presser <rpres...@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.
At home (unreleased and very unfinished), I'm working on a Prolog to 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.)
> 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.
C
-- Real email address: intercal WHIRLPOOL freeshell SPOT org It helps the spam filter if you include the word INTERLEAVING in the subject.
On 2008-08-19, Jim Kingdon <king...@panix.com> wrote:
> 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.
C -- Real email address: intercal WHIRLPOOL freeshell SPOT org It helps the spam filter if you include the word INTERLEAVING in the subject.
<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.
|
