Functions from data files

[Pete Mack]

Well sure you have to load the jdk as a jar file in order to use it, just like any other library. The same holds for haskell and C#. But it's perfectly feasible--much easier than in C/C++, where dynamic calls are a huge pain in the neck, never mind needing installed .h files and compiler for it to "work" at all.

Nope, not for (at least) Java nor Haskell. There's no guarantee that a running problem will have access to the compiler in either of those languages. (After all, the JDK is separate from the JRE. You only need the JRE to run Java bytecode. However, it is possible to generate bytecode at runtime and to use that. Can't recall if something similar might be possible with the GHC Haskell interpreter, but definitely not in general Haskell code. It's possible to load (compiled) code at runtime, though.)



I think the point here is that if you use e.g. a LISP (i.e. good for DSLs), it would be entirely possible to keep the data files just as succinct as they are now while also allowing things like changing how e.g. BLINK i monster.txt functions. (Spell effects are mostly hardcoded; see e.g. CAUSE_1, CAUSE_2, etc.)

[AnonymousHero]

Well sure you have to load the jdk as a jar file in order to use it, just like any other library.

I don't believe that it's specified anywhere in the standards that this needs to be possible. It may be possible currently if you're using the "right" JRE/JDK, but it's hard enough to get non-developer users to install the JRE, so in practice it's not really going to be workable unless you control the deployment environment (which Angband does not). Plus, most code requires a metric ton of dependencies which is going to be fun for users to download. (The "download the internet" phrase is only funny if you're on a fast internet connection.)

... and, actually, I don't I've seen a single example of this being done in practice (other than development tools, possibly) of over 10+ years of Java development. Do you have any examples?

The same holds for haskell and C#.

Haskell is a language not a compiler. I think you mean GHC Haskell. Can't comment on C# as I don't know enough about it.

But it's perfectly feasible--much easier than in C/C++, where dynamic calls are a huge pain in the neck, never mind needing installed .h files and compiler for it to "work" at all.

No argument that it's a huge pain in C++ (because of name mangling, etc.), but things like https://github.com/vgvassilev/cling already exist.

In the GHC Haskell case, unless you're using only the "base" set of packages (which ship with GHC and are always installed) then it's going to be a huge pain too. Just try using e.g. xmonad or yi or propeller from a sandbox[1] and you'll see what I mean. (At least this was the case ~3-12 months ago.)

[1] To avoid having to install packages "globally". Perhaps nix-style builds will eventually get around this problem, but it's still a bit unstable.

[AnonymousHero]

Given my experience with Pyrel and trying to make a fully-general equipment/stats/spells system, it's not worth the complexity of implementation. I would definitely stick to trying to support the current use case only, at least as far as data files are concerned. We want to make it easy to add new behaviors, but really mostly only in that we have a big glowing sign in the source code that says "ADD NEW BEHAVIORS HERE". Ideally the dev creates a function, declares a string for it, adds the string/function pair to a mapping somewhere, and then starts using the new behavior in the data files.

Agreed -- unless someone can come up with a good composable way (i.e. an "algebra of spell effects") to generalize.

I do think the situation with the X macros could be improved a little bit[1] with a small custom code generator instead, but it's likely to be a small improvement.

Anyway, I think this this topic's been more or less exhausted, so I'll leave it at that .

[1] X macros get a bit unwieldly editing-wise and rather error prone if you need to remove columns (or insert columns in the middle). They're also a bit annoying if you need to derive other compile-time data from them (e.g. the classic MAX_* macros).