Your ideal syntax

Started by
25 comments, last by M2tM 14 years, 1 month ago
So I'm making a programming language and I'd like it to have a really nice and readable syntax. But I can't decide on some things. First off, what do you think would be an ideal syntax for a language that is primarily used for coding games? Second, take a look at what I have and tell me if you think it sucks.

-- Comments start with two dashes

-- Function calls look like this
function(arg0, arg1)

-- Instead of declaring variables, you attach names to expressions
a = function(arg0, arg1)

-- There's infix operators
a = 1 - 2

-- Blocks start with keywords and end with 'end' (like Ruby)
if something
  do(something)
end

-- But I can't decide if blocks should have significant indentation like Python. What do you think?
if something:
  do(something)

-- Or possibly curly brackets
if something {
  do(something)
}

-- This is a function definition.
-- The language is statically typed, so each argument has a type name.
def my_func(int a, int b)
  do(something)
end

-- This is a function that returns something, the return type is declared with ->
def my_func(int a, int b) -> int
  return a - b
end

-- But maybe the 'return' should be optional, and the function should just return the last expression?
def my_func(int a, int b) -> int
  a - b
end

-- Also there are different possible ways to specify the return type
def my_func(int a, int b) { a - b }  -- implicit return type
def my_func(int a, int b) :: Int { return a - b } -- two colons like Haskell
int my_func(int a, int b) { return a - b }  -- return type name in front, C style

-- Here's a real function which draws a filled rectangle
-- The 'gl' part at the beginning of gl:triangles is a namespace
-- The square brackets indicate a list
def fill_rect(Rect rect, Color color)
    "Draw a filled rectangle."
    nw = [rect.x1 rect.y1]
    ne = [rect.x2 rect.y1]
    sw = [rect.x1 rect.y2]
    se = [rect.x2 rect.y2]
    gl:triangles([nw ne se se sw nw] color)
end

-- The -> operator is used to feed the input on the left to the function on the right.
-- It's there so that the writer can list the sequence of calls in left-to-right order
-- instead of right-to-left.
some_function() -> print
-- is the same as:
print(some_function())

-- The @ operator is shorthand that takes a name, and rebinds the overall result to
-- that name. It's there to make it easier to write a chain of expressions that
-- all operate on a certain name. Does this suck?
add(@a, 2)
-- is the same as:
a = add(a, 2)


This post is getting long so I'll stop there. TIA for feedback.
Advertisement
I'd have multiple assignment and multiple returns.
so you could have like:

a, b = 5, 6;

and

foo, bar, mumble = froboz();

It looks pretty standard, but could you elaborate on the notion of "named expressions"? How does a named expression behave/works?
Is the language typed?
Can you foresee a roadmap for the future?
What is the goal of this language? I understand it is for "coding games", but how would it win over competitors? Can you compare, at least in line of theory, what you're going to build with some alternatives?
Are you sure you want to use "--" for comments considering this could be operator-decrement?

For me, the ideal language for writing games is UnrealScript... States do rock, and replication leaves me in total awe. It's probably unnecessarly complicated for everything but highest-end games.

Previously "Krohm"

What's it called? YAPL? Yet Another Programming Language? xD

Personally I'm really not fond of the Basic style of if statements, I rather have brackets instead of 'end', since brackets can be aligned under each other (have the matching brackets on the same column). Didn't scroll down...
Further more, a semi-colon at the end of the line feels more natural. It gives a good marking for the end of the statement (and also allows multiple commands per line, not that you want that in most cases though). But it might be my C influences preferring this ^^
I like how you treat a function as a variable, since it is! It's merely a pointer to data in the code segment.

Beside that, will it be a programming language, or a scripting language? I mean, will you compile to machine code at compile time, will you compile to bytecode compile time and interpret bytecode at run time or will you interpret the code at run time entirely?

The syntax looks much like Lua btw, are you sure Lua will not fit your needs? Some big boys use it for their games too, so it's suited for that. Or is this more of a learning project?

Quote:Original post by jwezorek
I'd have multiple assignment and multiple returns.
so you could have like:

a, b = 5, 6;

and

foo, bar, mumble = froboz();


I like that. I always wondered why this was not possible in C, I think it can be done on the stack much like the input variables for functions (which is actually a tuple too). I do admit it is not very common in mathematics...

[Edited by - Decrius on February 16, 2010 2:48:22 AM]
[size="2"]SignatureShuffle: [size="2"]Random signature images on fora
I think one should always go new ways when designing a new language.
I'm working on my own programming language ATM and going through some of the same issues.

I think the new language designer should take extra care not just to extend existing languages. For instance. See how much a functional programming language is different from i.e. C++?

I think the language looks ok, but as mentioned theres a lot of lua/python in it.
But it's great learning experience (not to mention great fun) so you DONT have to invent anything truly groundbreaking :)

Feel free to PM me for my MSN as I'd love to talk about language design and implementation ;)

Also you should not call a byte code compiled language for a scripting language. Java and .NET are byte code compiled. (With JIT I know, but still)
Scripting languages are used to extend something, but it's still programming language that's being used. C# can be used for scripting too :)

And writing byte code or ASM is pretty close to each other depending on how you do it. If you can do one, you can (most likely) do the other.
First and foremost, I demand strong typing for making real games in a language. Python and Ruby are excellent for small, simple games, but the type system makes them much more prone to critical (runtime!) errors.

