Designing my own Programming Language

[xvedejas]

So I've just about decided how my programming language will work. It's inspired by smalltalk, ocaml, and haskell though I promise it's quite unique. So here's an explanation of the planned syntax.

1. Everything is a block. Blocks may be defined in this way:

Code: Select all

BlockName
{
    ...blockdefinition...
}

2. New blocks may be obtained by copying existing blocks. A colon represents copying a block.

Code: Select all

n: 5.            // n is a copy of "5"
myList: List.    // myList is a copy of "List"

3. Blocks have two parts: a data section and a code section. The data section is always formatted like dataName: DataType, dataName: DataType. but can have any variable number of data fields.

Code: Select all

Multiply
{
    number1: Int, number2: Int.  // data section
    ^number1 * number2.          // code section ('^' means 'yield')
}

4. When blocks are called, the value of their data is set, and their code is ran. The previous code is called thusly:

Code: Select all

>> Multiply 4, 5.
20

5. Nested blocks! (And thus OOP). Unlike C functions you can access nested blocks from outside by specifying their parent. Nested blocks have direct access to their parent's data and other blocks (no "this" or "self" needed).

Code: Select all

Stack
{
    size: Int,
    items: List.
    Push
    {
        item.
        items append item.
    }
    Pop
    {
        .               // a single period indicates no data section for the block
        ^items removeAt (items length).
    }
}

>> Stack 10.        // sets the stack's "size", doesn't alter "items"
>> Stack Push 7.
>> Stack Push 22.
>> Stack Push 5.
>> Stack Pop
5
>> Stack items
[7; 22]

6. Blocks may be copied and then immediately redefined. (Inheritance)

Code: Select all

Cat: Animal
{
    ...redefine some old stuff...
    ...add some new stuff...
}

7. Type system giving the coder however much strictness they want.

Code: Select all

>> x: Int.
>> x = 5.
>> x = 6.
>> x = 'a'.
ERROR: 'x' is type 'Int', not type ''a''
>> y: Object.                              // note: this is the same as just saying 'y.' but more verbose.
>> y = 7.
>> y = "A string!".
>> z: 42.
>> z = 21.
ERROR: 'z' is type '42', not type '21'
>> z = 42.
>> z = "fourty-two".
ERROR: 'z' is type '42', not type '"fourty-two"'

8. Pattern matching when calling blocks! Uses blocks without names to "split" the data section into different patterns to match. Sorta like the "match x with" of ocaml. Blocks are defined not only by their name but also by which given data parameters fit which block the best.

Code: Select all

Factorial
{
    { n: 0. ^1. }
    { n: Int. ^n * Factorial (n - 1). }
}

>> Factorial 5
120
>> Factorial "abc"
ERROR: 'n' is type '0' or type 'Int', not type '"abc"'

Example programs:

Code: Select all

// prints "Hello, world!" as many times as specified from the command line
HelloWorld
{ . PrintLine "Hello, world!". }

Main
{
    sysArgs: List.
    1 to (List at 1 toInt), HelloWorld.
}

Code: Select all

// gives us the GCD of two numbers a and b
GreatestCommonDivisor
{
    {a: 0, b: Int. ^b. }
    {a: Int, b: 0. ^a. }
    {
        a: Int, b: Int.
        (a > b) ifTrue
        { ^GreatestCommonDivisor (a - b) b. }
        else
        { ^GreatestCommonDivisor (b - a) a. }.
    }
}

I think one thing it is missing is a bit more syntactic sugar, but it's as good as smalltalk on that front anyways. Do I hear a "yeah" or a "nay" to changing to a python-style indentation? I like it, but I know a lot of people don't, so braces are okay.

[JackScott]

This looks like a really interesting language! Well done! A few comments:

• You're screwed either way regarding the Indentation vs. Blocking debate. The Curly-brace style you have isn't the true 'C' curly-brace style, so people who like curly-brace languages are unlikely to like yours. They'll also hate the indentation way of doing things. That said, I'd probably keep the style you have now. It's a lot easier to use indentation to make a free-form language behave than it is to make an indentation language free-form.
• You've described a lot of the structure of the language, but not a lot about the actual operations (the 'code' section). Do you mind giving a bit more information on the syntax of this section and how it all works?
• I like it a lot, but I'm still going to throw the hard one at you: why is this better than Smalltalk et al?
• What implementation do you have planned? Is it going to be compiled, or interpreted? It looks to me like something that would be interpreted, but I may be wrong.

[xvedejas]

Thanks JackScott!

You've described a lot of the structure of the language, but not a lot about the actual operations (the 'code' section). Do you mind giving a bit more information on the syntax of this section and how it all works?

Right. The "code" section is very similar to smalltalk; it contains "sentences" where you call blocks and pass parameters to blocks, as well as definitions of nested blocks. For example:

Code: Select all

Main
{   .
    file: File.                             // this is not part of our data definition! 'file' is not set when calling Main.
    file Open "/path/to/file".
    file Write "abc".
    file Close.
}

So it's basically imperative, and very similar to smalltalk. Of course, multiple calls can be combined with parenthesis and semicolons.

Code: Select all

/* parenthesis for order of operations */
-(factorial (y * 3)) / (sqrt x).
/* semicolons work as in smalltalk, send multiple parameters to a single block */
PrintLine "Line one"; "Line two".

I like it a lot, but I'm still going to throw the hard one at you: why is this better than Smalltalk et al?

Smalltalk is a great language, well designed, but there are a few issues. First, its virtualmachine implementation is horribly slow. This is to be expected from such a reflexive language. Secondly, it is purely object-oriented. I personally don't see this as an issue except for the fact that there are people who would rather code everything imperitively, and for smaller tasks that does produce simpler code. I guess the whole "block-oriented" idea was an attempt to allow imperitive, functional, and object-oriented programming while still keeping the elegant nature of smalltalk. That's the goal at least.

What implementation do you have planned? Is it going to be compiled, or interpreted? It looks to me like something that would be interpreted, but I may be wrong.

It's for my OS's interpreter. My OS will not have a userland, instead everything will be interpreted; this allows a lot more simplicity in kernel design. Yes, it will be an interpreter, but since it will live in the kernel, I bet it will be quite fast. Unlike smalltalk, all the basic datatypes (int, string, etc) will be predefined in C, like in cpython. Probably more than that too, so it will definitely be faster than smalltalk.

The interpreter will also double as the system shell, which is sorta cool; users and applications are on the exact same level. That's one reason for the whitespace, it makes a lot more sense to type the following at a shell:

Code: Select all

mv homedir, "/external/disk"

than this Java style:

Code: Select all

mv(homedir, "/external/disk");

[earlz]

OS - Valix | Kernel - L=M (Less is More)
All code is GPLv3 unless otherwise stated.

A bit off topic, but are you saying any post you make contain code is GPL'd lol. Thats a bit pointless don't ya think?

anyway.

I think that is a neat looking language. It seems very flexible. Could this be a compiled language or is there some part of the spec here that would prevent it or make it difficult?

[xvedejas]

I don't see it being difficult at all to write a compiler, just that's not the intent at all.

Thats a bit pointless don't ya think?

Eh, lots of code I write is "general knowledge" anyways so copyright doesn't count. I won't sue you

[iammisc]

Yes, it will be an interpreter, but since it will live in the kernel, I bet it will be quite fast.

I really don't see the logic here. If it's interpreted its going to be as slow as any other interpreter in terms of the running time. E.G. Executing one program might appear faster than if that program was executed under another os but that's only because in a full os other programs are running at the same time. If you implement multitasking your interpreter will be as slow as the next. Kernel space is not magic land where everything just goes fast.

As for the language itself: looks great and well thought out. I don't know too much about smalltalk but i am guessing that in your language types are prototype types where a "type" is just an object that is copied to make more of that "type" like in javascript. Is that right? Also, it would be nice if you would elaborate on the syntax of the code section.

Other than that I would suggest that you do not use python indentation and stick to curly brace style just for aesthetics. It seems the code would be hard to ride in a pythonesque style.

[xvedejas]

Kernel space is not magic land where everything just goes fast.

It sure is if you never switch to userland. The absense of the context switch should very well speed things up.

i am guessing that in your language types are prototype types where a "type" is just an object that is copied to make more of that "type" like in javascript. Is that right?

I've never used javascript but I think you have the idea. There are no "classes".

it would be nice if you would elaborate on the syntax of the code section.

I'm not sure what more needs to be explained. Everything works pretty much the same as smalltalk (just very slightly different syntax). I guess I should also point out optional naming of arguments:

Code: Select all

dictionary: Dictionary.
dictionary at 5, "five".
dictionary at 6, "six".
dictionary at key = 7, value = "seven".
dictionary at value = "eight", key = 8.
dictionary at 9, value = "nine".

I think (correct me if I am wrong) that this is pretty much how python does it.

[NickJohnson]

Yes, it will be an interpreter, but since it will live in the kernel, I bet it will be quite fast.

