Howdy,

CLIPS hasn't seen a major version release in almost 30 years.
Now, version 7 is being cooked -- that will be a big milestone :-)
Since these major version updates come so rarely, I've taken the
opportunity to list a few wishlish items, down below.
I'm putting this out there, and then crossing my fingers.
I know it's alot, but I'll probably only get to do this once in my life.
I hope you consider them for inclusion in V7.

In any case, I think CLIPS is awesome!

LANGUAGE

# 1. Please add multi-line comments.

# 2. Add an alias to the "bind" function named ":="

(:= ?val "some string")

Having a "traditional" looking binding/assignment feels good.
It helps that it stands out in code, so it's easier to spot assignments.

**# 3. Ability to declare and use constants. **

It's important for a language to have this. It's just good engineering.
I think them being limited to scalars (bool, int, float, symbol, and string) is perfectly reasonable.
Today, it feels clunky to use globals for the sake of eliminating magic numbers.
It's also unnecessary processing, because the constants should just be propagated at the location
they are used, instead of performing a read operation when their value is needed.
The lack of constants leads to a slight feeling of uneasyness; like something is missing.
I propose, for the sake of parsing simplicity, they could require a sigil. Like:

    (defconst #my-const = 42)
    (assert (my-fact (value #my-const)))   

I understand there may be code out there that uses # in prefix, but if there are going to be breaking changes, then they would happen in a major release. It would be easy to search and replace those fields.
For the sake of having constants in the language, I think such a change would be agreeable to experienced developers.
Personally, I think it would be unfortunate to add something suboptimal for all future time, in order to avoid having upgraders needing to make any change. Something like ?#m-const# wouldn't be ideal, in my opinion.

# 4. Make booleans a first-class type, like INTEGER and FLOAT

  (slot foo (type BOOLEAN))
  (iff (some-expr) #true #false)

This would strengthen the type system, as places that require booleans
could cause an error if given a different type.
Modern languages are converging on the idea that conditional statements must be
given explicit booleans, instead of performing implicit conversions.
That would eliminate the class bugs stemming from wrong use of values within conditionals.
This would also make generic functions that expect booleans more type-safe.

I understand that this is potentially a big change since, for consistency, existing
functions that return FALSE would be updated to return #false. But, I think for
posterity, having a proper boolean type would be a net positive for the language.

# 5. Add a Unit-Type to the language.

https://en.wikipedia.org/wiki/Unit_type
A good candidate would be: NIL as the type, and #nil as its only value.
Functions that are meant to return something or nothing, such as fact-slot-value, should
not return the FALSE symbol, since that is a valid slot value. Instead, missing values
should be denoted by #nil.

#nil, of type NIL, can be compared to every value, but only compares true to another nil value.
It is ilegal to create a type-constraint of type NIL: (slot foo (type NIL))

This part is optional, but because CLIPS is a somewhat functional language then, conceptually,
functions that don't return anything do in fact return the unit-type.
Also, conceptually, (void)'s return type is NIL, and the value is #nil.
(iff (expr) ?on-true-value) returns #nil as its else value.

With a unit-type and first-class booleans, the CLIPS type system would be fairly sound.

** 6. For C++ users, please add support conditional namespace. **

This would only affect C++ users, and C users wouldn't notice a difference.
For C++ users, this has the following benefits:
- Avoids placing CLIPS symbols in the global namespace, which avoids symbol clashes.
- When using IDEs, it helps Intellisense figure out the functions of the CLIPS API.
That is, when the IDE detects typing of "clips::", it will know which functions to suggest.
This is very useful for API discovery.

// in some file, define:
#ifdef __cplusplus
    #define CLIPS_NS_OPEN  namespace clips {
    #define CLIPS_NS_CLOSE }
#else 
    #define CLIPS_NS_OPEN  
    #define CLIPS_NS_CLOSE 
#endif

// In clips headers and sources:
#include ...
#include ...

CLIPS_NS_OPEN

// ... contents of file

CLIPS_NS_CLOSE

7. Embedded CLIPS can use the concept of an user-overridable interface.

This is a set of callbacks that the user could override in order to provide custom functionality,
according to their specific needs. Whenever CLIPS performs an action that could benefit from
user customization, it would do it using functions in this interface.
Something like:

   struct IUser {
        // The header portion of IUser interface.
        int64 info;
        void* next;

        // List of interface callbacks:
        typedef void (*onPrint)(Environment*,  const char*);
        typedef int  (*onGetFoo)(Environment*,  bool, int, float);
        typedef void (*onWarning)(Environment*, int, const char*); 
        // ...
   };

During CLIPS init...

First, initialize an IUser with default CLIPS actions. It provides default behavior to all the callbacks (perhaps as no-operations). It also attaches the pointer to the Environment object.

    MyCustomFooStruct myObject;
    ...
    Environment* env = CreateEnvironment();
    SetEnvUserData(env, &myObject);

    IUser iuser;
    InitIUser(env, &iuser, VERSION_1);  

    // At this point, 'iuser' points to default callback implementations.
    // Now, the developer can override individual callbacks, as desired.
    void myOnWarning(Environment* env, int warnCode, const char* msg) {
        MyCustomFooStruct* ptr = (MyCustomFooStruct*) GetEnvUserData(env);
        // ...      
    }
    iuser.onWarning = &myOnWarning;

A final IUser initialization step. This gives CLIPS the ability to do some
optimization, after the user has setup their callbacks, but before initial run.
For example, perhaps, CLIPS creates an internal-only version of the interface,
where all the callback overriding have been pre-resolved, prior to use.

    FinalizeIUser(&iuser);

Info on the interface.

    // Common header to all IUser interfaces.
    struct IUserHeader {
        int64 info;
        void* next;
    };

   // Maybe there is only ever 1 IUser struct, which gets updated by 
   // adding more callback functions to it, or by modifying existing ones.
   // This is straight forward to code.
   //
   // On the other hand, this gives the ability to add extensions in a backwards compatible way.
   // There would be an IUser, then IUser2, then ... IUserN
   // This gives flexibility on how the CLIPS custom callback interface is upgraded.
   // 
   // This extension format is inspired by the Vulkan Graphics API.
   struct IUser {
        // Must be the first element.
        // Provides basic information about this (not next) IUser interface. 
        // Any type of info can be stuffed here, in a format that CLIPS understand.
        // For example, the low 16 bits could give the version of this IUser struct.
        //      iuser.info = MAKE_IUSER_INFO(VERSION_42_7, ...)
        int64 info;

        // This is an extension point. 
        // It gives the oportunity to expand the IUser struct with new or extra callbacks,
        // without breaking the previous API and with keeping the ABI stable.
        // Can be NULL, if there are no more extensions installed.
        // If not NULL, can be casted to IUserHeader* for inspection.
        //      IUserHeader* header = ptr->next ? ((IUserHeader*) ptr->next) : NULL;
        void* next;

        // Then, follows the callbacks definitions....
   };   

    // A future extension of IUser interface -- optional.
   struct IUser42_7 {
        // All interface extensions must have 'info' and 'next'.
        int64 info;
        void* next;

        // Version 42.7 only has one extension method.
        typedef void (*onQuantumTransfer)(Environment*, QuantumState*, void* data);
   };

   IUser iuser;
   IUser42_7 iuser42;
   InitIUser(env, &iuser,   VERSION_1); 
   InitIUser(env, &iuser42, VERSION_42_7);  

   // Extend IUser with new capabilities.
   ExtendIUser(env, &iuser, &iuser42);

   // Internally, maybe ExtendIUser() is just:
   iuser->next = iuser42Pointer; 

// Example use of extension method.
void IUseInterfaceExample_FileTransfer(Environment* env, FILE* file) {
        IUser* iuser  = env->iuser;

        // Interface version 42.7 supports quantum entanglement transfers.
        PFN_OnQuantumTransfer_Typedef quantumTransfer = NULL;       
        IUserHeader* header = iuser->next ? ((IUserHeader*) iuser->next) : NULL;
        uint16 version   = 0;

        // If present, fetch the extension method.
        while (header) {            
            version = header->info & 0xFF;
            if (version == VERSION_42_7) {
                IUser42_7* iuser42 = (IUser42_7*) header;
                if (iuser42->onQuantumTransfer) {
                    quantumTransfer = iuser42->onQuantumTransfer;
                }
                break;
            }

            if (header->next) {
                header = (IUserHeader*) header->next;
            } else {
                header = NULL;
            }
        }

        if (quantumTransfer) {
            (quantumTransfer)(env, file);
        } else {
            // Use old-style transfer.
            (*iuser->onFileTransfer)(...);
        }
    }