SilverScript: New scripting language for game development

[Tenry]

Hi, I hope it's okay to post something like this here in the SFML forums. Once it's working, it could be useful for your game development So:

I'm currently working on a new scripting language named SilverScript. I'm going to use it in my SFML projects once the interpreter is fully working. Before anybode of you says, why a new scripting language? there are already bunches of them out there, let me depict you my main reason: getting experience. I wanted to learn to write a parser and interpreter, and what would be better than a new scripting language I can design for the best fit in my planned projects? So here it is, SilverScript! And I'd like to know what you think of it, unless you think it's useless.

I've written the SFML example code in SilverScript so that you get an idea what it looks like (as at July 2013):
# import external modules
use sfml as sf # make the sfml module available (as sf)


function main
  # note: new variables are declared with the @-character, which is similar
  # to the 'local' keyword in other languages
 
  # create the main window
  @window = new sf.renderWindow(new sf.videoMode(800, 600), "SFML window")
 
  # load a sprite to display
  @texture = new sf.texture()
  if not texture.loadFromFile("cute_image.jpg")
    return 1
  end
  @sprite = new sf.sprite(texture)
 
  # create a graphical text to display
  @font = new sf.font()
  if not font.loadFromFile("arial.ttf")
    return 1
  end
  @text = new sf.text("Hello SFML", font, 50)
 
  # load a music to play
  @music = new sf.music()
  if not music.openFromFile("nice_music.ogg")
    return 1
  end
 
  # play the music
  music.play()
 
  while window.isOpen()
    # process events
    @event = new sf.event()
    while window.pollEvent(event)
      # close window: exit
      if event.type == sf.event.closed
        window.close()
      end
    end
   
    # clear screen
    window.clear()
   
    # draw the sprite
    window.draw(sprite)
   
    # draw the string
    window.draw(text)
   
    # update the window
    window.display()
  end
 
  return 0
end # end of main function


SilverScript is actually not going to be designed to develop whole game engines (like in the example above) but rather for smaller tasks such as enemy behavior.

If you want to keep up to date, visit http://silverscript.org/, but downloads are not yet available.

[Nexus]

Cool! The syntax reminds me of Lua, but also a bit of Matlab. Why do function calls sometimes have parentheses and sometimes not? Do you already have plans on how to interfere with C++?

And have you implemented a garbage collector? I'm interested in how you manage resources and memory

[Tenry]

Cool! The syntax reminds me of Lua, but also a bit of Matlab. Why do function calls sometimes have parentheses and sometimes not? Do you already have plans on how to interfere with C++?

And have you implemented a garbage collector? I'm interested in how you manage resources and memory

Yeah, the syntax is very oriented to Lua, but there are still significantly differences in the language design and the inner workings behind.
I don't know what Matlab is like, but I might take a look at it, just to compare

Parentheses around function parameters are optionally. At least, if a function call (or definition/implementation) is not in an expression, i.e. you are not taking a function's return value for something.

function foobar
  # function body...
end

foobar # calls the function
foobar() # also calls the function
f = foobar # f now points to the function
f() # call to foobar()
f = foobar() # f has got the return value of the function call


An interface between SilverScript and C++ is mandatory, but I'm still thinking of what that API should look like.

At the moment SilverScript uses reference counting, although I've already read that this kind of garbace collection might not be the best.

[MorleyDev]

That strikes me as confusing. No more confusing as some of the things other languages to do with functions as 1st class objects, but confusing none-the-less.

[Tenry]

That strikes me as confusing. No more confusing as some of the things other languages to do with functions as 1st class objects, but confusing none-the-less.

New languages might always be confusing

As soon as the interpreter works well I will release the source code and detailed tutorials. Then SilverScript might be quite easy to understand, I hope.

[Nexus]

Parentheses around function parameters are optionally. At least, if a function call (or definition/implementation) is not in an expression, i.e. you are not taking a function's return value for something.

Do you see an advantage in making parentheses optional? Especially if you want to keep it simple, enforcing parentheses for function calls, and therefore avoiding the ambiguity, might be a better idea. At least, I find it quite unintuitive when an expression behaves completely different just because it is assigned to an object...

At the moment SilverScript uses reference counting, although I've already read that this kind of garbace collection might not be the best.

Yes, there are some issues, especially circular references. There are different approaches, complex GCs work in "generations" depending on the object lifetime. I wouldn't make it unnecessarily complex, unless you need a high-performance scripting language

[MorleyDev]

New languages might always be confusing

Just saying, it's a little ambiguous.

[Tenry]

Parentheses around function parameters are optionally. At least, if a function call (or definition/implementation) is not in an expression, i.e. you are not taking a function's return value for something.

Do you see an advantage in making parentheses optional? Especially if you want to keep it simple, enforcing parentheses for function calls, and therefore avoiding the ambiguity, might be a better idea. At least, I find it quite unintuitive when an expression behaves completely different just because it is assigned to an object...

I made the parentheses in general optionally, because I find it nicer to read or to understand in some cases, especially if the function doesn't have any parameters. Consider the following two examples:

update_screen # actually a function, should be clear because of the name

mytime = current_time
# current_time should give you the system's current time (e.g. as Integer),
# but it almost behaves like a usual variable.
# Unfortunately (current_time is a function) it's not clear whether mytime
# shall accept the return value of current_time() or point to the function,
# hence I made it mandatory in assignments.
# In simple statements (non-assignments) the return value is not retreived,
# so in such a case it can only be a function call (like the update_screen example above).

[panithadrum]

I think that function calling without parentheses is a bad idea.

[Mario]

Well, worked in Basic, too. But I agree, it could be misleading/harder to read and you don't gain anything making the parenthesis optional, so I'd just force them, especially when supporting some kind of pointers or references (to distinct between wanting the address or return value for example). Otherwise things like "x = functionname" will be misleading, especially for beginners, cause most would expect the return value to be assigned.

[Tenry]

I think that function calling without parentheses is a bad idea.

Well, worked in Basic, too. But I agree, it could be misleading/harder to read and you don't gain anything making the parenthesis optional, so I'd just force them, especially when supporting some kind of pointers or references (to distinct between wanting the address or return value for example). Otherwise things like "x = functionname" will be misleading, especially for beginners, cause most would expect the return value to be assigned.

As far as I know, parentheses in function calls in Ruby aren't needed, either, am I right?

Most of you are just too used to C style languages, where parentheses around function parameters are needed. Maybe I will get another idea for function calls, because... those parentheses are also used in simple expressions to group certain operations together...
There is one simple rule to remember my syntax: when not expecting some function return value by a function call, the parentheses are not needed. If you are unsure whether you should put parentheses or not, to call a function, you can always put them, especially, if you are used to C style languages.


There are some other language aspects, I would like to discuss more. In SilverScript, a Class is the same as an Object, Namespace or Structure. An object is just a copy of a class (function code internally keeps referenced) and could be used a sub class which could also be instanciated (so, copied). The usual way to implement a class is the following:

class foobar
  # attributes
  x = 0
  y = 0
 
  # methods
  function do_something
    # function code...
  end
end

instance = foobar.new()
instance.do_something()
...


I call this type of class implementation explicit implementation/conversion/casting. As types are dynamic in SilverScript, the following (for example for a vector structure) could also work:

# 'pos' is not set, it is nil

# by accessing any attribute of pos, it is automatically converted to an empty class
# I call this 'implicit implementation' or '- conversion' or '- casting'
pos.x = 0
pos.y = 0


In Lua you always have to "declare" a table like pos = {} before you can set any attributes.
The same rule applies for arrays: when accessing/setting an index with the []-operator, the variable is internally converted to an array, and any previous data (e.g. class attributes) is deleted.

