Interpreted language design decision

Discussion about everything. New games, 3d math, development tips...
Post Reply
chronologicaldot
Competition winner
Posts: 688
Joined: Mon Sep 10, 2012 8:51 am

Interpreted language design decision

Post by chronologicaldot »

I have a question for everyone here, but first, a bit of background.

I'm writing an interpreted language that I can incorporate into irrlicht (and other programs) and easily extend. I've made it such that I can control the input of tokens without modifying the main frame of the interpreter. The standard way of reading things would be simply getting token separated by spaces. I've also made the interpreter such that I can easily add new tokens (once again, without modifying the main frame of the interpreter) and give them the syntax I want. From the parser, I can grab any token I want and interpret it as an object in a couple quick steps. A couple important limitations, though: parenthesis and curly brackets create bodies of code.

My design decision comes in here:
I'm writing an extension class that interprets functions, and I'm trying to decide what would be the most convenient, logical syntax for running a function. The syntax for function creation is as follows:

Code: Select all

 
func myFunction params
{
 
}
 
Where "func" is a keyword that creates a function, "myFunction" is the name of the function, and "params" is either another variable or a list of variables formed by square brackets.

A few options to think about (other suggestions are more than welcome):

Code: Select all

 
run myFunction params
 
Where "run" is a keyword, "myFunction" is a function object, and "params" is either a regular object or a list containing objects. If it's a list, it could be enclosed in square brackets.

Another option:

Code: Select all

 
myFunction processes params
 
Where "processes" is a keyword.

Or maybe

Code: Select all

 
myFunction(params)
 
... as we're all used to. This actually requires more work on the part of the interpreter and not just because there's an extra token (the parenthesis at the end). Reason: The first part ("myFunction") returns an object. Parenthesis, however, already have the function of simply containing a body of code. In other words, there's nothing to associate the function with the parenthesis to indicate running.
Now, you may think, "Why not just use square brackets"? - The thing is, square brackets denote nameless list creation (although I may change this at you guys' suggestion to simply "list ... ;").


So that's the scenario. I'd appreciate you guys' advice, tips, and suggestions. Any questions?
REDDemon
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: Interpreted language design decision

Post by REDDemon »

I like first option => "run name params". run can tell to interpreter that next token is necessarily a function name. Probably requires less work than using "()" and seems more consistent with the definition of the function (you have used no parentheses in function definition parameters. And i think "run something" looks better than "something()"). I never writed a language so my opinion is almost countless.

the problem can arise with nested function calls (if you think to allow them of course)

value = sin( cos(x) + sin(x));

how will look with "run"?

value = run sin ( run cos x + run sin x); ?? assuming 2 returned values can be combined into an expression
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
chronologicaldot
Competition winner
Posts: 688
Joined: Mon Sep 10, 2012 8:51 am

Re: Interpreted language design decision

Post by chronologicaldot »

Yeah, if I implemented like that, which at this point is very likely, then your expression ( value = run sin( run cos x + run sin x ) ) would work.
Okay, sounds good. I also spoke with a friend of mine who recommended the same thing.
Post Reply