SE4 Scripting in Python (templatizer again) - Page 6

Ed Kolis · #51 August 12th, 2004, 11:19 PM

New Version of the (text-based) Templatizer ready - now with caching, so it's much faster!

Hmm, when will I ever get back to work on that graphical modding tool?

Ruatha · #52 August 31st, 2004, 01:18 AM

What's happening with the graphical shell?

Ed Kolis · #53 October 18th, 2004, 01:23 PM

Oops, sorry, must have lost track of your post, Ruatha... I haven't done anything on a graphical shell yet, but what I am doing is completely rewriting the program to make it faster and more powerful. See, right now, it's horribly inefficient at parsing the text, because basically if you have 5 + (2 * 3), it searches for the outermost operation (the plus), and splits it up into two expressions, 5 and 2 * 3. Then it takes the 5 and says "oh, that's a number", and stores it away. The 2 * 3 then gets parsed AGAIN (even though it was already searched through to find the plus) and split into the 2 and 3. Then, those numbers are multiplied to get 6, and then 5 is added to get 11. This may not seem to inefficient, but imagine a long expression with many subexpressions, such as sin(pi * (2 + atan(6) * e) - 1?

So what I WANT to do is do all the parsing at once, only once, and THEN do the evaluation. This will involve something I've come up with called "functional notation" where every operation, constant, or variable is represented as a function, so for instance 5 + 2 would be represented as +(5,2), and sin(pi / 3) would be represented as sin(/(pi(),3)). Actually functional notation has probably been invented already, but I thought of it independently, so there

Which leads me into the main reason for this post: I noticed that using functional notation, there could only be one function or operator with the same name and "arity" (which is the number of operands). This reminds me a LOT of a programming language called Erlang, because there was the same restriction on Erlang's functions, seeing as Erlang was a weakly-typed language. SO... what I'm thinking of doing is, while I'm already rewriting everything, adding a *scripting language* to my expression evaluator, so that you can define your own functions without having to compile any C# code. Basically, I'd have only the most rudimentary functions and operators predefined, and the rest would be called through script. I know, you say scripting Languages are slow, but C# has this nifty feature which lets you compile and execute code "on the fly", so I could compile the scripts whenever the program is run (don't worry, C# code compiles fast

), and then execute them as compiled code in memory!

SO... what my question is, is what would be the preferred language of the Users of this program to base the scripting language on? The most natural choice for me would be C#, because that's what I use, but VB would work as well, since the on-the-fly compiler can work with either language. But since I'll probably have to write my own language parser (to allow only harmless instructions like "return x+y" and "if p then loop until q" and nothing like "delete c:\windows\*.*"

), I could just as well base it on some other language, like Python or Erlang... problem is, I don't know much ABOUT Python or Erlang...

So, anyone have a preference?

Aiken · #54 October 18th, 2004, 02:39 PM

I'd prefere native c syntax. It'll make your work much easier. Just don't forget to rewrite documentation

Fyron · #55 October 18th, 2004, 02:47 PM

VB is not an option... Stick to real Languages.

Python would be a very good choice. Python has similar syntax to C/C++.

Gandalf Parker · #56 October 18th, 2004, 03:03 PM

Quote:

Imperator Fyron said:
VB is not an option... Stick to real Languages.

Python would be a very good choice. Python has similar syntax to C/C++.

Really? VB not an option for a scripting language? Of a game that is Windows restricted? You would rather have scripters in C syntax instead of basic?

Aiken · #57 October 18th, 2004, 04:20 PM

The best scripting language is the language you know best of all.

It really doesn't matter VBS, JScript, python or perl or pseudoC script.
Probably VBS or JScript are more convenient than others, because of WSH.
Personaly, I don't like VBS and VB (in general) too - many inherent flaws and bad design. So my next vote will go to JScript.

Fyron · #58 October 18th, 2004, 04:25 PM

Quote:

Gandalf Parker said:

Quote:

Imperator Fyron said:
VB is not an option... Stick to real Languages.

Python would be a very good choice. Python has similar syntax to C/C++.

Really? VB not an option for a scripting language? Of a game that is Windows restricted? You would rather have scripters in C syntax instead of basic?

You can easily install other scripting language interpreters on Windows, including other "basic" type Languages... it is just a few clicks away. VB is no good.

Ed Kolis · #59 October 18th, 2004, 06:35 PM

Hmm... a divided opinion... well, I could always have functions loaded as modules, and let the user choose between VB and C#, and screw the security considerations - if you're dumb enough to run a malicious program when the source is sitting right in front of you, it's your fault!

Gandalf Parker · #60 October 18th, 2004, 08:22 PM

Quote:

Imperator Fyron said:You can easily install other scripting language interpreters on Windows, including other "basic" type Languages... it is just a few clicks away. VB is no good.

That wasnt what I meant. Not that Im big on "run this, but of course you will have to go get this first" type of programs. I was just totally disagreeing with a blanket sheep statement like "VB is no good". Everything has its pros and cons. VB doesnt have many but as a beginners scripting language in fairly english usage that would seem to be what its for.

But dont mind me, I wouldnt prefer VB either. I prefer to do all my coding on linux then run it in windows