Your ideal syntax
Quote:Original post by Windryder
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.
That's why it would be awesome if someone would make a statically typed, properly compiled Ruby clone. Of course, that would require stripping some features, but I think the end would be worthwhile. C/C++'s speed fused with Ruby's syntax, that's my ideal language. (And maybe add Python-like indentation treatment, since that contributes to overall readability.) Now that there is LLVM, the bar to create full-blown optimizing compiler for your language is significantly lowered. (But it's still a pretty complex project)
Basically a mildly revised version of Tangent syntax I used before.
Standard C# comments
Basic literals (no octal/hex, no float specifiers, no sci-notation)
Standard C# identifiers (expanded to include more unicode categories)
Expanded symbol/operator list (again, including more unicode categories)
If/while/do-while/foreach as in C#
Method invocation via juxtiposition
Explicit returns required
and psuedo-bnf
Thus you end up with stuff like:
Standard C# comments
Basic literals (no octal/hex, no float specifiers, no sci-notation)
Standard C# identifiers (expanded to include more unicode categories)
Expanded symbol/operator list (again, including more unicode categories)
If/while/do-while/foreach as in C#
Method invocation via juxtiposition
Explicit returns required
and psuedo-bnf
expression ::= (identifier|symbol|literal)+ // and a few special things like lambdasparameter-definition ::= (expression:expression)|(comma-delim-var-list)base-class ::= expressionreturn-type ::= expressionclass-def ::= class-modifiers? class (identifier|symbol|parameter-definition)+ (: base-class)? class-def-blockmethod-def ::= method-modifiers? (identifier|symbol|parameter-definition)+ => return-type (block|;)
Thus you end up with stuff like:
public add(a:int, b:int) => int {...} // add(1,2);public (a:int) plus (b:int) => int {...} // 1 plus 2;public (a:int) + (b:int) => int {...} // 1+2;public shoot (target:Actor) with (weapon:Item) => void {...}
I would try to design a set of language semantics that can be transferred to different syntactic front-ends. That should help with putting syntax in the right place on the priority list. FWIW, typing discipline is not fundamentally a syntactic issue.
Thanks all for the excellent feedback. I heart Gamedev.
Multiple return values: I was strongly considering these so now I'll definitely add them.
I'm surprised the comment syntax got so much attention :) I'll most likely change that.
Here's some requested context information. The language's name is Circa (feel free to let me know if you hate the name).
The goal is a scripting / rapid prototyping language, along the same lines as Processing.
It is primarily executed by an interpreter, although in the future I'd like to add JIT or C++ cross-compilation.
It's statically typed with type inference. It does support dynamic typing (using a type called "any")
It does have some interesting features, one of the features I have in mind is that compiled code should be really easy to introspect and modify. Outside of the Lisps, not many languages have this as a priority. An example of what this could mean, is that you could have an IDE which allows you to visualize a piece of code as a dataflow diagram, and even make changes to the diagram, and then save those changes back to text format.
Another interesting feature is that it has really good support for live code reloading, which is pretty fun for prototyping stuff.
In a C-like language, if you had code like this:
it means that 'a' refers to some piece of memory, the first statement sets that memory to 1, and the second statement sets it to 2.
In a more functional language, you don't think of it like that. Instead you have an expression '1' which has the name 'a' attached to it. Then you have another expression '2' which also has the name 'a' attached. The name doesn't necessarily refer to a specific location in memory.
Yeah that is the case. The syntax is probably the least interesting of Circa's features; if I'm able to come up with a syntax that is relatively clean and readable and not hated by future generations, then I'll call that a success.
Multiple return values: I was strongly considering these so now I'll definitely add them.
I'm surprised the comment syntax got so much attention :) I'll most likely change that.
Here's some requested context information. The language's name is Circa (feel free to let me know if you hate the name).
The goal is a scripting / rapid prototyping language, along the same lines as Processing.
It is primarily executed by an interpreter, although in the future I'd like to add JIT or C++ cross-compilation.
It's statically typed with type inference. It does support dynamic typing (using a type called "any")
It does have some interesting features, one of the features I have in mind is that compiled code should be really easy to introspect and modify. Outside of the Lisps, not many languages have this as a priority. An example of what this could mean, is that you could have an IDE which allows you to visualize a piece of code as a dataflow diagram, and even make changes to the diagram, and then save those changes back to text format.
Another interesting feature is that it has really good support for live code reloading, which is pretty fun for prototyping stuff.
Quote:
It looks pretty standard, but could you elaborate on the notion of "named expressions"? How does a named expression behave/works?
In a C-like language, if you had code like this:
a = 1a = 2
it means that 'a' refers to some piece of memory, the first statement sets that memory to 1, and the second statement sets it to 2.
In a more functional language, you don't think of it like that. Instead you have an expression '1' which has the name 'a' attached to it. Then you have another expression '2' which also has the name 'a' attached. The name doesn't necessarily refer to a specific location in memory.
Quote: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.
Yeah that is the case. The syntax is probably the least interesting of Circa's features; if I'm able to come up with a syntax that is relatively clean and readable and not hated by future generations, then I'll call that a success.
Quote:Original post by Windryder
Perhaps you could show us some more? A function declaration? A class?
Sure here's a real program, it's a simple asteroids clone. Currently there's no classes or support for real OO, but do I want to add that.
That looks pretty cool. But I don't see any top-level game loop. How does that work?
On a less important note, I don't really like having to use the state keyword to instantiate a type. It seems like I should just be able to say Ship ship = [...] and be done. Is it required for all mutable state?
I think I would say to stick with one style for function definitions and such. Seeing Ruby-style, C-style, Python-style, and Haskell-style syntax elements all in one program would be very confusing. Leave open the possibility of one-liners, but other than that cut it down.
Anyway, I certainly don't think it will be hated by future generations, at least not for its syntax [wink].
If you haven't already, you might want to take a look at Go. It has some interesting features.
On a less important note, I don't really like having to use the state keyword to instantiate a type. It seems like I should just be able to say Ship ship = [...] and be done. Is it required for all mutable state?
I think I would say to stick with one style for function definitions and such. Seeing Ruby-style, C-style, Python-style, and Haskell-style syntax elements all in one program would be very confusing. Leave open the possibility of one-liners, but other than that cut it down.
Anyway, I certainly don't think it will be hated by future generations, at least not for its syntax [wink].
If you haven't already, you might want to take a look at Go. It has some interesting features.
Quote:Original post by theOcelot
That looks pretty cool. But I don't see any top-level game loop. How does that work?
It loops over the whole script for every frame, which I figure is OK default behavior for a rapid-prototyping language.
Quote:
On a less important note, I don't really like having to use the state keyword to instantiate a type. It seems like I should just be able to say Ship ship = [...] and be done. Is it required for all mutable state?
Yeah it's required; in practice I don't think this is too bad. The language encourages you to use pure functional expressions, so you don't need as much mutable state as you would with a C-like language. Also, "state" variables in Circa behave in slightly weird ways.
Quote:
I think I would say to stick with one style for function definitions and such. Seeing Ruby-style, C-style, Python-style, and Haskell-style syntax elements all in one program would be very confusing. Leave open the possibility of one-liners, but other than that cut it down.
Yeah, you are probably right about that.
Quote:
If you haven't already, you might want to take a look at Go. It has some interesting features.
I really like their emphasis on interface types; that feels like the right way to do OO.
Quote:Original post by DevFred
The syntax should be easy to parse for automatic refactoring (and other) tools.
I my opinion absolutlly not!!! You should provide the source code for the scanner and the parser for people to use in tools. I don't care if the syntax is hard for the computer to understand if humans find it very naturral. Take for example an idea i have:
The if statement looks something like: "if( expression) instruction" where `instruction` can be a block of instructions: "{ instruction ... }. Using {} is good but say you don't want to use them. The same language takes a valid syntax the following:
"if( exp) instruction... instruction endif". This grammar is context dependant grammar and a pain in the ass to parse. There is a small trick i'm thinking of for using an ll(1) parser to parse this particular case of `if` statement.
The language should be strongly typed and with c++ like templates ( even more powerfull with `static if` something like D programming language) :
example:
struct foo{ int a,c,b;}template <attribute A,operator OP,class T> // or template <attribute T::A,class T>bool compare(T & left , T & right){ return OP(left.A,right.A); }// you could spawn any compare function for a struct ; ex: compare<foo::a,int::operator <=,foo>
I would add type inference with a nice construct: ex: int a; typeof(a) b;
and `auto` types: "auto a=..." or "a <- ..." where the types of a is deduced by the value assigned.
Comments sould not be started with `--`(instead use the classic // and /*) because you might want to use that as an operator: int a = 10; a--;
The syntax has to be very very simple wo write! I find pressing Shift(lots of times) on my keyboard very frustrating when writing in c++ something like: foo<int>::method(my_instance,1 + 2 + 3,"adfgh");;
Address the issue of string:
For the sake of this world please use ' or ` not " (because you don't have to press shift)
when starting them.
When you have something like:
message = 'Error : line:' + i + ' row:' + j + ' message';
create a system that allocates the memory space neccesarry to fit that in only one go.Take c++ like strings, for example, every time you call + operator more space is created , the stuff is put inside that and then the old space is releassed (i find this verry stpid and slow).
Paralelism is the future so you need so have it. I would dump the classic oop and thrade that for a new concept that can parallelized more easley. Do a google search on OpenCl.
In my opinion the only synchronization mechanisms you would ever need are semaphores and barriers ( No mutex , no Critical_Section, no Events)
This is all the stuff i can think of right now;
Hope it helped.
Raxvan.
Quote:For the sake of this world please use ' or ` not " (because you don't have to press shift)
when starting them.
that only applies to american QWERTY keyboards :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement