Language Design Discussion

[Infinite Chalupas]

Since there are a few people on the site who are interested in writing compilers, why not open a discussion to share our ideas?



To get us started, one of the things I think is a bit disorganized about many programming languages is the use of different forms of brackets. There should be a standardization, like:

Code: Select all

( ) expression
[ ] array
{ } object
< > prototype

If you were to use [ ] instead of ( ) to execute functions like MyFunction[arg1], then you can treat the arguments as an array. Then you could do stuff like

Code: Select all

object[] myarray = ["%i, %i, %i\n", 1, 2, 3];
printf myarray;

Another thought I had is that attributes should be placed to the right of objects in some way instead of the left, like:

Code: Select all

int x = 0   public;

This way, the declaration of objects will be easier to spot because the first token on the line will be a type name; and thus it will be more legible to read and faster to compile.

Advertising

[codestation]

I am not interested in writting a compiler myself but i can comment in some things.

If you were to use [ ] instead of ( ) to execute functions like MyFunction[arg1], then you can treat the arguments as an array.

Interesting but personally i don't see the need to mix array brackets with function argument lists. For example Python can achieve the same thing without mixing the two:

Code: Select all

def foo(a, b, c):
    return a + b + c

# the function can be called normally
ret = foo(1, 2, 3)

# or unpacking a list, like this:
mylist = [1, 2, 3]
ret = foo(*mylist)

I would love this flexibility in a C-like language.

Another thought I had is that attributes should be placed to the right of objects in some way instead of the left

This doesn't make it harder to read since now the programmer has to look to both extremes of the line to get the complete type/attribute of a variable?

Advertising

[Infinite Chalupas]

Interesting but personally i don't see the need to mix array brackets with function argument lists. For example Python can achieve the same thing without mixing the two:

There's a bit of a difference there. Python is simply expanding an array into arguments, but in the example I stated before, the array itself the arguments. There are several ways you could take advantage of it:

Code: Select all

const int[] one = [1];

int negative[int value]
{
	return -value;
}


int main string args
{
	printf["%i\n", args[1 + negative one]];
}

This doesn't make it harder to read since now the programmer has to look to both extremes of the line to get the complete type/attribute of a variable?

The opposite actually. The idea is to get the attributes out of the way so you can shorten the amount of code on one line like:

Code: Select all

void DoStuff(string thisStuff)
	public static
{
}

[Acid_Snake]

Actually, what python does is treating argument list exactly like a tuple. This is how built-in python functions look like:

Code: Select all

Py_Object* someBuiltInFunction(Py_Object* self, Py_Tuple* args){
    some code to unpack the tuple
    whatever other code
}

as for this:

Another thought I had is that attributes should be placed to the right of objects in some way instead of the left, like:

Code: Select all

int x = 0   public;

what I do with my language is use () to declare private attributes and methods for both classes and modules, so it ends up looking like this:

Code: Select all

int (x)

the name of the variable being enclosed in () gives the programmer an overall feel of encapsulation, which is exactly what's happening, so the programmer receives much more info without reading that much, that way you avoid what I already talked about (private static final long int x = 0, f*ck that).
Attributes with no brackets aren't necessarily public, they are in fact properties, my language generates default setters and getters unless you override them.

Code: Select all

class XYLocation:
    int x
    int y

    void __init__(int x, int y):
        self.x = x
        self.y = y

    @setter x
    int setX(int x):
        return

    @setter y
    int setY(int y):
        return

in the above class, x and y appear to be public and accessible from the outside, but when trying to modify them, nothing happens, thus giving you encapsulation without looking like it.
Properties are very important as they allow you to change parts of the class without clients having to change their code.

[hgoel0974]

Speaking of design patterns, there is OOP and then there are things like Modular programming but I feel that Entity-Components is also probably a better way to do things (compared to OOP):

Code: Select all

register(console)
console.add(new outComponent("Hello World!"))
system.start()
unregister(console)

Oh and this article presents an interesting point of design patterns http://blog.codinghorror.com/are-design ... es-evolve/
and some more design pattern related stuff http://c2.com/cgi/wiki?AreDesignPattern ... geFeatures

[Infinite Chalupas]

what I do with my language is use () to declare private attributes and methods for both classes and modules, so it ends up looking like this:
CODE: SELECT ALL
int (x)

That's a fairly interesting idea. It kinda reminds me Lisp Another thing you could do is use Use the symbols # + and - to symbolize public, protected, and private respectively. There is a documentation program whose name escapes me that does this.

Just another cool thing to bring to the table, a lot of people don't know this but you can declare functions like this in C:

Code: Select all

int main(argc, argv)
	int argc;
	char *argv[];
{
	return 0;
}

Just for some extra reading, here are 2 articles I wrote a while back on code projects

• http://www.codeproject.com/Articles/613 ... ***-in-C
• http://www.codeproject.com/Tips/614570/Lambda-in-C-GCC

I'm a bit of a C enthusiast as you can probably tell I came up with a much better way to do classes, but I never got around to uploading the tutorial. My harddrive fried before I could upload it

[Acid_Snake]

there are many ways to do classes in C

[Infinite Chalupas]

So I just had an idea. Like Acid_Snake had stated before, one of the fallbacks of strict OOP programming how it's ridiculously messy and hackish to try to use native system functions. Well, one way this could be done cleanly is by creating a new type of interface this specifically intended for external code. For example:

Code: Select all

namespace System.IO
{
	extern interface ISTDFIO
	{
		static void *fopen(char *path, char *filemode);
		static void fclose(void *handle);
	}

	public class File: ISTDFIO
	{
		private void *handle;

		static pubic File Open(string path)
		{
			File file = new File();
			file.handle = File.fopen(string.text, "rb");
			if (!file.handle)
				throw new Exception("Failed to load file.\n");
			return file;
		}

		public void Close()
		{
			File.fclose(handle);
		}
	}
}

an external interface would work just like a normal one, except the functions don't need to be defined. It could also work both ways as a cleaner method of communication between functional and object oriented code. It's something I definitely wish Visual C++ had...

[hgoel0974]

C# uses that for the methods that need to access the actual system
Also, it just crossed my mind that while it is nice to have a specific design pattern in mind, it is better to design a language based on what you expect from it, I mean that there isn't just a single way to do something, and I think it would be better to explore new patterns rather than follow old standards. For example, I expect my language to be very very fast, I'm attempting hit the 'sweet spot' (X marks the spot)
[spoiler][/spoiler]
thus my main design goal is productivity and optimization and so I'd look for different patterns and constructs to do so.

[Infinite Chalupas]

C# uses that for the methods that need to access the actual system

I've never seen it done that way. I've only seen them using System.Runtime.InteropServices bracket attributes.

Also, it just crossed my mind that while it is nice to have a specific design pattern in mind, it is better to design a language based on what you expect from it, I mean that there isn't just a single way to do something, and I think it would be better to explore new patterns rather than follow old standards. For example, I expect my language to be very very fast, I'm attempting hit the 'sweet spot' (X marks the spot)
[spoiler][/spoiler]
thus my main design goal is productivity and optimization and so I'd look for different patterns and constructs to do so.

One thing you could do is make use of dynamic vector tables. Rather than calling functions directly, you could relocate them to a calling table and then execute them from that (internally of course, not through the actual language itself). Then you could take advantage of processor caching.