Replies: 1 comment
-
Following an This also brings up the question how plugins should deal with this because Not following |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
First let me describe the problems I'm trying to solve:
-O gen-C++
currently has to skip functions (or in some cases whole files) that are influenced by@if
conditionals, because if it compiles them in one context and they execute in another (where the@if
would resolve differently), the results would be incorrect. There's no easy fix for this because@if
s throw away their enclosed body un-scanned/un-parsed when the conditional is false.To address these, I'm thinking about introducing a new type of
@if
conditional, say@activate-if
. The key differences from@if
would be (1) the expression in the conditional is remembered, and made available to subsequent analysis (such as allowing the compile-to-C++ compiler to generate run-time conditional decisions), (2) code inside would be (a) fully parsed (resulting in errors if malformed, or if this introduces inconsistencies with other code outside the conditional), but (b) deactivated (event handlers wouldn't be installed,redef
s wouldn't happen), and (3) perhaps some forms of scripting would be disallowed or generate warnings, such as extending a record, or complaining about appearing inside a non-activating@if
, or (maybe) if a@load
is present.Not all
@if
s can be treated in this way, which is why this would be a new form of conditional rather than an adjustment to the current one. In current use,@if
s are heavily dominated by varying behavior depending on whether the script is running on a cluster, and if so whether the current node is a worker/proxy/logger. From the inspections I've done so far, it looks like many of these could be converted to@activate-if
s.Beta Was this translation helpful? Give feedback.
All reactions