Language alternatives?

[itsyfox]

Alright, don't kill me, but...

I think there might be better languages than CScript and ASM to use for scripting in Zelda Classic. If it wasn't too much trouble, would you change languages?

Would it be too much trouble?

I know a lot of people would probably complain that they had to rewrite their scripts, but let me explain...

I'm suggesting Python. Not to run the graphics, but to provide the scripting interface, at least. It also 'compiles' to it's own byte-code, so having the ASM layer for efficiency would most likely be unneccessary, too...

Here's why:

1) Python has a wide variety of data types, including multi-valued types such as tuples and dictionaries.
2) Python has classes. You can write your own classes to use, and child them to existing classes, declaring their type if desired.
3) Python is designed to be pretty. No semicolons or curly-braces to worry about, instead, it's the indentation itself that designates blocks. And since it's formal to indent anyways, that simply takes out unnecessary characters that often trip you up if you aren't careful, and leaves only the more obvious (and very clean looking) indentation.
4) Python has a wide variety of commands that can be used, but there's not too much overlap.
5) Python is a very easy language to learn. There are more words than symbols, and not much of the language is cryptic at all. Most of the commands are straightforward, and mean what you'd guess.
6) It really knows how to use integers! Yet you can still do all your bit-shifting and such when you want. Plus you can AND and OR your conditionals together, reducing the number you need.
7) It's highly portable, and will still work on all three platforms.
8) There's already a Python binding for Allegro, more than one, but here's one I found: http://sourceforge.net/projects/pyallegro/
9) Bindings are also fairly easy to make, using the C libraries version of the interpreter, or others.

Let's have a small example. I'll make up some code in ZScript, then in Python. For the Python, I'll basically just make Python-style commands with the same names as the ZScript commands.

ZScript code (not necessarily functional):

ffc script foo {
    import "std.zh";
    void run() {
        int a_variable = 4;
        while(true) {
            while(Screen->NumItems() < a_variable) {
                Screen->CreateItem(I_RUPEE1);
                item thisitem = Screen->LoadItem(Screen->NumItems());
                int randx = rand(16) * 10 * 16 & 224;
                int randy = rand(16) * 10 * 11 & 224;
                thisitem->X = randx;
                thisitem->Y = randy;
            }
            Waitframe();
        }
    }
}

Equivalent Python code:

ffc script foo
    """
    Python doesn't have to be contained entirely inside functions.  What was outside of all functions would be run first.
    Global scope exists for any loop not in a function; otherwise anything declared inside a function is function-local scope.
    The same is true for anything created in a class, in order to reference a class variable you use dot syntax.
    Normally you'd use dot syntax for imported commands too, but since you did 'from x import *' instead of just 'import x',
    you can use all the commands directly.  This allows you to import specific functions and classes, too, rather than a whole file.
    """
    from std import * #import what is currently std.zh but would probably be std.py or std.zpy or something
    #init some variables
    a_variable = 4
    create = Screen.CreateItem
    load = Screen.LoadItem
    items = Screen.NumItems
    while 1 #do this every frame
        while items() < a_variable #do this while we're below our max
            create(I_RUPEE1) #create a green rupee 
            thisitem = load(items()) #store the current item
            randx = rand(16) * 16 #get a random x that's on a screen tile
            randy = rand(11) * 16 #get a random y that's on a screen tile
            #move the item to the random coordinate
            thisitem.X = randx
            thisitem.Y = randy
        Waitframe()
#and we're done!

You could also create a class of ffc, even for a generic type of custom enemies! You could create a class based on any existing classes, and give it any functions, variables, and subclasses you wanted!

Also, by setting the value of arguments in a function declaration, you can have optional arguments. for instance, the python code:

function foo(x, y, z)

would require you supply x, y, and z, but the code:

function foo(x=0, y=0, z=0)

would allow the function to have default values of 0,0,0 and be called with any or none of the arguments!

Python is a wonderful language. Wonderful. If it were used instead of ZScript, I'm sure the initial grumble over re-writing code would turn into appreciation for a really nice language.

Also, when you saved a script to a slot, it would compile python byte code instead of ASM. That way, you only need work with one language, but you have all the functionality right there, high and low level both.

Then all the developers need is to be able to compile their own python bytecode right into the engine, to make development far more modular and far less hard-coded. ^_^

And heck, if this were to be done, with as few ZScript commands as there are anyways, I'd be willing to spring and write a ZScript->ZPython converter! Maybe ZASM too, but I haven't learned ZASM yet.

[jman2050]

If it wasn't too much trouble

Too much trouble. No.

[itsyfox]

Alright. It was a suggestion, but I understand. Sorry for making a poor suggestion. ^_^

[jman2050]

It wasn't a poor suggestion. It just isn't feasible right now.

[itsyfox]

Oooh, right now.

Now, I'm not jumping all over that and saying "When? When?"

Because actually, and I should have mentioned this the first time, this isn't at all a suggestion for 2.5.

I only put it in the Beta forum because that's where the Scripting forum is. I put it in Scripting Suggestions, 'cause it's all about scripting. ^_^

