ID:2103365
 
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:
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.
In response to Nadrew
99%? Seems a bit high to me.
Exaggeration for effect :)
In response to Nadrew
You're right; I thought I recalled something similarly typed working before, but my testing proved that incorrect.
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.
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.
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.
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.
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.