'inline' setting

ID:2103365
 
Jun 20 2016, 1:45 pm
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
Random idea: Would it be possible and perhaps feasible to add an inline setting for procs that allow them to act similarly to a #define macro? An example:

mob
    proc/check_something_proc()
        set inline = 1
        return src.somevar ? 1 : 0


The inline setting would make check_something_proc() act exactly as if it were defined.

#define check_something_proc()  \
    return src.somevar ? 1 : 0    \


Related thought:
Jun 20 2016, 1:53 pm
Well, for one, #defines can't work that way, they have no src, you'd have to pass an argument. For two, I can't imagine a possible way for the compiler to be able to change from actual code to preprocessor-friendly code with the usage of an inline keyword, 99% of the code you can write in normal DM won't work as a #define.
Jun 20 2016, 2:04 pm
In response to Nadrew
99%? Seems a bit high to me.
Jun 20 2016, 2:06 pm
Exaggeration for effect :)
Jun 20 2016, 2:47 pm
In response to Nadrew
You're right; I thought I recalled something similarly typed working before, but my testing proved that incorrect.
Jun 20 2016, 3:56 pm
This is actually something I've thought about. It's a tricky problem so it's been more of a wish-list item for me, but it's on my mind for sure.
Jun 20 2016, 4:26 pm (Edited on Jun 20 2016, 4:34 pm)
while you're there, add a inline for datum vars, that make them bypass the changed vars array and get compiled into indexes for super fast var accesses (a limitation would have to be that they only have fast access on src. accesses (or could even only be accessible on src to save on overhead added to other var accesses))

edit: as for inline procs, the implementation detail is easy:

They are only inlined when accessed locally or if the proc is global (ie, only when accessed via src. (or the implied src.) or if the inlined proc has no src (global))

It auto renames all vars in the proc when compiled inline to avoid conflicts and make runtime reporting easier

args accessing would be the hardest part, and accessing args list might have to be invalid (triggering the compiler to ignore the inline flag).

there will be a depth limit of say, 3 procs, so that calling an inlined proc from an inlined proc doesn't matter, and in most cases still resolved.

Any issues with these limitations and it just compiles as a normal proc call.
Jun 25 2016, 11:45 am
In response to Nadrew
You can actually do a lot with defines already.

Proc call overhead is scary.

Yes I'm more than well aware how dirty this is.
Jun 25 2016, 1:06 pm
Why are you equating it to a define macro? Why not just call it what it is: marking a proc inline would replace calls to it with the actual bytecode contents of the proc.

There would be a few caveats and gotchas due to the infrastructure of DM, but I do believe that overall such a feature could be beneficial if used properly.

Also, instead of this set inline thing (which, admittedly, isn't a major stretch from other proc settings), I would prefer something along the lines of:
inline/proc
proc/inline

// akin to:

const/var
var/const

With the obvious implication of possible name conflicts.
Jun 25 2016, 1:19 pm
In response to Hiead
Why are you equating it to a define macro? Why not just call it what it is: marking a proc inline would replace calls to it with the actual bytecode contents of the proc.

No reason pertinent enough to mention. It got the idea across effectively enough however.

Also, instead of this set inline thing (which, admittedly, isn't a major stretch from other proc settings), I would prefer something along the lines of:

An inline setting was the first thing that came to mind. It fits into the language perfectly compared to the alternatives, in my opinion.
3:00 am
Necro, but this is still open and I'm going with my gut by just replying to the existing thread. I find issue with the lack of inline procs... a lot.

Defines are unwieldy for many reasons. To begin with, return values? Don't have those. Not with multi-line defines. You also lose syntax highlighting and have to use curly braces for statements among other syntax quirks. It's not good.

And proc overhead is a serious problem. For example when making a liquid system for an SS13 fork, exposing atoms to reagents is done via /atom/expose_reagents(). This has two sets of proc overhead for the type-specific variants and further from the subprocs /reagent/expose_atom(), /reagent/expose_mob(), /reagent/expose_turf() and /reagent/expose_obj(). (forgive me if I mistyped any of the procs it doesn't really matter though)

Those are all pretty deeply integrated procs and extracting them out is painful. If I could instead just write /inline or something, that would make my life much easier. And no, this is not the only case where it'd be useful, there are like 10 just for this one system, and it's a serious performance issue since the expose proc is called for every single turf in a liquid group. (of which there are hundreds or even thousands)

Login to reply.