However, I understand that it might take awhile, and that you're locked on new features right now. That's all cool, and I wasn't expecting you to jump on this for 2.5.

Or 2.6, 2.7...it's just something I'm throwing out there. For maybe, eventually. And like I said, if it was ever done, I'd even write the converter for everyone's scripts myself.

And hey, somebody once suggested a validator.exe. If I was making a converter, it should validate the new code anyway, right? So it would serve a double-purpose there.

Anyway. No pressure, no insistance. It isn't necessary. I'd just like it, and I bet there's others that would, too. ^_^

[DarkDragon]

Uh, well, as I've said before, if you were to write a program in C that compiles Python (or whatever) to ZASM (as ZScript currently does) I'd be more than happy to integrate it into ZQuest.

I fully understand there are many very good programming languages, each with their own advantages and disadvantages, but compiler are not trivial to write - the ZScript compiler represents about 3 solid weeks of work during my summer vacation - three weeks which were therefore not spent fixing bugs. We quite frankly don't have time to write and support java, perl, python, lisp, ocaml, mzx robotics, or any other very nice existing language-like compilers.
I chose C for ZScript for the following reasons:
1. Most people who know how to program already know how to program C. This statement is becoming less true, but certainly remains more true for C than for Python.
2. C, being a lower-level language, needs a simpler compiler, and I am lazy.
3. I had previous experience with the C grammar and the tricky parts of its implementation.

I don't claim that C was the best or only choice from a theoretical perspective; holy wars could be fought over that question.

[itsyfox]

Alright.

Well, one thing about Python is, the base of all its implementations *is* an interpreter.

And yes, Python is an interpreted language. But see, like ZScript, it can be compiled to a much more efficient, low-level 'byte-code', which usually shows up with the .pyc extension (and, when you have Python on your computer, looks like a stone tablet with code in it, as opposed to the normal page. ^_^)

So, ideally, (on the Python side anyways - I don't know about the ZC side) this would replace both ZScript AND ZASM.

You'd only be writing in Python.

However...

I could also look for a Python implementation in Assembly, and perhaps modify it with the ZASM commands (once I become familiar with them).

I'd try to make it as modular as possible so commands could be added to the ZASM Python interpreter/compiler easily. Like, add a command to ZASM, and only like...two or three lines of code to attach the Python to the ZASM instruction.

Like,

function NewCommand(arg, arg...)
    returnval = ReadZasm(Funcname, arg, arg...)
    return returnval

And that should be as much as it needs, once such a deal is written.

Python usually does such things with strings, so there'd probably be a string parser inside of ReadZasm. Like, take funcname and args and place them into the appropriate string, which would then look like a ZASM command.

I'm familiar with stack-based languages, because I've programmed in a variety of the Fourth language. So I know about push, pop, and all that, and GETV and SETV look fairly straightforward. Once I learn the rest of the syntax, and the ZASM-unique commands, things should be fairly straightforward.

If you want, I'll get to work on that right now! But, like I said, if some developers are stressed about getting 2.5 (or at least the next beta) out soon, I'm not saying it has to be implemented NOW. Just, when it's done, and you're all ready.

Plus, jman, looking at some of your threads and your treatment of ZScript and ZASM, it looks like you've worked really hard on them, and you're really proud of them. I *totally* respect that, and certainly don't want to throw out any of that hard work. The idea is to include it, to 'convert' or at least overlay, so to speak, in a language that while people may be less familiar with, is very easy to learn, I'd say either on par with or even easier than any form of BASIC. Plus it comes with SO MUCH functionality already for things ZScript and ZASM need to be programmed in manually...

EDIT: Alright, perhaps this should be our solutions to questions like this, instead of bugging the developers?

I'll make an external compiler.

This is from another thread a long time ago where someone suggested a different scripting method. He said when he had enough knowledge, he'd do so.

If it's gotta compile to ZASM anyways, then why shouldn't people who want a different language just be able to write that?

I mean, a *compiler* is one thing, but parsing a file for strings, and changing the string format to match a different language, is something else. This is just 'if this word, this word' and such. Instead of dealing with memory and bytes and uncompiling data...it's nothing but a string parser.

So. I'm willing. I'll probably just make a simple Tkinter or WXWidgets interface, and it will have a Python buffer, and a ZASM buffer, and you'll be able to import/export both to file, just like ZQuest currently can with ZScript. This would all most likely be written IN Python, or maybe in C-Python so it could be compiled to all platforms. It SHOULD be compilable to all platforms, and I don't want to force people to download Python to run it.

And I'm sure anyone who wanted to program in a different language could do the same. They'd still have to learn ZASM at least, however.

I *do* have one question. Does ZASM currently have, at all, data types for either strings, or even just chars? Python could have tuples or lists of chars no problem, so if it even has the most basic data type, I could make much more use of strings in a Python to ZASM type thing.

I know you're working on strings for the Dialogue editor, so it'll be there soon no matter what. I was just wondering if the data types were even there yet. I'll be patient if they aren't. ^_^

Being able to store strings to a variable would be nice even if you *weren't* going to use them for the dialogue editor.