Gulp Introduction

From Computer Tyme Support Wiki

Latest revision as of 02:31, 20 November 2005

• GULP - Main GULP Index

A little History

My first programming language was binary - leterally! In 1979 I had an IMSAI computer with 8k of ram and only EPROMS for storage. I started programming it from the front panel switches one byte at a time. Eventually I wrote an operating system. Got a keyboard and screen working - then tape - and eventually disk. Managed to convert two languages to run on it. Had a 5k Basic and a Forth compiler. Then I learned Pascal.

Forth was elegant in the way it ran but sucked in the way it read. The inventor of Forth - Chuck Moore - wrote a ver kool little Basic like compiler in Forth that was extremely impressive and later becames the basis for my MarxMenu compiler. Marxmenu is long gone as DOS has faded - but there doesn't exist any languages today that is anywhere near as elegant as MarxMenu is to program in. Today's programmers just don't get it - so I'm posting this in hopes to get something going.

Languages Done Right

Cumputer exist to serve humans and they get faster but not necessarilly easier to use. My idea of a good programming language is one that is intuitive so that the programmer/user can script something together quickly and get code running. Readability is the most important aspect of this language. Nothing else really matters. If it's too slow - get a faster computer. As long as it runs reasonably fast - that's good enough.

Under the Hood

This language has two parts to it. The run time part is similar to Forth. It's an RPN engine that uses a lot of stacks. The interpreter/compiler takes pretty source code and turns it into nasty Forth like RPN code that tokenizes small and runs reasonably fast. As an interpreter the system interprets the text stream and runs it. As a compiler the text stream is turned into a file of tokens that represents the RPN like execution sequences. Either way should be easy to code because the interpreter builds the tokens in memory. The compiler just saves the tokens to disk and eliminates the initial preprocessing of the text.

Forth Type Runtime Engine

Here's a quick tutorial of Forth like RPN runtime concepts. All information is passed on a stack. Routines get their data from the stack and return their results on the stack. In this case the stack contains variables and can hold any kind of data. Constants and Variables read push data into the stack.

For example - let's defins some words and operators. Binary operators like + - * / pop two data items - operates on them - and returns the results. Let's say we have a word "write" that pops an item off the stack and prints it. So let's look at the following sequence:

4 5 + write

The word 4 pushes 4 on the stack. 5 pushes 5 on the stack. + takes the top two items - 4 and 5 - adds them - and pushes the result - 9 - onto the stack. Write removes the top item and displays it.

A more complex example would be:

6 5 2 + * write

The result would be 42. Follow the logic yourself and you will see how it works.

Another example using strings:

"abc" "xyz" + write

The result - "abcxyz"

Looks ugly - but runs fast. It's basically left to right processing. And this is just fine for the runtime engine. But who want's to write code this way? Not me! But you must forst understand the runtime engine and then understand the interpreter to take a nice looking text stream that humans like and flip it around into something efficient that the computer likes.

Wouldn't it be nice if the code looked like this:

Write 4+5
Write 6*(5+2)
Write "abc" + "xyz"

That is exactly what we are going to do here.

Coding the GULP Language

So - what would you write a lnguage like this in? Annything and everything. Just about any existing language can be used to write this interpreter. I'll be interested to see what people do with it. You can use C, Pascal, Forth, Perl, Python, or whatever. And you might want to use this in your existing application in case users need to write script configuration files that your application interprets.