Wednesday, November 17, 2010

Language Ideas Part 1

First, apologies for the long time between posts. It's been a stressful few months, but things will be getting better.

Now, before all the stress I began work designing a language to facilitate the creation of software in a very safe manner. I did this by trying to make the code as easy to read as possible, but to also prevent things that we know cause problems, such as shared global variables and lack of bounds checking. Unfortunately, two things happened: first, I lost all the work I did and second, I realized I don't have the time to really do it justice. So, I'm going to blog about it as I recall what I did and perhaps come up with more ideas that I believe are worthwhile.

The first aspect of the language, which I called SPL or Safe Programming Language, I want to discuss is the syntax of functions. What I did was I wrote out the same function in several different styles, looked at the pros and cons of each, and tried to make an informed decision about which was I thought was best. The same was done for the Zimbu language and I liked it a lot, hence why I followed suit. It worked out well as I could then see what the code would look like and I could try to catch poor decisions earlier in the process.

I ended up deciding that a functional programming style was best as it really promoted the creation of very small functions, which is a very good thing as the smaller a function is, the more understandable it is. However, I didn't like any of the current functional programming styles enough because they weren't quite as readable as I wanted it to be, so I came up with my own. Below is a sample as best as I can remember it:
function square(int, int) -> int
given x, y :
x * y
This is designed to be read as follows: The function square takes to arguments, and int and an int, and produces an int. For pattern matching, it reads as follows: given two arguments x and y, then do x * y. You can have multiple "given" clauses to handle different cases. Here's an expanded example using guards:
function abs(float) -> float
given x when x < 0:
x * -1
given x
In this case, the first pattern is read: given a value x, when it is less than 0, then return x * -1. Again, easy to read. Throughout everything I did, I tried to not be overly dependent on symbols, but also not pollute the language with unnecessary keywords. I did tend to use keywords over symbols as they are much easier to understand in many cases.

I didn't hit a lot of possibilities yet, but I was in the early stages of the design and was somewhat ADD as I kept jumping between different aspects of the language. However, I believe this to be pretty solid and definitely fits in with the easy to read aspect of the language.



Post a Comment

Links to this post:

Create a Link

<< Home