I really don't see the logic here. If it's interpreted its going to be as slow as any other interpreter in terms of the running time. E.G. Executing one program might appear faster than if that program was executed under another os but that's only because in a full os other programs are running at the same time. If you implement multitasking your interpreter will be as slow as the next. Kernel space is not magic land where everything just goes fast.

Yeah, you're really going to have major performance and flexibility problems if all your system can run is scripts. Having an in-kernel interpreter is not a bad idea, but you probably should have an interface for normal machine code programs. Think what would happen if you wanted to run another interpreter like Python on your system... running an interpreter written in an interpreted language would not be pretty.

Either way, nice job on the language design. I think it would be cool if you added a sort of "anonymous block" feature where a block is defined ad-hoc and put into a variable or argument, like a lambda or function pointer. Based on your code, if the type of such a thing was "Block", something like this:

Code: Select all

DoTenTimes
{
    block: Block.

    1 to 10, block.
}

HelloWorld
    {
    .

    PrintLine "Hello, World!".
}

Main
{
    .

    DoTenTimes HelloWorld.
}

Or this:

Code: Select all

DoTenTimes
{
    block: Block.

    1 to 10, block.
}

Main
{
    .

    DoTenTimes
    {
        .

        PrintLine "Hello, World!"
    }
}

[xvedejas]

if you wanted to run another interpreter like Python on your system...

Why would I?

That defeats the point of my system. The kernel is merely an abstraction of the hardware and the interpreter (shell) is merely a way of talking to the kernel.

NickJohnson, you are very right, the first example you gave already works. Sorry if I didn't make it clear enough. When you define a block, it's an undefined name followed by braces. If the name before the braces is already defined, it works as an "anonymous block" alright.

[NickJohnson]

if you wanted to run another interpreter like Python on your system...

Why would I?

That defeats the point of my system. The kernel is merely an abstraction of the hardware and the interpreter (shell) is merely a way of talking to the kernel.

Yes, but it severely limits what you can do. You can never program in another language under your system, or run anything computationally intensive quickly. At the very best you should be able to get your language to run at about 1/20 the speed of native code (judging by Python speed). Not to mention that it's significantly harder to write a good kernelmode interpreter than to just support machine code, and supporting machine code means you get your interpreter eventually anyway. You could also go halfway and have the whole userland run under a bytecode compiled virtual machine in the kernel, sort of like Inferno, and get the portability benefits along with more speed and potential other-language support.

Hard coding an interpreted language as the only way to run programs on a system is like forcing someone to wear a wet suit 24/7. Yeah, it's useful and convenient for some things, but you'll never be able to walk very fast or go out in public.

[xvedejas]

Right, well, the key word is simplicity. If it doesn't work out I'm sure later I'll be able to put in a faster virtual-machine sort of system.

[xvedejas]

If anyone would like to help me make this a reality... just ask

[xvedejas]

Yes, but it will be similar to the python introspection (you will be able to access a list of attributes and such). You'll be able to override methods of basic types and everything, of course, even though they will be built-in.

I don't know if I previously mentioned it but there will be an intermediate bytecode layer. Any syntax can be used so long as it correctly translates into the bytecode. So later, python-style syntax is entirely possible.

[earlz]

Yes, but it will be similar to the python introspection (you will be able to access a list of attributes and such). You'll be able to override methods of basic types and everything, of course, even though they will be built-in.

I don't know if I previously mentioned it but there will be an intermediate bytecode layer. Any syntax can be used so long as it correctly translates into the bytecode. So later, python-style syntax is entirely possible.

Aren't there already enough language bytecodes? There is Java, Android(the base language, before being translated to java) LLVM and countless more.. what would you gain from this bytecode layer? and why would anyone prefer to port a language to your bytecode as oppose to one of the many others out there?

[NickJohnson]

Yes, but it will be similar to the python introspection (you will be able to access a list of attributes and such). You'll be able to override methods of basic types and everything, of course, even though they will be built-in.

I don't know if I previously mentioned it but there will be an intermediate bytecode layer. Any syntax can be used so long as it correctly translates into the bytecode. So later, python-style syntax is entirely possible.

Aren't there already enough language bytecodes? There is Java, Android(the base language, before being translated to java) LLVM and countless more.. what would you gain from this bytecode layer? and why would anyone prefer to port a language to your bytecode as oppose to one of the many others out there?

I'm guessing the OP wants to have the VM correspond closely to his language so it's easy to compile. The standard implementations of most managed environments (Java, CLI) are quite complex, and LLVM is not managed. Those things would be tricky to implement on the kernel level, or would be already implemented, like that MOSA OS project released a couple of days ago. Plus it's an interesting experience to design and implement a VM.