peq
commented
9 years ago Here would be an example using a special annotation @withRuntime. The meaning of this would be that all calls to native functions, which are not understood by the compiletime interpreter, are recorded and added to map initialization time.
@compiletime @withRuntime
function example()
for i = 1 to 8
new ItemDefinition('I000' + i, 'Ibla')
..setName("Tome of attack " + i.toString())
createItem('I000' + i, vec2(0., 0. + 128. * i))
// would generate:
init
CreateItem(1227894833, 0.0, 128.0)
CreateItem(1227894834, 0.0, 256.0)
CreateItem(1227894835, 0.0, 384.0)
CreateItem(1227894836, 0.0, 512.0)
CreateItem(1227894837, 0.0, 640.0)
CreateItem(1227894838, 0.0, 768.0)
CreateItem(1227894839, 0.0, 896.0)
CreateItem(1227894840, 0.0, 1024.0)Open questions:
-
- what should happen if the result of such a native function is used somewhere? For example:
@compiletime @withRuntime
function example_problem()
for i = 1 to 8
new ItemDefinition('I000' + i, 'Ibla')
..setName("Tome of attack " + i.toString())
createItem('I000' + i, GetPlayableMapRect().getCenter().polarOffset(angle(0), 128.*i))or even:
for i = 1 to GetPlayers()
...My first idea would be too throw an error if a return value from such a function is used somewhere, but that is probably too restrictive. If we make it more flexible, it would be very hard to explain the semantics of this construct, I guess.
-
- Often one wants init code to be executed delayed, so that load time is not affected and the maximum number of instructions are not a problem in the init. How could this be done here?
Cokemonkey11
I am not yet sure how this could be done. Some discussion is below:
(15:45:35) Cokemonkey11: peq, why can't I create a unit in a compiletime function? (15:46:05) peq: you mean a new unit type? (15:46:09) peq: or a real unit? (15:46:31) peq: the first one should be possible (15:49:49) Cokemonkey11: i mean createunit() (15:50:14) Cokemonkey11: it would be a nice feature if compiletime functions could automaticaly detect non-compiletime events (15:50:21) Cokemonkey11: and build initialization functions instead (15:50:38) Cokemonkey11: because it would be useful for example i have a unit which is only for decoration (15:50:49) Cokemonkey11: i compiletime initialize it and then place it in the same function (15:55:32) WaterKnight: how are comptiletime functions scheduled (16:02:34) ***Cokemonkey11 slaps peq around a bit with a large fishbot (16:04:04) peq: hm, I think we could do that (16:04:12) peq: but I don't see much benefit in it (16:04:23) peq: you can do the same thing in normal code (16:05:17) Cokemonkey11: yeah its just a pain in the ass (16:05:21) Cokemonkey11: if i have a compile time function for 10 units (16:05:27) Cokemonkey11: and also a single placement for each of those 10 units (16:05:39) Cokemonkey11: it isn't very pragmatic to have a big set of function pairs (16:06:49) peq: one function to generate the objects + one init block (16:07:22) Cokemonkey11: right but the data is associated regardless (16:07:28) Cokemonkey11: i have 10 units that each need to be placed once (16:08:21) peq: I think it would be confusing to mix compiletime and runtime like this (16:08:55) peq: then you have to know for each function which one belongs to compiletime and which to runtime (16:09:21) Cokemonkey11: just remove @ compiletime completely (16:09:31) Cokemonkey11: compiletime events should be implicit (16:09:44) Cokemonkey11: functions should support both types of event (16:09:49) Cokemonkey11: and the compiler should arbitrate that (16:10:13) peq: functions can be used in both types (16:10:23) peq: the annotation is just to say which ones are called (16:10:52) peq: it wold not make sense to just call all the functions in the script (16:11:40) Cokemonkey11: just merge compiletime and initialization functions (16:11:48) Cokemonkey11: initialization can never perform compiletime events (16:11:54) Cokemonkey11: and compiletime events can never be run during initialization (16:12:04) Cokemonkey11: so the distinction is just overly verbose (16:12:37) peq: so you want to write compiletime code in normal init blocks? (16:12:58) peq: and the compilere should check the contents of init blocks to see which ones should be run at compiletime? (16:13:10) Cokemonkey11: i want to be able to write good functional code that takes a set of data (unit type and location) and both initialized and instantiates them (16:13:19) Cokemonkey11: instead of writing two functions to perform half of those actions on the same data (16:13:26) Cokemonkey11: yes exactly (16:14:45) peq: hmm (16:15:24) peq: someone has done something like this by using if blocks (16:15:30) peq: maybe it was Crigges (16:15:35) peq: something like (16:15:45) Cokemonkey11: if blocks? what do you mean (16:15:48) Cokemonkey11: i dont understand how it can be (16:15:58) peq: if compiletime then else
(16:16:31) Cokemonkey11: how is that possible
(16:17:29) peq: https://github.com/Crigges/HotN/blob/080bce449d51e9d63e8d4011292586935031e011/HotN/wurst/helper/CompiletimeInit.wurst
(16:17:29) Cokemonkey11: is the @ compiletime annotation just an alias for something else?
(16:18:13) Cokemonkey11: that.. that is spagetti
(16:18:30) peq: and https://github.com/Crigges/HotN/blob/080bce449d51e9d63e8d4011292586935031e011/HotN/wurst/OeSetup.wurst#L26
(16:20:16) Cokemonkey11: that is useful
(16:20:26) lep: kek
(16:20:28) Cokemonkey11: i think that this is a language smell though
(16:21:02) WaterKnight left the room (quit: Quit).
(16:22:18) peq: i don't like it much
(16:23:42) Cokemonkey11: what don't you like, the second example? it's just an ugly version of my suggestion
(16:23:45) Cokemonkey11: still better than two functions though
(16:24:06) peq: it's both one example
(16:24:20) peq: the first is to set the "compiletime" variable
(16:24:24) peq: that is a bit ugly
(16:24:40) peq: would be nicer if there was a builtin constant for that
(16:25:08) peq: and I also don't like the mixing of compiletime and runtime
(16:25:29) peq: I think it even depends on the optimizer to eliminate the if-statements
(16:29:30) Cokemonkey11: he shouldnt have to do that imo
(16:29:43) Cokemonkey11: it should be part of the compiler to do compiletime actions during compile time
(16:29:48) Cokemonkey11: and everything else during map load
(16:30:04) Cokemonkey11: unless you have really good example of an action that has a good reason to run in both
(16:32:01) peq: usually there are some functions shared by both
(16:32:15) peq: but the actions are separate
(16:35:09) Cokemonkey11: right, some actions can occur in either case, that's fair
(16:35:30) Cokemonkey11: actually, which actions are those?
(16:36:09) peq: setting up the data
(16:37:17) peq: so data which you need to create the objects and which you also need at runtime
(16:41:57) Cokemonkey11: such values should be constants
(16:42:04) Cokemonkey11: or equivalent for both
(16:42:05) Cokemonkey11: no?
(16:42:22) peq: yes
(16:42:37) Cokemonkey11: so the compiler could just duplicate this part of the code
(16:42:39) Cokemonkey11: in the generated output
(16:43:10) peq: but how should it know which parts are required by the runtime?
(16:43:16) peq: and which by the compiletime?
(16:45:15) Cokemonkey11: for example, each initialization function could be parsed twice - once as though it were compiletime, and once as though it were initialization time
(16:45:45) Cokemonkey11: actions which have effect on the compiletime one are stripped in the initialization time one
(16:45:54) Cokemonkey11: any extra code like conditions and loops would be stripped automatically
(16:46:13) Cokemonkey11: once that compiletime stuff is gone in the initialization pass that is stripped of compile-time only actions
(16:46:27) Cokemonkey11: im sorry im not very good at describing this, i never wrote a compiler before