Sea (a compiled language)
fuzzyastrocat (767)

Hello everyone! This is my first post, so if it's boring I apologize :D

Just wanted to share a little compiled language I made called Sea. It's called Sea because, well, Sea shares many things in common with C. I chose C to mimic because this was my first compiled language — given that C is so low-level, I figured I wouldn't have to do too much work translating to x86.

A quick overview of the language

In case any of you want to try it out, here's a quick overview of the syntax/semantics.

To start, we'll take the simple "hello, world" program:

    import "stdlib.sea";
    int function main {
            println("Hello, world!");
            0;
    }

Here we immediately see a few differences between C and Sea:

  • Import is not a preprocessor routine, it's a keyword
  • Functions are defined as <type> function <name>
  • Functions automatically return their last expression — to suppress this, the last expression can be void;
  • Arguments in functions are declared differently — instead of putting arguments between parentheses, they are written as null declarations on the following line:
    int function my_function
            int my_arg_1;
            int my_arg_2;
    {
            // some code
     }

Control flow (if, else, while) is implemented as a "postfix operator":

    1 == 2
            :then {
                    println("Whoa, math broke"); // And no, this won't get printed :D
            }

A for-loop can be emulated with a block scope and a while:

    {int i = 0; i < 5
            :while {
                    printf("%d", i);
                    i++;
            }}

These control flow constructs can be extended — an excerpt taken from the stdlib:

    int::isZero {
        $int
            :else {
                $();
            }
    }

$int represents the int in question, and $() represents execution of the block given to the control statement. We could "call" this like so:

    0
         :isZero {
                 println("Hey math works again!");
         }

Sea has support for ints, chars, pointers, strings (char*), and moderate support for floats. If you want to see more about the language, peruse stdlib.sea and the tests (and oldtests, though some of those are outdated) folders in the repl.

EDIT: stdlib.sea uses what might be a confusing doc notation, so let me explain that here.

Comments

Sea comments behave just like C comments:

    // This
    /* will
        not
        be
    */ // Evaluated

However, there is a doc notation (used by SeaLib to generate simple HTML docs for a file). It is the following:

    [[[header]]]
    The header must be the first line of the file (outside of line or block comments).  It gives  a description of the file to follow. // This line is the file info

    [[your_function]] // Descriptor doc — gives info about a function
    A cool function I just wrote for demo purposes

    void function your_function {
            println("Hello, world!");
    }

    // Add more functions with their descriptor docs

SeaLib translates that to the following:

And yes, that file would actually run (aside from saying "entry point main is not defined"). Doc headers are ignored (along with the line after) just like normal comments.

Future

"That's neat — but why are you posting it here right now?"

Unfortunately, I'm going to abandon Sea (in favor of a newer language, Curta). Why? Two things:

  • As the language became more complex, I noticed a few things I had done not-quite-nicely in the compiler were becoming difficult to manage. I was faced with either using bad tools or buying (re-coding) new tools.
  • I was actually wrong about translating from a C-like language to x86 being easy. While the actual conversions themselves are not difficult, finding the proper x86 commands can be very difficult! For instance, there is no power function for the SSE floating point system — and all the tools I needed to make a power function were either nonexistent or difficult to implement.

So Sea will probably remain in its current state [for the rest of time].

In the aforementioned newer language (Curta), I am learning from my mistakes — it will compile to C++, with the added benefit that it will work on some embedded systems (most notably the Arduino). Stay tuned!

EDIT: Curta is now here: https://repl.it/talk/challenge/Curta-Lets-make-hard-things-easy/51820

You are viewing a single comment. View All
MocaCDeveloper (320)

This is incredible!
How do you make it a compiled programming language? Is it compiled due to the assembly or..?
I am very _interested in finding out how to make a homemade programming language compiled!!

DynamicSquid (3610)

@targetfanttthat same. interpreted languages are pretty easy to understand, but I never understood compiled ones

fuzzyastrocat (767)

@targetfanttthat Epic! We need more compiled languages!
So, an interpreted language is run by the language it's written in. If I wrote an interpreted language in Python, the Python would execute the code.
A compiled language translates the code of your language into a lower-level language like x86 assembly or C. The compiler doesn't run the code — instead, it just translates from one language to another.

Since you said you're interesting in making a compiled language, I'd suggest starting here: https://norasandler.com/2017/11/29/Write-a-Compiler.html
It requires basic programming knowledge, but other than that it builds from the ground up!

MocaCDeveloper (320)

@DynamicSquid I think the assembly code is what makes it compiled, but still I want to know just how he did it!

fuzzyastrocat (767)

@targetfanttthat Don't associate assembly with compiled — some languages can compile to other languages like C or C++ (or even Java)! However, the reason you make a compiled language is usually for performance, and x86 has very high performance.

MocaCDeveloper (320)

@fuzzyastrocat Alright thank you!! Also good job on this language you did very well! Keep it up!

fuzzyastrocat (767)

@targetfanttthat Thanks! It took quite a bit of work since there aren't a whole lot of resources about compilers (or at least, resources that I could find).

MocaCDeveloper (320)

@fuzzyastrocat That is where I have gotten stumped at. I have tried and tried to find documentation on how to make my programming language a compiled one but I just give up cause no documentation was very open, or reliable I guess you could say.
Thank you for that link though I am going to have a very fun night tonight, lol

fuzzyastrocat (767)

@DynamicSquid @targetfanttthat Yeah, interpreted languages have more documentation since they're generally easier. I hope that link helps — it was one of the few comprehensive resources I could find. It was my starting place, and look what I made :D

Lethdev2019 (182)

you can get CPython to compile the languages into bytecode using py_compile which converts it to .pyc. @DynamicSquid

MocaCDeveloper (320)

@Lethdev2019 But still, usually you don't want another programming languages' compiler compiling the language you created yourself. There is no creativity in that.
You're talking about using Python to create a programming language, right?

Lethdev2019 (182)

true but python is quicker than you think (especially if you create an optimised lexer). @targetfanttthat

MocaCDeveloper (320)

@Lethdev2019 Well yes because Python supports some higher level libraries(like PLY) to help people out. But still in this case you are at a full disadvantage because you have no control on many things, such like you have no control on how you pick up keywords or punctuation in the lexer, you depend fully on a Python library.
Yes, I agree, Python is quicker and more optimizable, but in the end you really have control over one section of your language: The Syntax

Lethdev2019 (182)

wrong. I am working with aguy on slice and we built our own lexer on SLICE and we were able to control how it picked it up from a file and it is 0 dependency. @targetfanttthat

MocaCDeveloper (320)

@Lethdev2019 Oh. I thought when you said "python is quicker" and said "an optimized lexer" that you were hinting to using Python libraries. Optimizing something means it makes the better use of which is why I thought you were referencing to using Python libraries

Lethdev2019 (182)

no, optimising it as in making it smaller and more efficient, libraries are not the way to go if you want to optimise. PLUS with your own code, it is easy to convert to an exe. @targetfanttthat

MocaCDeveloper (320)

@Lethdev2019 Well yes, making the better use of, being, making the situation better and easier in any way possible.
To Me, Python wouldn't be the best language to use due to the fact it is a High Level programming language, it is a Dynamically Typed programming language, it is Interpreted and it is garbage collected, all causing it to be slower in the end and less efficient all together for memory management, which is the key to any programming language

Lethdev2019 (182)

dude, python is made using C @targetfanttthat

MocaCDeveloper (320)

@Lethdev2019 Yes, but just because it was made in C does not mean that the language is going to be fast.

I am talking about why I think Python shouldn't be used to create a programming language. We all have our own opinions though!

I personally like the hands-on feeling of needing to allocate memory, work with low level stuff etc.
While you may not and you would rather just get straight into it without needing to worry about any of the stuff I need to worry about using C..

fuzzyastrocat (767)

@targetfanttthat @Lethdev2019 I see both sides of your argument. As for py_compile, that compiles Python code, not custom language code. Sure, you can translate a custom language to Python, but as @targetfanttthat pointed out the only thing that changes is the "looks" of the language, not the functionality. And if you really do create a true translation of a different language into Python, you're basically just compiling to Python — so why not compile to a lower-level (and faster) language like C?

As for optimization: Yes, python is a very optimizable language. But no matter how much you optimize it, it will still be an interpreted language — and interpreted languages are naturally slower. This is why Python is considered a slow language. I'm not saying Python is bad here: it has very good uses because of how high-level it is. But that same high-level-ness is what makes it slow, so for this particular instance it's not a good choice for a language in which you want performance.
However, if you don't care about performance, then making a language in Python is totally fine. I made my first language in Python, because I knew that Python would be easy to work with. However, that language was painstakingly slow compared to even Python, which is why I've moved on to making compiled languages (which compile to a fast, low-level language).

As for language builder libraries: This is a hotly debated subject. Some people say that these libraries are the best tools to use — others say they are terrible. In my opinion, there is no right answer here. If you just want to get it done fast (or easy), or if you're new to language building, you should use a language builder library. However, if you want full control over the lexing/parsing/etc process (like I did) or if you just want to make it yourself for the fun of it (also like I did), then you should build it from the ground up with no libraries. Neither way is wrong, just a matter of preference.

Pardon the wall of text — didn't realize how long this was until I typed it all out :P