You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
...and maybe lead to some monetization (as language itself is not monetizable, but an end-user product is).
Motivation
There are many hardly explored areas where compile-time evaluation brings major advantages.
Recently I thought a rules engine - if made part of the standard Basil runtime - could accelerate public interest in Basil. More importantly, it'd allow for terse, provably correct (assuming the runtime itself is correct, ehm), and readable/understandable programming.
This would substitute all reactive programming, ECS libraries, etc. Game development, UI development, etc. shall then become a breeze in Basil.
Basil should focus on the staticRuleset functionality (incl. the wrapper macro to avoid forced centralization of rules in the source code) instead of the alternative naive implementation (uses mutable dynamic arrays/tables under the hood) pararules offer.
The rule engine shall be fully parallel to take advantage of tens, hundreds, etc. processing cores.
The syntax shall be "safe by default" - i.e. probably making then = false the default to guarantee no cycles can happen.
session.retract( ... ) shall be discouraged and instead a "cascading" session.retractCascade( ... ) shall be introduced to guarantee the fact DB will always stay consistent.
Because Basil uses value-passing, the API shall automatically always use references (in whatever form - not necessarily a pointer) to all bigger values (usually most non-primitive types or anything having more than two or four bytes) passed to the rules engine.
Leverage the low-level capabilities of Basil and optimize the rules engine leveraging all the information available in compile time (especially to achieve cache locality & coherency as that seems to be what the rules engine algorithms suffer from).
Improved syntax (this I'm not much afraid of as Basil is nicely readably by default, so it's only a matter of "not screwing it up much" 😉).
... (this list is not exhaustive)
The text was updated successfully, but these errors were encountered:
...and maybe lead to some monetization (as language itself is not monetizable, but an end-user product is).
Motivation
There are many hardly explored areas where compile-time evaluation brings major advantages.
Recently I thought a rules engine - if made part of the standard Basil runtime - could accelerate public interest in Basil. More importantly, it'd allow for terse, provably correct (assuming the runtime itself is correct, ehm), and readable/understandable programming.
This would substitute all reactive programming, ECS libraries, etc. Game development, UI development, etc. shall then become a breeze in Basil.
Summary
Build something like https://github.com/paranim/pararules but without the few downsides pararules have.
Details
staticRuleset
functionality (incl. the wrapper macro to avoid forced centralization of rules in the source code) instead of the alternative naive implementation (uses mutable dynamic arrays/tables under the hood) pararules offer.then = false
the default to guarantee no cycles can happen.session.retract( ... )
shall be discouraged and instead a "cascading"session.retractCascade( ... )
shall be introduced to guarantee the fact DB will always stay consistent.The text was updated successfully, but these errors were encountered: