Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Killer app/lib/built-in-feature to make Basil stand out #34

Open
dumblob opened this issue Feb 17, 2022 · 0 comments
Open

Killer app/lib/built-in-feature to make Basil stand out #34

dumblob opened this issue Feb 17, 2022 · 0 comments

Comments

@dumblob
Copy link

dumblob commented Feb 17, 2022

...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

  1. 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.
  2. The rule engine shall be fully parallel to take advantage of tens, hundreds, etc. processing cores.
  3. The syntax shall be "safe by default" - i.e. probably making then = false the default to guarantee no cycles can happen.
  4. session.retract( ... ) shall be discouraged and instead a "cascading" session.retractCascade( ... ) shall be introduced to guarantee the fact DB will always stay consistent.
  5. 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.
  6. 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).
  7. 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" 😉).
  8. ... (this list is not exhaustive)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant