dclang

TO INSTALL AND SETUP:

ABOUT:

dclang is an RPN, stack-based language with near-zero syntax. It is in the spirit and tradition of forth and the grand ol’ RPN calculator dc, which is oft-found on a UNIX/LINUX system near you! You can think of it as a dialect of forth, much in the same way scheme is a leaner dialect of lisp. Why dclang and not gforth? For the same reasons one would choose scheme instead of lisp! Smaller, easier to learn, in some ways, better in terms of usability and syntactical and naming improvements. I wanted to take what I like about forth, shave off what I didn’t like, and make a more user-friendly idealized version of forth – one that forth folks would recognize, but also would perhaps be friendlier to new users.

There are two constant goals of dclang:

1) to present hackers with a USABLE tool that they will enjoy! 2) to create a lean, performant tool that utterly smokes most interpreted languages.

I do not want to get stuck in exploring CS theory (although that is respectable and interesting) so much that I have a “Turing Tarpit Tool” that does nothing. dclang is slowly gathering features that means you can use it like you’d use python, bash, gforth, etc…and I have an eye to be guided by some of the key “daily use” functionality that is for instance offered by glibc in C. In fact, you might say that I’ll know dclang is really done when every (or almost every) aspect/feature of glibc is somehow reflected in the in-built capabilities of dclang.

RPN means “Reverse Polish Notation”. That means everything uses a ‘point-free-form’, and there are no parenthesis, since there is a completely level order of operation. Words operate on stack operands immediately, and leave the result on the stack immediately. This makes the interpreter/parser not only simple but faster than one that has to do computational gymnastics around parsing things like braces or parenthesis, etc. It also saves memory, since you don’t have runaway linked-list creation that you have to later garbage-collect. All actions happen on the stack. Like forth, this is not and never will be a garbage collected language, but there will be operations to create variables and other data structures like lists and hashes (dictionaries) and so on, but they will be manually destroyed in memory to make room for other structures with other keywords (‘free’). No garbage collection means things are kept simple, and the programmer is assumed to be a thoughtful and responsible adult. :) forth is a great language, and I mean to follow that lead, even as I simplify certain aspects of the forth standard in this dialect.

The trade-off for that simplicity is that one has to get used to how order of operations work in this world (everything being immediate and w/o parenthesis). And also, one has to get used to manipulating the stack such that defined words make sensible, efficient use of the stack. It takes some getting used to. I direct the user to the internet or books to search for things relating to the fine art of programming forth, etc. Everything said there applies here.

Anyway, due to RPN, things will look like this, when you do math:

    4 5 + .
    9

    20 5 / .
    4

    0.523 sin .
    0.4994813555186418

    3 2.54 pow .
    16.28875859622752

    1 2 3 5 + 7 16 / .s
    <4> 1 2 8 0.4375

    # a function!
    : testif 1 if "true" else "false" endif print cr ;
    testif
    true

    # times/again -- basic, fastest loop type, starts at zero, ascends to cutoff parameter (minus one).
    : looptest 7 times i . again ;
    looptest
    0 1 2 3 4 5 6

    # for/next loop, a little slower than basic 'times/again', but gives step options.
    # Parameters are to/from/step.
    # Let's add the first 20 million integers!
    : for_test 0
        20000001 1 1 for
            i +
        next . cr ;
    for_test
    200000010000000

    # this is a comment
    "This is a string!" print
    This is a string!

    # create a variable and store a value at it:
    var mynum
    4.321 3 / mynum !
    mynum @ .
    1.3773333333333333

    # low-level approach to do the same -- store a value at slot 11:
    1.15123 11 !
    0 @ .
    1.15123

Notice the ‘.’ character, which pops/prints the top-of-stack (TOS). This comes from forth, as does ‘.s’, which non-destructively shows the stack contents. This is different from ‘dc’, where ‘p’ pops/prints the TOS.

In the looping examples, the block has access to up to 3 hidden variables, ‘i’, ‘j’, and ‘k’ which you can use to test conditionally and escape the loop. This allows nested loops up to three counters deep. Going any futher is a code-smell anyway, and you should refactor to a different implementation if you need something more.

Implemented thus far:

A note on “composibility”

After wrestling a bit back-n-forth with the stack API for trees and lists, I opted for what what some might consider a non-standard approach to stack order for both. On the face of it, the approach for these structures is inconsistent with the other variable types, “normal array slots” and “hashes”. Consider:

var thing
5 thing !         # normal 'FORTHish setter': <value> <slot> <action>
  thing @         # normal 'FORTHish getter':         <slot> <action>

# and for hashes:

"bar" "foo" h!
      "foo" h@

So, why have I not preserved this “standard stack-order way” for trees and lists? Well for starters, I did. However, since these structures can sometimes be nested, and one can do neat things with nesting, keeping this strictly FORTH-like way can be a nuisance, and unwieldy. Take for instance, a nested list:

# make 3 lists
var outer_list
lmake outer_list !
var inner_list1
lmake inner_list1 !
var inner_list2
lmake inner_list2 !

# If we use a FORTH-ish stack order:
inner_list1 outer_list lpush
inner_list2 outer_list lpush
2 inner_list1 lpush
3 inner_list1 lpush
5 inner_list2 lpush
7 inner_list2 lpush
0 0 outer_list l@ l@     # 2
1 0 outer_list l@ l@     # 3
0 1 outer_list l@ l@     # 5
1 1 outer_list l@ l@     # 7

# If we use a "un FORTH-ish" composeable stack order:
outer_list inner_list1 lpush
outer_list inner_list2 lpush
inner_list1 2 lpush
inner_list1 3 lpush
inner_list2 5 lpush
inner_list2 7 lpush
outer_list 0 l@ 0 l@    # 2
outer_list 0 l@ 1 l@    # 3
outer_list 1 l@ 0 l@    # 5
outer_list 1 l@ 1 l@    # 7

Now, isn’t the 2nd way much nicer, and easier to parse? For starters, we preserve the “odometer” feeling of digging into a nested structure that most folks are used to. Also, notice how, related to that, the idea of “outer” and “inner” is actually preserved in a left-to-right reading. Finally, when you de-reference the outer_list with l@, you get the inner list, and can further deference that in a “chaining” fashion with yet another index and l@ operator. I find this much clearer, cleaner, and more intuitive.

Since trees can be nested in a similar way, I changed their stack-order expectations in a similar way. There may come a time where I consider doing this to normal variables and hashes – however, I’ve written so much code, and a chain of dereferences making for strange stack-order (i.e. nesting) is less common in those cases, and might be more upsetting the apple cart at this point. More thought and consideration of the matter is required at this point to convince me that changing that is worth it.

Contact

Aaron Krister Johnson

Please report bugs and successes to akjmicro@gmail.com

This site is open source. Improve this page.