Syntax Proposal / Inheritance
Is your feature request related to a problem? Please describe. There is currently no way to extend imported nodes (nor existing nodes) with new constraints, variables or objectives, nor to disable some of them, without copy-pasting or writing a lot of proxy-like code.
Describe the solution you'd like
It is difficult to reuse with
due retro-compatibility issues. The syntax for this would need to be very similar to the existing notation for creating nodes/hyperedges.
//import from local file (needs #VARIABLE)
#NODE x extends y
//... normal node definition ...
//import from external file (needs #VARIABLE)
#NODE x extends y from "file.gboml"
//... normal node definition ...
//shortcut for reuse-without-change
#NODE x extends y;
#NODE x extends y from "file.gboml";
Due to the "non-closed" block model of the GBOML language, to avoid ambiguities, we need to force node extension to contain a #VARIABLES
block. This means that under this syntax, it's not possible to redefine a parameter without an #VARIABLES block. We propose to use the keyword pass
(see #22):
#NODE x extends y
#PARAMETERS
a = 2;
#VARIABLES //without this, wouldn't parse
pass;
Hence the "shortcut" with ;
to allow simple reuse-as-is. Another possibility would be to add a "force node end block":
#NODE x extends y
#PARAMETERS
a = 2;
#END
I'm not a huge fan, but why not.
With this syntax, we can alternatively deprecate the with
syntax or keep it (to avoid problem like having to add #VARIABLES/pass/#END
when just redefining parameters).
Semantically, reusing any name in the new node definition would override the previous definition, so no need to introduce particular syntax for variable scope change for example.
We can introduce a syntax for objective/constraint removal:
#NODE parent
#VARIABLES
#CONSTRAINTS
named_constraint: x < 2;
#NODE x extends parent
#VARIABLES
#CONSTRAINTS
deactivate named_constraint;