Another thing to consider is OO and encapsulation. While both Ruby and Python are OO languages in a sense, they lack many features that I consider critical. For example, Python's encapsulation is... Well, there really isn't any to speak of. Ruby allows for new methods and data to be added to a class from anywhere, rendering the encapsulation that actually exists useless against a determined "attack".

Furthermore, both of these languages are "duck typed", and, as the Ruby folks like to put it: "if it looks like a duck and quacks like a duck, it's probably a duck". This discourages the use of inheritance for flexibility and instead encourages its use as a means of code reuse. As a C++ programmer I consider this bad.

As for the actual syntax, I agree with Krohm on the use of the '--' operator as comment symbol. There are much better (and more widely used) comment symbols, and you get the extra benefit of not having your language mixed up with Lua all the time. ;)

I like the omission of the semicolon, which I quite honestly find rather pointless. Ending blocks with a keyword rather than a bracket is something I can deal with, though I really prefer the good old {} pair. :)

Perhaps you could show us some more? A function declaration? A class?

Also, will your language be compiled to native code or some intermediate bytecode?
I think any new programming language can't simply be a syntactic wrapper over the familiar constructs and methodologies supported by common languages. Even in combining language elements of different progenitors under a new umbrella language is not terribly compelling, unless the integration is unique or very elegant.

And certainly targeting a 'niche' market such as game programming, which does not actually have any hard distinction from other types of programming in the way that, say, critical/verifiable systems have, is a bit of a fools errand in practical terms.

There has to be some specific goal, preferably one which meets a need that is unfulfilled in current programming languages, in order to have any hope of being anything more than a toy language all of a dozen people might try out. In other words, try to do something that's more than superficially different -- try to do something novel.

Take Lua, for instance, which was probably the first scripting language which placed a high degree of importance on being embeddable -- that is, integrating nicely into another application.

Or take SPECS, which is explicitly a new syntax for C++, but it's specific goal is to make the syntax more consistent (from a human perspective) and also completely unambiguous (from the compiler's perspective) -- which largely go hand-in-hand, but which attempts to address very significant issues with C++ from a usability, maintainability and evolutionary standpoint.

Or take Epoch, created by a member of this forum whose identity escapes me this moment, but is meant to unify heterogeneous (meaning non-similar) computing resources under a single language and run-time system. The ideal of this language is to write one piece of code which can run on the CPU, GPU, a DSP, or any other type of execution resource -- possibly even broken down and assigned to the most appropriate execution resource intelligently.

throw table_exception("(? ???)? ? ???");

One of the most tempting pitfalls of starting a new language project is getting caught up in designing the syntax. It is incredibly easy to focus on this, as it seems to be a legitimately significant question.

What I've learned over the course of building several languages, however, is that syntax is virtually irrelevant. Of all the things you need to consider when starting a new language, syntax is basically the bottom of the list.

Syntax is a means to an end, not a goal in itself (unless you truly have some novel idea for how the syntax should work, which it appears that you do not in this case). All of the other decisions you need to make will influence the syntactical design. You will need to mold the syntax itself to suit the features and capabilities of the language.

Placing syntax first is, again, very tempting, and easy to get caught up with. But sticking too closely to a rigid syntax design will damage your ability to include other language features cleanly. For instance, by choosing "--" as your comment delimiter, you have completely eliminated the possibility of including the post-/pre-decrement operators (a-- and --a, respectively).


There is a great series of questions that you should be able to answer about your language. Some of them you can safely postpone until later, but none of them can be totally ignored. I would recommend getting to a point where you can answer the majority of those questions before you get too deep into coming up with syntax ideas.

Last but not least: remember that for every syntactic decision you make that is different from existing languages, you will introduce a point of confusion for newcomers. Everything that is unique will actually make your syntax less readable and intuitive, because by definition, what your syntax does is different from what the reader will expect from past experience. Achieving readability is much harder than it sounds.


In any case, best of luck with your project, and enjoy it - it's a very rewarding ride [smile]

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

That list only needs one question: Do you want to bore yourself to death or have fun writing the language? :)

Seriously. It's a great list, but just designing the syntax can also have it's merits :)

The language should be your own dream language IMHO. And if the idea is good, others might follow. If not. Well. At least you have your own dream language :)

But: It's important thinking about types, functions, program flow and collections before or during the design of the syntax.
It's not nearly that bad [wink] I've been through that list several times and I'm still having a hell of a lot of fun on my own project, so it isn't impossible to both analyze heavily and still enjoy the task.

Quote:Seriously. It's a great list, but just designing the syntax can also have it's merits :)


Easy enough to say, but I'm not convinced... what merits do you see, specifically?


Quote:The language should be your own dream language IMHO. And if the idea is good, others might follow. If not. Well. At least you have your own dream language :)


Creating a "dream language" is far more involved than just making a pretty syntax. If you aren't careful, you'll end up with a nice syntax for 5% of the features, and a hideous mass for everything else. It's critical to think of what the syntax "means" under the surface, and how the internals of the language come together. Sometimes moving a single character around can spell the difference between a nice, simple parser, and a horribly complicated bog of nastiness (like C++).


In any case, I don't think that this is really that sort of situation. The OP posted asking for input on the syntax - which indicates to me that the OP doesn't already have a clearly defined "dream syntax" to be working towards.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

This topic is closed to new replies.

Advertisement