[Nexus]

I made the parentheses in general optionally, because I find it nicer to read or to understand in some cases, especially if the function doesn't have any parameters

Exactly in these cases, I find it very misleading. This is also the case in Matlab, and I have been confused again and again because you can't syntactically differ between variables and function calls in the code. What makes things even worse in Matlab, is that the array index operator and function call operator look exactly the same.

There are two problems: 1. The simple addition of a "r = " in front of the expression changes the whole semantics, which is likely to introduce unexpected bugs, and 2. one doesn't recognize function calls (with possible side effects or expensive computations). You should really reflect if that's worth the slightly "nicer" syntax (which is subjective), at least if you plan to make your language available to other users.

Most of you are just too used to C style languages, where parentheses around function parameters are needed.

I have already programmed in Haskell, where everything is a function. Function calls require no parentheses. But contrary to SilverScript, this syntax is consistent inside Haskell.

Apart from that, most of your audience will be used to C style languages, that's why it's a good idea if you don't upset everything they are used to

The same rule applies for arrays: when accessing/setting an index with the []-operator, the variable is internally converted to an array, and any previous data (e.g. class attributes) is deleted.

The initialisation of members without initialisation of the object exists also in Matlab

I would however be careful with such seemingly nice features. Especially the array access: In most cases, accessing a structure as an array is a mistake and should be treated as one, and not silently lead to different program behavior (=bug). When one wants to overwrite an existing object, one could still make it explicit.

There are some other language aspects, I would like to discuss more. In SilverScript, a Class is the same as an Object, Namespace or Structure. An object is just a copy of a class (function code internally keeps referenced) and could be used a sub class which could also be instanciated (so, copied).

Do you somewhere differ between the 4 terms?

If an instance is just a copy of a class, can you change the original class? In your example, write foobar.x = 5?

[MorleyDev]

As far as I know, parentheses in function calls in Ruby aren't needed, either, am I right?

There are several ways to get a reference to a method in ruby but they are all very explicit. Here it looks to be based on the context. I'd argue being context-based is the opposite of nice syntax.

So if it was parenthesis are optional but if you have to explicitly declare you're getting a reference to a function somehow, this removing the context sensitivity, my complaint there would get withdrawn.

[Tenry]

There are some other language aspects, I would like to discuss more. In SilverScript, a Class is the same as an Object, Namespace or Structure. An object is just a copy of a class (function code internally keeps referenced) and could be used a sub class which could also be instanciated (so, copied).

Do you somewhere differ between the 4 terms?

If an instance is just a copy of a class, can you change the original class? In your example, write foobar.x = 5?

Consider the following:
class foo
  x = 5

  function func
    # ...
  end
end

bar = foo.new()
# bar.x = 5 (it was copied)
# bar.func = function ... (it is internally referenced, because of possible huge code size)

foo.x = 20
# bar.x is still 5

foo.func = function
  # ...
end
# bar.func is still the old one

bar.x = 1
# does not affect foo.x


I'll think about the function call syntax carefully, but at there moment there are also other things I have to work with.


EDIT:
I've go an idea: Functions are always called, no matter whether there are parantheses or not, but they are needed it parameters are passed. If one would like to give a function an alias (another variable pointing to the function), one can use the "ref" keyword.

# old syntax
music = sf.music.new()
music.play
...
window.draw sprite
... ... ...
func_ref = myfunction # func_ref points to the function of myfunction


# new syntax
music = sf.music.new # parantheses are optional, because there are no parameters
music.play
...
window.draw(sprite)
... ... ...
func_ref = ref myfunction

[MorleyDev]

Hmm, it feels like them being optional with no parameters is a waste when you could use the parameterless form for getting the method reference.

It'd make more sense to me either parameters being optional and using the ref, or making them required and not using the ref.

Using ref introduces an expectancy that you can get references to variables, which I don't know if you want SilverScript to support or not.