Programming Language support in WML (was '[nowml] tag')

[Sapient]

I really don't like this idea because it would have some negative side-effects.

If every property of every exposed object can change at any point in an event, this added power creates an added burden to verify things that depend on those values. One of the benefits of WML's simplicity is that it creates clear points of entry. You know what changes can occur in each place, and (hopefully) you plan accordingly.

Also, supporting two scripting language would require more time than supporting one scripting language. If a language is far better than WML, then I'd rather switch over to it entirely. However, the language should be simple enough so that non-programmers will not be intimidated by it. Since WML has an incredibly simplistic design, it will be hard to beat in that area.

[Viliam]

Also, supporting two scripting language would requires more time than supporting one scripting language. If a language is far better than WML, then I'd rather switch over to it entirely. However, the language should be simple enough so that non-programmers will not be intimidated by it. Since WML has an incredibly simplistic design, it will be hard to beat in that area.

The strength of WML is in the places where it can be simple -- defining unit properties, defining sides, defining simple events. But when scenario authors want to do something more complicated, it is often necessary to use a lot of macros (where IMHO things become even more intimidating than an elegant scripting language would be) or to add new WML commands (so the simplicity of WML language is balanced by the number of different tags and their special attributes; yes, most WML commands are relatively simple... after your find all related details in wiki).

I agree with the idea that the new language must be obviously superior to WML, because supporting two languages would probably be a lot of work and lead to a lot of bugs. It would be good to point out specific things which are hard to do in WML, and could be interesting to see in scenario. My biggest hope is that with another scripting language it would be enough to support a finite set of objects and properties in C interface, and everything else would be programmed in that scripting language. Now I fear that adding new features often requires new WML tags, and that means extending the interface in C.

Until then, maybe a good offline WML manual would help. A copy of all pages in WML Reference could be the useful thing...

[zaimoni]

Check out lua's use in ToME 3 Alpha

Have done that for ToME 2. Keep in mind that Angband and its variants are C, so Lua is a more natural scripting language than Python. [Python binding was attempted...apparently, it didn't go well.]

Lua is a very powerful language, but it extends the C metaphor in the direction of ML and Haskell, not in the direction of C++. As such, ToME's advanced uses of Lua are functional programming.

It should be noted that auto-reflection of C++ classes into Lua has been a stalled project in Boost for almost three years now. Boost reflection of C++ classes into Python has been around since 2002.

And that is, quite simply, because Lua 5 doesn't have any object model to reflect into. Sure, you can wrap all public methods as C functions with C interface -- which means no overloading, and you lose all of the syntactic sugar, and you still can't reflect C++ equality and assignment into Lua equality and assignment.
====
[Boost libraries]
The technical reason I don't expect Boost to be adopted by Wesnoth is that Boost is too finicky about its compilers. [In particular, most of the interesting features are compiler errors on the must-support MSVC 6.1.]

However, there's a licensing issue I haven't researched yet: whether it is legitimate for a GPL'ed project (Wesnoth) to use a library with the Boost license (which explicitly allows commercial reuse of the library).

[Jgrr]

However, there's a licensing issue I haven't researched yet: whether it is legitimate for a GPL'ed project (Wesnoth) to use a library with the Boost license (which explicitly allows commercial reuse of the library).

Contrary to the common belief, the GPL is not anti-commercial in any way. It is just anti closed-source, which is a completely different matter, even if most of the companies very closely associate them together.

In http://www.gnu.org/philosophy/license-list.html , there is a list of GPL compatible and incompatible licenses, with justifications. According to the page, Boost is compatible.[/i]

[zaimoni]

Good to see someone's thought about it. [Boost is so short that any contrafactual incompatibility issues would have been on the GPL side.]

And an enumeration of licenses that indeed prohibit compilation.