#include'ing files multiple times

ID:1718128
 
Nov 11 2014, 11:01 am
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
This would be helpful for managing modular code.

For example, let's say there's a large and complex module A that uses conditional compilation.
Then let's say we have modules B and C which want to #include it, but with different compilation options. Or perhaps B and C want to include it, but module D and E don't (so the ones who want it would include it then include a set of #undefs undoing it).

Not sure how feasible this is, but it probably wouldn't break anything (if nobody has yet made a feature request for repeat-inclusion i highly doubt anyone relies on single-inclusion, not to mention that code would be hacky and strange.).
Nov 11 2014, 1:11 pm
++ I don't see this being a issue and I see the use in it. Shouldn't be hard to implement.
Jan 7 2015, 5:11 pm (Edited on Jan 7 2015, 9:20 pm)
Bumping since this is especially pressing now that I'm trying to put together a sort of standard library.
A "normal" #include would allow implementing special inheritance (especially mixins, interfaces) and very large macros in much cleaner ways.
If there's legacy support concerns, a new instruction (eg "#finclude") could be used for this, with the same functionality as #include (except without the check for whether it's already been included).

Another helpful thing along these lines would be a command to define/insert a block:
//Proposed          //Current

#defblock EXAMPLE   #define EXAMPLE \
world << "1"        world << "1" ; \
world << "2"        world << "2" ; \
world << "3"        world << "3" ; \
#endblock

             //Before

/proc/example()     /proc/example()
    world << "0"        world << "0"
    #insert EXAMPLE     EXAMPLE
    world << "4"        world << "4"
    return              return

             //After

/proc/example()     /proc/example()
    world << "0"        world << "0"
    world << "1"        world << "1" ; world << "2"; world << "3" ;
    world << "2"        world << "4"
    world << "3"        return
    world << "4"
    return


After all, it's a little strange to write macros with semicolons and curly brackets and insert it into code that uses the off-sides rule.

Edit: Found another use case for #including multiple times, long pre-processor instructions. For example, there might be multiple places in the compilation process where one might want to check the BYOND version and throw warnings/errors. Unless there's any more undocumented operators and instructions i'm not aware of, the pre-processor cannot handle even simple compounds of its commands, much less complex ones (this is probably because it uses a very simple parser, which does not have proper statement separators/terminators or block markers, and can't distinguish between # appearing as an operator or as part of a word). This means the best solution becomes putting the desired instructions in a file and #include-ing it: but that means this can only be done once due to the "include only once" limitation.

Jan 15 2015, 10:35 pm
Bumping again, I suppose.

This would be extremely useful, and it doesn't seem overly difficult to implement on the compiler side of things (to say the least). Plus it wouldn't break anything or slow anything down, so there's that.

Jan 16 2015, 1:00 am
In response to Wild Bill Bartok
Wild Bill Bartok wrote:
Bumping again, I suppose.

This would be extremely useful, and it doesn't seem overly difficult to implement on the compiler side of things (to say the least). Plus it wouldn't break anything or slow anything down, so there's that.


Bumping things doesn't mean they'll get looked at, considered or even implemented. I've been trying that on a few requests for a couple of years now, some are more involved than others and some are simple edits the the IDE....


Jan 16 2015, 2:20 am
In response to A.T.H.K
A.T.H.K wrote:
Bumping things doesn't mean they'll get looked at, considered or even implemented. I've been trying that on a few requests for a couple of years now, some are more involved than others and some are simple edits the the IDE....

Yeah, I know. Got enough ded feature requests to prove that :V.
Mainly bumping this since it hasn't gotten official word yet, and looks near-trivial to implement.