SFML community forums

General => SFML projects => Topic started by: Tenry on December 16, 2012, 05:12:59 pm

Title: SilverScript: New scripting language for game development
Post by: Tenry on December 16, 2012, 05:12:59 pm
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/ (http://silverscript.org/), but downloads are not yet available.
Title: Re: SilverScript: New scripting languages for game development
Post by: Nexus on December 16, 2012, 06:31:04 pm
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 :)
Title: Re: SilverScript: New scripting languages for game development
Post by: Tenry on December 16, 2012, 09:34:26 pm
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.
Title: Re: SilverScript: New scripting languages for game development
Post by: MorleyDev on December 16, 2012, 10:49:25 pm
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.
Title: Re: SilverScript: New scripting languages for game development
Post by: Tenry on December 16, 2012, 11:17:22 pm
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 :P

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.
Title: Re: SilverScript: New scripting languages for game development
Post by: Nexus on December 16, 2012, 11:38:05 pm
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 ;)
Title: Re: SilverScript: New scripting languages for game development
Post by: MorleyDev on December 16, 2012, 11:51:49 pm
New languages might always be confusing :P

Just saying, it's a little ambiguous.
Title: Re: SilverScript: New scripting languages for game development
Post by: Tenry on December 17, 2012, 02:23:15 pm
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).
Title: Re: SilverScript: New scripting languages for game development
Post by: panithadrum on December 17, 2012, 03:20:47 pm
I think that function calling without parentheses is a bad idea.
Title: Re: SilverScript: New scripting languages for game development
Post by: Mario on December 17, 2012, 03:44:00 pm
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.
Title: Re: SilverScript: New scripting languages for game development
Post by: Tenry on December 17, 2012, 04:18:48 pm
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.
Title: Re: SilverScript: New scripting languages for game development
Post by: Nexus on December 17, 2012, 09:21:18 pm
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?
Title: Re: SilverScript: New scripting languages for game development
Post by: MorleyDev on December 17, 2012, 09:33:13 pm
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.
Title: Re: SilverScript: New scripting languages for game development
Post by: Tenry on December 18, 2012, 07:56:12 am
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
Title: Re: SilverScript: New scripting languages for game development
Post by: MorleyDev on December 19, 2012, 03:09:48 pm
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.
Title: Re: SilverScript: New scripting languages for game development
Post by: Tenry on December 19, 2012, 04:57:55 pm
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.
Actually I'm not supporting references/pointers in SilverScript. The only usual way to pass "references" of for example Integers is packing them to a Class, as they are always referenced, if not creating a new instance of it (cloning).

When referencing a function via the ref-keyword, I want be able to change the reference variable (that points to the original function) without affecting the original variable, and then the ref-keyword can't work for numeric variables.
Title: Re: SilverScript: New scripting languages for game development
Post by: Tenry on January 05, 2013, 12:42:09 pm
Hi, it's me again. There are two things to say:

1. I'm still actively working on SilverScript. I've been rewriting the parser code, so that it is more efficient and that it now generates an Abstract Syntax Tree (http://en.wikipedia.org/wiki/Abstract_syntax_tree), which wasn't there before. This makes it for example easier to optimize script code (for example calculating expressions, of constants only, to the final value on the fly).

2. There are still many things, that aren't finally decided yet. I'm developing SilverScript to be used in my personal projects, but I want to make SilverScript's source code available so that any of you could use it in their projects as well, so your suggestions on the language design might be helpful.
Note that SilverScript is designed to be embedded in games (e.g. written in C++), but I'm planning to add the feature that one could write applications based on SilverScript (runned by the main interpreter executable) and extended, for example by DLLs. Here come the questions I have to you, please tell me, what you like best:

Thanks in advance in supporting me :)
Title: Re: SilverScript: New scripting languages for game development
Post by: Nexus on January 05, 2013, 01:47:08 pm
Quote from: Shy Guy
I saw that Ruby uses the $-prefix for global variables. Would you like to have the $-prefix as a synonym for global.?
I don't know how often this specific feature would be used, but in general, I would tend to not offer everything in multiple variations only to make everyone happy. It may easily cause confusion, if it's not clear that there are no differences.

Quote from: Shy Guy
Should it be possible that classes have private, or even protected members?
What about virtual methods? (class inheritance is already planned)
This depends on how complex you want the language to be. Should it be a simple script language for configurations and AI scripts or similar? Or do you want a full-fledged interpreted language with OOP language features?

I personally would keep things simple for the moment, and make sure they run stable, bug-free and efficient. You can still add more features later. But for complex OOP designs, statically typed languages scale better -- while script languages are useful to manage the dynamic parts, or configurations.

Quote from: Shy Guy
Would you prefer the last expression of a function always being the default return value, or would you only allow explicit return values with the return keyword?
What if there are multiple places to leave a function? I would prefer return statements.

Quote from: Shy Guy
What do you think about "everything is an expression"? For example, should this be possible?: x = if y > 0 then true else false
Basically an interesting idea, but can it be applied to everything? What's the expression of a loop? Of a function call that returns nothing? In this specific case, you could also use something like operator?: :P

Quote from: Shy Guy
What do you think about the idea, that any number of parameters can be passed to a function, no matter how many are specified? Non-passed parameters are initialized as nil (or their default value).
You lose type safety by doing so and introduce the need to check for validity of function parameters. However, there could be a way to pass multiple parameters to functions (in an array/list or something).

Quote from: Shy Guy
When passing more parameters to a function as specified, how would you like to access the additional parameters? (compare with vargs and printf-like functions in C)
As stated, a list or something similar might be the way. Do you have such a data structure which is built-in to your language?

Quote from: Shy Guy
In syntax, while-loops look like if-loops, just with a different keywords. Which other loops would you like to have (such as for), and how to design it?
If-statements are no loops, they are executed at most once. The for loop should definitely be available, its design depends on other language features. Do you have something like intervals or ranges?

Also, a foreach loop would be very handy.

Quote from: Shy Guy
What do you think about the distinction between Integer and Decimal in my language? Types are dynamic, though.
The distinction is a good idea, it allows to check more easily for valid index access, for example.

Quote from: Shy Guy
What should count as "false"? Only nil and false? Or also 0? What about "empty" classes and arrays?
What does "count as false" mean? Inside if statements? What I wouldn't do is the ambiguity that if (xy) is true if xy is valid or true. I would allow only boolean statements in conditions, and provide something else to check for the existence or validity of a variable, maybe an additional operator like if (#xy).

Do you differ between existence (variable has been assigned a value) and validity (variable is not nil)? If so, is it possible to "undeclare"/delete a variable, such that it becomes inexistent?
Title: Re: SilverScript: New scripting languages for game development
Post by: Tenry on January 05, 2013, 03:11:37 pm

Quote from: Shy Guy
Would you prefer the last expression of a function always being the default return value, or would you only allow explicit return values with the return keyword?
What if there are multiple places to leave a function? I would prefer return statements.

Quote from: Shy Guy
What do you think about "everything is an expression"? For example, should this be possible?: x = if y > 0 then true else false
Basically an interesting idea, but can it be applied to everything? What's the expression of a loop? Of a function call that returns nothing? In this specific case, you could also use something like operator?: :P
Just the last expression of a function would be returned, if nothing else was explicitly returned with the return-keyword. Things like a loop could simply return nil (i.e. "no" value). This is also the default value for uninitialized variables, variables which aren't assigned to any (other) value yet.



Quote from: Shy Guy
When passing more parameters to a function as specified, how would you like to access the additional parameters? (compare with vargs and printf-like functions in C)
As stated, a list or something similar might be the way. Do you have such a data structure which is built-in to your language?

Quote from: Shy Guy
In syntax, while-loops look like if-loops, just with a different keywords. Which other loops would you like to have (such as for), and how to design it?
If-statements are no loops, they are executed at most once. The for loop should definitely be available, its design depends on other language features. Do you have something like intervals or ranges?

Also, a foreach loop would be very handy.
Yeah, I would like to make foreach loop possible. The current "interval" data type in SilverScript is the array, but I was thinking of arrays not having a specific "size" (any index out or range simply is nil and could be assigned to any value; index mustn't be negative or a decimal number).

Just another note: first I wanted the array being a data type itself. If you have a variable number of items stored in it (instead of simply 2, or 17 or another static value), you have to store the size in a separate variable, as 1. the array does not really have a size visible to the programmer and 2. neither there's (yet) a "size"-operator, nor I could provide a "size"-method, because any attribute access (with the dot .) would convert the array back to an object.
But I've got a new idea: an array is not a data type itself, but instead it is just an object. Any object can have attributes/methods (which have names/identifiers), but also have, let's say, "unnamed" attributes, accessed by their indices, accessed with the []-brackets.



Quote from: Shy Guy
What should count as "false"? Only nil and false? Or also 0? What about "empty" classes and arrays?
What does "count as false" mean? Inside if statements? What I wouldn't do is the ambiguity that if (xy) is true if xy is valid or true. I would allow only boolean statements in conditions, and provide something else to check for the existence or validity of a variable, maybe an additional operator like if (#xy).

Do you differ between existence (variable has been assigned a value) and validity (variable is not nil)? If so, is it possible to "undeclare"/delete a variable, such that it becomes inexistent?
I especially mean in conditions.
Actually, there isn't yet a way to check a variable's existence (hence a variable assigned to nil, the default value, then "exists"), although the "existince" of a variable is important in another aspect of my language... a special operator for checking a variable's existince is a good idea, let me think... the hash (#) is already used for comments, but there are some other symbols left, I could use:
Title: About Arrays, Ranges and Objects
Post by: Tenry on February 18, 2013, 06:21:07 pm
It's me again. I got back on developing on SilverScript and my Parser (which generates the abstract syntax tree) already works very well. Now there come some more questions about the language design, and I rely on your opinions.

In SilverScript, literal Arrays are possible. Conside the following code:
foobar = ["First Element", "Second Element", ...]
# is the same as:
foobar[0] = "First Element"
foobar[1] = "Second Element"
foonar[...] = ...


Classes (you may also call them Objects at this point) are some kind of simple containers: it contains identifiers which refer to some numbers ("attributes") or some functions ("methods") and are accessed with the dot (.). Example:
# assuming foo being a class/object
foo.bar = 27


First I wanted Class and Array being two different data types. But maybe they could both be the same data type (an Object)? I mean, foo can have an attribute (foo.bar) and an index (foo[12]) at the same time. In any case, should an Array and a class always be initialized explicitely? (i.e., foo[12] or foo.bar throws an error if foo isn't an Array/Class/Object yet)


I think, Ranges could be a handy thing in programming, so I was thinking of implementing Ranges. They are useful to extract substrings or a piece of items from an array. Consider the following example:
# assuming foobar being a string or array
foobar[0] # access the first char/item
foobar[0..4] # from-to (inclusive): access the first 4 chars/items (0, 1, 2, 3, 4)
foobar[0...4] # from-to (exclusive): access the first 3 chars/items (0, 1, 2, 3)
foobar[0,4] # from-length: access the first 4 chars/items
foobar[1,] # access everything without the first char/item
foobar[,4] # access the last 4 chars/items


Instead of the pure literals to access the items (like in the example above), the user may also use identifiers:
foobar[from..to]
foobar[start,length]
foobar[my_range]

As you can see in the third line, the brackets [] shouldn't be necessary for ranges. You could write:
my_range = 1..5
Even if I would make the brackets required, I've got problems with the special ranges expressed with [start,len], [start,] and [,len], as especially the first one could also be interpreted as an array with the elements start and len, which isn't the same as a Range (yes, I want Range and Array/Object being different data types).

Do you have any ideas on the design at this points? Any opinions and suggestions are greatly welcome :)
Title: Re: About Arrays, Ranges and Objects
Post by: Nexus on February 18, 2013, 07:54:32 pm
First I wanted Class and Array being two different data types. But maybe they could both be the same data type (an Object)? I mean, foo can have an attribute (foo.bar) and an index (foo[12]) at the same time.
Hm, what's the use case for something that's an array and a class at the same time? I mean, wouldn't it be clearer to take a class that contains an array in such situations?

Something you could also think about are maps/dictionaries. One possibility is to unify everything (array, object, map) like the tables in Lua. I have not worked a lot with them yet, so I don't know how well this works in practice. One thing you have to consider is that the more dynamic and interchangeable your types become, the more easily they are confused and type errors occur.

In any case, should an Array and a class always be initialized explicitely? (i.e., foo[12] or foo.bar throws an error if foo isn't an Array/Class/Object yet)
I would enforce an initialization. When you don't have strict scope and lifetime rules, there may still be an old object with the same name, and one accidentally reuses it.

I think, Ranges could be a handy thing in programming, so I was thinking of implementing Ranges.
Sounds like a good idea! However, I would take the .. operator for half-open intervals, as this case appears more often. Especially when your indices start at 0, you will often have intervals of the form begin..arraysize. From my own experience, the way how the STL does it is very intuitive and doesn't require off-by-one corrections (+1 or -1).

Even if I would make the brackets required, I've got problems with the special ranges [...]
Why don't you take curly braces for arrays, like a = {1,2,3}?
Title: Re: About Arrays, Ranges and Objects
Post by: Tenry on February 18, 2013, 08:28:12 pm
Hm, what's the use case for something that's an array and a class at the same time? I mean, wouldn't it be clearer to take a class that contains an array in such situations?

Something you could also think about are maps/dictionaries. One possibility is to unify everything (array, object, map) like the tables in Lua. I have not worked a lot with them yet, so I don't know how well this works in practice. One thing you have to consider is that the more dynamic and interchangeable your types become, the more easily they are confused and type errors occur.
Taking a class containing an array might mean, that the user could implement an array class himself, too. And if the access works with the []-brackets, SilverScript should have some kind of operator overloading, and I have no clear plans yet how to design operator overloading methods.
Nonetheless I'm going to have Arrays (with indices 0, 1, 2, ...) and Maps/Hash Tables. Maps will only allow strings as keys, just to permit the use of something like an object as a key (there isn't a clear definition about object comparison behavior, yet).

I would enforce an initialization. When you don't have strict scope and lifetime rules, there may still be an old object with the same name, and one accidentally reuses it.
SilverScript has very local variables, similar to the principle in PHP with the functions. Variables from an outer namespace are to be accessed explicitly.

I think, Ranges could be a handy thing in programming, so I was thinking of implementing Ranges.
Sounds like a good idea! However, I would take the .. operator for half-open intervals, as this case appears more often. Especially when your indices start at 0, you will often have intervals of the form begin..arraysize. From my own experience, the way how the STL does it is very intuitive and doesn't require off-by-one corrections (+1 or -1).
Could you show me examples / explain in detail? I have never worked with Ranges yet, I just saw that feature in Python and Ruby on the fly.

Why don't you take curly braces for arrays, like a = {1,2,3}?
I was thinking about something like that, too. But: {} for arrays and [] for ranges? Or vice-versa? And what about literal hash tables? Here is what I was thinking so far at the moment:
my_array = [ "First Item", "Second Item", "You may also use other types:", 27.5, [ "SubArray", ... ] ]
my_hash = [ "Name" => "John Doe", "Location" => "USA", "Age" => 22 ]
class my_object # the same as: my_object = class
  x = 0
  y = 0
end
# what about the following additional syntax for literal objects?
my_object2 = { x = 0, y = 0 }
my_range1 = [0..3]
my_range2 = [5,2] # <-- would be interpreted as an array.....
Title: Re: SilverScript: New scripting language for game development
Post by: greeniekin on February 21, 2013, 09:23:56 am
I like some aspects of this. Like simi-colons are a bit nasty when it is bad form not to have and enter after the line. Why not just have a new line and that's it. I have done a lot of programming in javascript and dynamic types can be nice sometimes.

I still, like everyone else, thinks functions should have brackets. It makes things more clear.

Not having braces seems personally weird. I use to program in qbasic and then visual basic. Though i have been doing so much work in php, javascript, and c++ that it just seems weird. I do get it though. Indentation is an important part of making something readable.
Title: Re: SilverScript: New scripting language for game development
Post by: Tenry on July 09, 2013, 10:14:12 pm
Update

After a long break I continued the development of SilverScript. In addition, the language design got some minor and major changes:
The license for the first release might be LGPL (http://www.gnu.org/copyleft/lesser.html), but it's propable to become zlib (http://zlib.net/zlib_license.html) in a later version when SilverScript is matured.


EDIT: I forgot to show you what the C++ API is going to look like. Here a short example snippet:
#include <iostream>
#include <SilverScript.h>

using namespace std;

int main()
{
  sil::VM vm; // the virtual machine; it is initialized automatically
 
  // load a script and pack it in a callable function object
  sil::Object func = vm.loadFromFile("test.sil");
 
  // check whether script was loaded successfully
  if(!func.isNil())
  {
    sil::Object result = func.call(); // call script and get return value
    cout << "Result: " << result.toInteger() << endl;
  }
 
  return 0;
}
Title: Re: SilverScript: New scripting language for game development
Post by: Nexus on July 09, 2013, 11:38:52 pm
The changes sound good, nice to see you applied some of the suggestions from this thread :)

By the way, what tools do you use for the implementation? Just standard C++? Or a parser framework like Boost.Spirit?
Title: Re: SilverScript: New scripting language for game development
Post by: Tenry on July 09, 2013, 11:45:33 pm
By the way, what tools do you use for the implementation? Just standard C++? Or a parser framework like Boost.Spirit?
I'm only using the new C++11 standard, including some of its new headers and classes. I might try to make a portable version not using the new C++ as well. In addition I plan to provide a version for C, too.
Title: SilverScript: Concept of Modules
Post by: Tenry on October 02, 2013, 03:53:14 pm
Like in any other programming and scripting language there shall also be the possibility in SilverScript to put the code in several files for better overview and maintenance. So I am thinking about the concept of so called modules.

Let's say, you have got your main script file main.sil, and you define a class for creating a window in window.sil.

window.sil (1):
class window
  # attributes and class methods
end


main.sil:
use window # the interpreter looks for window.sil and loads it into the "window" namespace/class
@my_window = new window.window()



Note that you can give modules, you import, any alias you want:
use window as w
@my_window = new w.window()



There are also cases, where you want to load a module directly into the current namespace. This is supported through the keyword import:
import window
@my_window = new window()



If your module only has got a single class, you can also trick there a little bit and treat the module as a class:
window.sil (2):
@window_attribute1 = 0
@window_attribute2 = 0

# ...

function new() # constructor
  # initialize a new instance
end

# more class members...



main.sil:

use window
use window as foobar

@first_window = new window()
@second_window = new foobar()




Please tell me your oppinions and suggestions about these plans. Do you have any improvements?
It is not clear yet, where the module files (when using/importing a module the first time) are searched and in which order, but they shall be searched at least in the directory where the requesting script file lies.