User:Nthern

From Esolang
Jump to navigation Jump to search

Real name: Nate Thern

email: nthern-at-gmail-dot-com

Narrative:

Another friend of esoteric languages. Actually, my main interest is writing interpreters for one language in another language. Esoteric languages often lend themselves well to that pursuit.

Another interest of mine is functional programming languages, of which there are several esoteric examples.

My favorite esoteric languages are FALSE, SMITH, SMITHb, unlambda and Lazy K.

I have started an EsoInterpreters page for cross-referencing Esolang interpreters that have been implemented in another (possible the same) Esolang.

--Nthern 16:50, 13 July 2007 (UTC)

Esolang Thoughts

I'm still working on getting a reasonably permanent web presence, so for now here are some of my esoteric projects and other thoughts. I am putting scripts and interpreters and other code in an archive page.

My primary esolang-related focus is creating interpreters of foo-in-bar, where foo and bar are both esolangs. If a language has at least stdin and stdout I/O, I prefer to create an interpreter that can read the program followed by the program input on stdin a la DBFI. I also like creating translators from foo to bar.

/// and itflabtijtslwi

Great Language! Really hard to loop in until you get the hang of it. I did some work a while ago on a Thue to /// translator. It appears I broke it or never quite got it working, but I will get back to it some day. done.

Plans for ///:

  • Translate my brainfuck-in-Thue interpreter.
  • Either modify the existing BCT-in-/// interpreter so it spits out 1s & 0s or write my own. done.
  • Write a native brainfuck-in-/// interpreter, or a DBFI notation brainfuck-in-itflabtijtslwi interpreter
  • ///-in-ORK would be cool.
  • The subset of /// with only the characters "/" and "\" should be TC. This would be easier to write an interpreter for in another esolang.

My /// stuff:

BCT

The BCT column in the EsoInterpreters spreadsheet should be at least as full as the brainfuck column, since BCT is so easy to implement.

There is a path to create a brainfuck-in-BCT interpreter (or do other useful things in BCT). Create a brainfuck-in-Turing machine interpreter and then translate it into Cyclic tag system via the path in this paper: "P-completeness of cellular automaton Rule 110". Then translate the Cyclic tag system interpreter into BCT. I plan to explore this possibility.

It probably won't be me, but I hope somebody can prove that Self BCT is TC. It would be fun to have a reason to implement SBCT-in-Foo.

Befunge(-93)

Befunge-93 is a Push-down automaton. I created a TC brainfuck-in-befunge-93 interpreter by extending the spec so the stack could hold unbounded integers.

Befunge(-93) interpreter in perl with bignums

Befunge(-93) interpreter in C with bignums

Plans for befunge-93:

  • BCT interpreter in pure Befunge-93, using the codespace to hold the BCT data string and commands. Although Befunge-93 is a PDA, the codespace can hold quite a few bits.
  • Explore making befunge-93 TC by adding the following to the reference interpreter:
    • Extend the codespace and implement relative addressing (for "put" and "get").
      • p & g are initially relative to 0,0. Command "c(oordinate)" pops x&y and makes p & g relative to that new coordinate.
    • Implement a roll-stack operator. This depends on the fact that the befunge-93 spec places no limit on the size of the stack.
      • Command "r(oll)" rolls the top of the stack to the bottom
    • Implement a second strictly-LIFO stack
      • Command "i(n)" pops the stack & pushes on stack 2. Command "o(ut)" pops stack 2 & pushes on stack 1
    • Implement a subroutine operator
      • Command "s(ubroutine)" stores the PC pos & dir (only if top of stack is true). Command "t" (reTurn) restores PC pos & dir & pushes a 0 on the stack. If not in a subroutine, "t" only pushes a 0.

Befunge(-98)

Plans:

Brainfuck

This perl program converts a natural number brainfuck program into an 8-bit brainfuck program. IOW, after conversion a BF program that expects to be able to grow the value of any cell to any natural number will run on an interpreter that limits cell size to 8 bits. The resultant program stores virtual cells as base-256 numbers and does not rely on wrap-around. Naturally, any program that only uses cell values of 0-255 (and does not wrap-around) will run unchanged after conversion - just much slower.

I keep mucking up file extension conventions for brainfuck and using the .bf extension. The standard practice (it seems) is to name brainfuck programs foo.b and befunge-93 programs foo.bf. I will try to get my files and pages standardised.

Bub

As I noted in Talk:Bub, Bub is a more powerful language than brainfuck. Therefore, interpreting Bub is more difficult than interpreting brainfuck (I think).

Some programs for Bub:

I belive I have all of these:

  • BF interpreter in bub (converted from DBFI)
  • BF interpreter in bub (native Bub)
  • BCT interpreter in bub (converted from BCT-in-BF)
  • BCT interpreter in bub (native Bub)
  • Bub interpreter in BF
  • Bub interpreter in Bub (converted from Bub interpreter in BF)
  • Bub interpreter in Bub (native Bub)

SMITH

My SMITH interpreter in perl. This contains a lot of improvements over the reference implementation.

A brainfuck interpreter in SMITH

SMITHb

My favorite esolang experience so far! Lots of classic esoteric characteristics here:

  • Simple spec, but no implementation
  • Unique and wierd paradigm
  • Limited and minimal operators
  • Useability and computational class highly suspect
  • Any written program is totally obfuscated

After reading the spec, it looked like there was a way to make this language break out of loops and make other decisions, but I wasn't sure it would work. I wrote an interpreter based on the spec, but let it languish for a while. When I came back to the language, it took some work, but I was eventually able to make some simple looping programs with decisions, calculations and a halting condition. At this point I realized that with my looping construct and halting condition I had all I needed to translate any brainfuck program into SMITHb. I had proved SMITHb is Turing Complete!

I will document the process on the SMITHb page, but for now here are some programs:

SMITHb interpreter in perl. In the process of experimenting with the language, I came up with a macro system. The macro system documentation and implementation are in the perl interpreter.

SMITHb interpreter in C. Uses gmp to handle bignums and a homegrown dynamic memory allocation to handle arbitrary stack size. Only processes raw SMITHb programs - no macros. Compile SMITHb programs with macros to raw SMITHb using the -c option to the perl interpreter. I made this when I realized that the perl interpreter was far too slow to handle some of the programs I had created.

Here is my brainfuck-to-SMITHb translator.

Here is a brainfuck interpreter in SMITHb created by converting DBFI to SMITHb.

Whirl

I have created a brainfuck-to-whirl translator.

Retrieved from "https://esolangs.org/w/index.php?title=User:Nthern&oldid=49677"