Lua

[Doomguy0505]

We could make an intermediate language and use an external compiler.

[Zippy]

We could make an intermediate language and use an external compiler.

That is to say, source code which gets translated into Lua, and then run by ZDoom? Or Lua code that gets translated into something ZDoom can run? Because the second scenario barely makes any sense at all, and as for the first, it's a little roundabouts and it doesn't solve Graf's problem in that engine is still internally dealing with Lua.

Lua looks fine to me, and I still think if it came down to it, most people who needed it would just learn it, use it, and move on. Clearly, though, it's a much bigger question for some people. Here's what I think:

Taking something that already exists, like Lua, and getting it implemented soon would be nice. More features quickly, hey, great, wonderful, good times. Speed and progress. Work cycle finishes, product ships, profits go up, and... oh wait.

ZDoom is still just an open source hobby project. As far as I'm aware of, nobody's employed to work on it. More features soon to the people who use it is nice, yes, but it isn't obligiation. It's not owed to anybody who uses ZDoom. The question to people who spend their own extra time working on the source isn't what can you get to us, but what do you want to do with ZDoom? Developing ZDoom's own custom scripting could take awhile, but I can see why, for someone who is interesting in that kind of thing, they might want to do it. Doubtless, an interesting development experience.

If ZDoom were to suddenly cease development, I don't think I'd be concerned. I've always felt ZDoom is amazing as is, certainly far beyond the original Doom, and further, I think, than all the other ports out there. I don't think it needs anything more, but as long as people still want to work on it, I'm eager to see what new things they add, how they handle development, contrast it to what I might do if I had the inclination to work on the project (or just against my own opinions and knowledge; still a ways to go in the experience department.) Things don't need to be added to ZDoom, especially for some kind of timetable, for anyone but those doing the adding. Getting something useful to everyone who uses ZDoom is very generous and wonderful, but secondary to something more important:

What do you want?

[Kate]

Quote
________

That's like Brain rape!

That's the point of Esotoric Programming Languages -- Some of them are designed to be as obfuscated (difficult to read) as possible. And I'd say Malbolge wins at that. XD

Lua
________

Personally I see it as a welcomed addition to the cycle. Having delt with dynamic typing and object-orientation (Python \o/), it actually seems rather familiar in many ways to the interpreted scripting language that I'm more used to.

While it may look strange to those hardcore C junkies (Graf you can't live without your brackets, can't you? ;P), it has a lot more flexibility in the way it treats and handles parsing of code. I say if it's going to be just as useful, then that should be the way to go.

One must take into consideration that the readability of a code depends not on the language the code is written in, but rather the one whom is writing the code, and the one whom is reading it. Any language can be made into either a beautifully executed source or a mangled distraught mess of epic proportions, so I truly don't see the point in arguing over style differences. Readability is an exercise left up to the programmer and the reader. The reader should be aware of, by the least, the simple ins, outs, and limitations of the language they are reading, and the programmer should be aware of the complicated situations in their code where the reader could otherwise not understand a point or get lost. Here's my obligatory example on readability. Sure, it's not my best ever or even very useful, but it should be bleeding obvious on every line what's going on.

Code: Select all • Expand view

"""Print a smooth sine from 0.0 to 1.0 and wait 1/35th sec. between each print.

A very simple, fully working Python example."""

from math import sin, radians
from time import sleep

TIC = 0.0266666666667 # This is *pretty much* 1/35th of a second as far as my guesses go.
angle = 0

while angle < 90:
    print sin(radians(angle)) # sin() takes radians, not degrees.
    angle += 3
    sleep(TIC)

print "Finished."

[Doomguy0505]

@Zippy: I mean P-Code, which would probably go faster than Lua.

[Kappes Buur]

What's so unreadable about it? It's perfectly understandable to me. And the "problems" of dynamic typing aren't obvious either. You still get type-checking, just at run-time instead of compile-time.

Need I also mention that OBLIGE is written primarily in Lua?

If the conversion to Lua becomes a reality, I wonder how the ZDoom community will fare.
It is alright for an advanced programmer to state that something is easy to understand, but I
have a feeling, that for 90% of ZDoom mappers this will become an unsurmountable
obstacle and either stick with ZDoom as it is now or switch to Skulltag, GZDoom or perhaps
EDGE.

ACS in it's present form may be limited, but it is easy to pick up. LUA seems to be too much
of a learning curve, particularly when someone is not set on a career as a programmer.

[Doomguy0505]

Why not have both Decorate and Lua?

[Graf Zahl]

What's so unreadable about it? It's perfectly understandable to me. And the "problems" of dynamic typing aren't obvious either. You still get type-checking, just at run-time instead of compile-time.

Let's just say that I have to spend too much time at work with programming languages I don't like. For my recreational activities I don't need more of the same. My main problem with Lua aside from the syntactic differences is that the untyped variables often make it very hard to decipher what type a specific value is. Referring to the declarations to help me understand something is a total impossibility with this language and robs me of one of the most important things I use to understand code from other programmers.

Need I also mention that OBLIGE is written primarily in Lua?

No. Yet another big chunk of code that strengthens my feelings about the language.

But just out of curiosity: How fast is Lua? What's the speed factor between compiled C code and interpreted Lua code? The way the language works there has to be a lot of dynamic data management to get it all done which would create quite some overhead.

[Doomguy0505]

Is there a p-code version of Lua or anything like that?

[k0da]

Is there a p-code version of Lua or anything like that?

Lua normally compiles source into bytecode at runtime. This step can skipped by using the Lua compiler to write bytecode to disk beforehand. There's also a JIT add-on called LuaJIT.

[Grubber]

It'd be easier to write a new one from scratch. It's not too hard to write a compiler. Some time back, I whipped up a working prototype in a single week. (Unfortunately, the language it compiled was too underspecified, so all the work went to waste. e.g. It had no functions and no easy way to add them, so it wasn't good for much.)

I have something 10% done built into ZDoom laying on my HD, but it's just a collection of ideas (not working ATM). If only I had time, I would continue working on it .

[Graf Zahl]

Care to show it? Maybe if it's worth pursuing we can combine forces on it. I think the biggest problem with Doomscript so far has been that everyone tried to cook up his own solution alone instead of doing it together.

I think what should be done first is to collect a list of language features that would be useful. Obviously the language doesn't need to be able to handle everything C can do but on the other hand should be able to make interfacing Doom's engine capabilities easier.

Regarding Lua, I think this last issue is its biggest shortcoming unless the language itself is extended. It may be an interesting alternative to get it up and running quickly but syntax and other issues aside I have a fear that later it will come back with a vengeance once we want to do stuff with it that are not that easy to handle (I have the same reservations with Squirrel.) After all it is a general purpose scripting language so a direct interface with Doom's data structures will never be possible and always have to use uncomfortable workarounds.

The good thing is that this summer I will have more time to work on ZDoom than I had in the last 8 months. But since I have no experience with compiler design or defining a grammar for a compiler I'd need at least some help there to get a rudimentary setup up and running. The details can be filled in later piece by piece but I really think that we can do something far better than Lua if we combine our efforts.

So far the only decent scripting language for engine code is VavoomC. I think ZDoom should get something fundamentally better.

[Grubber]

Sure. IIRC the newer one can be compiled and runs. But I don't think there's anything very useful in it.

[Grubber]

I think what should be done first is to collect a list of language features that would be useful. Obviously the language doesn't need to be able to handle everything C can do but on the other hand should be able to make interfacing Doom's engine capabilities easier.

Well, I have some ideas. E.g. the data types:

Code: Select all • Expand view

bool: bool var;
int: int var;
name: name var;
float: float var;
string: string var;
class: class</parentclass/> var;
struct: /structname/ var;
object: /classname/ var;
array: array</type/> var;
static array: /type/[/count/] var;
map: map</keytype/, /valuetype/> var;
delegate: delegate /type/ var (/args/);


Inline action functions:

Code: Select all • Expand view

actor Something
{
    states
    {
    Spawn:
        SOME A 1
        SOME A 0 {
            if (something)
                do something;
            do another something;
        }
        loop
    }
}

...and others. I can write a full list of them if you want.

[Graf Zahl]

I think for decent handling we'd need at least another data type 'sound' so that sound names and indices can be handled interchangeably. I think a special data type will be less work than providing a set of conversion functions or special handlers to have the script programmer do that himself

Now I'll take a look at your stuff. I'll post some comments when I am done.

[Graf Zahl]

Hm, ok, you are probably right that this isn't that useful to begin with.

I think a formal grammar is still needed for a proper language definition first. However, I am wondering if we could use LEMON's setup that lets the tokenizer feed the parser to our advantage. If done right this could be used to create a DECORATE parser that can remain mostly as it is and only calls the grammar parser for the stuff where it is really needed. For example to parse action function calls inside DECORATE definitions one possibility could be to feed the parser with a dummy function header so that the actual code pointer call would be the function's body (and of course any closing tokens could again be fed manually to the parser.)

Sure, I know it sounds a bit hack-ish but it sure sounds appealing to me to make it all function with less work. The only alternative that wouldn't require a rewrite of the entire DECORATE parser would be to separate the actor definitions from the accompanying code. I don't like that idea.