Recent changes to feature-requests

#12 Version 7 wishlist: IDE

Gary Riley — Sun, 22 Feb 2026 00:42:01 -0000

1) There's already a function called clear-window that you can enter to clear the scrollback.
4) My vision changed in the last few years and I switched over to dark mode with apps that supported it. The macOS IDE supports dark mode. All it required was a recompile of the source code with the newer SDK and there was a single custom widget that needed to be swapped out with the appropriate system widget. I spent a week or so trying to get dark mode working with the Windows IDE. It was a nightmare with no reasonable support options for WPF .NET apps.

#9 Extend / function to allow a single parameter

Gary Riley — Thu, 02 Oct 2025 01:38:37 -0000

status: open --> closed
assigned_to: Gary Riley

#10 Extend the - function to accept a single argument

Gary Riley — Thu, 02 Oct 2025 01:37:42 -0000

status: open --> closed
assigned_to: Gary Riley

Version 7 wishlist: IDE

vlad — Fri, 31 Jan 2025 01:39:21 -0000

This is ticket 2 of 2 of my CLIPS wishlist. First is :
https://sourceforge.net/p/clipsrules/feature-requests/11/

This one pertains to the CLIPS IDE

Mr Gary, thank you for all the work you've done throughout the years,
and also for the work you continue to do.

Regards,
- a fan

CLIPSIDE

#1. When running inside the CLIPSIDE repl, please add a function to manipulate some aspects of the IDE. I'm specially hoping for:
(ide clear-scrollback)

#2. When running inside the IDE, please add a shortcut (like F5) to rerun the last batch file used.
This would allow a nice flow when iterating:
- make CLIPS changes in external editor (like vscode)
- switch back to IDE and press F5 to test changes
- repeat
This, coupled with the ability to clear scrollback from a script, would be sweet!

#3. Needs fix: in the IDE, when at the 'CLIPS>' prompt, pressing 'home' key doesn't nagivate the caret to beginning of line.

#4. Possibly big change. On behalf of my retinas, please add a dark theme to the IDE, if possible.

#5. Please add a toggleable option, in a menu, to auto-add top-level parenthesis.
That is, if the option is on, then entering this:
CLIPS> watch rules
would be equivalent to this:
CLIPS> (watch rules)

The behavior of that feature would be simple: If the first non-whitespace character of the text-buffer
is a letter or underscore "_", then add a "(" at the beginning, and a ")" at the end of
the text-buffer.

This is not a huge deal, but it would make working at the repl just a tiny bit nicer.

#6. Currently, at the IDE prompt, when pressing up/down keys, it always navigates the history.
This causes an issue when editing multi-line code: it's not possible to navigate
to the previous and next line with the up/down arrows.
I think it's important to be able to do that.
The way Powershell handles it is that if the user is editing a multi-line command,
then the up/down arrows does not change history -- they navigate, instead.
This could be detected by searching for a '\n' newline in the text-buffer when
an up/down arrow is pressed.

#7. Allow Ctrl+Enter (or Shift+Enter) to execute the current prompt buffer, regardless of the position of the cursor. Currently, one is forced to navigate to the end of the text-buffer, then press enter, to execute the code.

Version 7 wishlist: Language

vlad — Fri, 31 Jan 2025 00:55:00 -0000

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)(...);
        }
    }

#7 Provide find-indexed-fact function

Gary Riley — Mon, 27 Jan 2025 17:29:42 -0000

status: open --> closed
assigned_to: Gary Riley

#7 Provide find-indexed-fact function

Gary Riley — Mon, 27 Jan 2025 17:29:16 -0000

Added a function called fact-index-to-fact to the 6.4.2 release.

Extend the - function to accept a single argument

Dave Richards — Thu, 23 Jan 2025 19:35:10 -0000

        Common LISP allows the - function to accept a single argument. In such cases the argument is negated and returned. I had expected CLIPS to have the same behavior.

Extend the - function to accept a single argument

Dave Richards — Thu, 23 Jan 2025 19:35:10 -0000

Ticket 10 has been modified: Extend the - function to accept a single argument
Edited By: Gary Riley (garyriley)
Status updated: 'open' => 'closed'
Owner updated: None => 'garyriley'

Extend / function to allow a single parameter

Dave Richards — Thu, 23 Jan 2025 19:25:33 -0000

            Common LISP allows the / function to accept a single argument. In this case, the reciprocal of the argument is returned. I expected that CLIPS would follow  this same convention, but it requires two arguments.